MCP Feeds AI Coding Tools Real Component Data, Not Guesswork
Teams with in-house component libraries can now feed their actual specs to AI coding tools, eliminating the back-and-forth of re-explaining code. Teams relying on public UI libraries gain little from MCP, and the security and metadata upkeep are real costs to budget for.
AI coding tools still produce code that doesn't fit a specific project's component library, design tokens, or type definitions. The problem isn't model intelligence; it's that the model has to guess from public training data. MCP (Model Context Protocol) changes that by letting the assistant reach into a live codebase and pull project-specific metadata on demand.
The author spent two days building an MCP server for a ~60-component library. It exposes a component list, per-component details (props, slots, events, examples, design notes), and design tokens as resources, plus two tools: one that recommends components from a natural-language requirement, and one that validates a code snippet against the component props. After registering the server in Claude Code, the assistant stopped emitting native HTML and inline styles; it produced imports and props matching the library's actual definitions.
MCP works, but it's not friction-free. Exposing resources and tools means anything the AI can access is also accessible to logging or cloud transfer, so the server should stay read-only and only expose public specs. Metadata quality is the other bottleneck; the fix is to auto-extract from TypeScript and JSDoc comments rather than maintain a separate doc layer. The author's threshold for adoption: teams with 30+ custom components and a design spec see real gains; teams on Ant Design or Element Plus already enjoy adequate training data and shouldn't bother.
MCP amplifies metadata quality: stale or vague type definitions flow directly into AI-generated code, so its value hinges on keeping source comments and types meticulous.
The 30-component threshold is pragmatic but arbitrary; the real break-even point is when guessing on AI output costs more than the two days to build the server.
MCP is useful for specific integrations but not yet a standard interface; its adoption depends on ecosystem tooling, security hardening, and whether metadata extraction stays automated.
A quick exchange settles one taxonomy question—Codex-class tools clearly count as agents—before shifting to a tooling comparison. Building a skill from existing company documentation is proposed as a more convenient alternative to an MCP server, and the follow-up reply accepts it as a viable route. The thread stays brief, with agreement rather than any sustained debate.
Are Codex and those things considered agents?
Definitely counts, yes.
Why not just add a skill instead? If the company has documentation, wouldn't generating a skill be more convenient?
That would work too.