Editor and MCP
A component library is a contract. These props, these variants, these tokens. An assistant generating a screen from training data is working from a guess at that contract rather than the contract itself. The Model Context Protocol is how the real one gets handed over.
What MCP is
The Model Context Protocol is an open standard for connecting assistants to tools and data through a declared interface. A server publishes the operations it offers and the shape of their inputs and outputs. A client (an editor, an agent, a chat surface) discovers those operations when it connects, and calls them while it works.
The important part is the direction of travel. Without it, context gets pushed: somebody pastes documentation into a prompt, and the model works from whatever made it into that window. With it, context is pulled, by the model, at the moment it needs it, in a shape it did not have to parse out of prose.
Because the protocol is the contract rather than one vendor's plugin format, a server written once is reachable from every client that speaks it. That is what makes it worth building against rather than shipping an extension per editor.
The problem it solves
Ask any assistant for a date picker and it will produce one. The code will look right. It will import from a path that reads correctly, set props with sensible names, and reference a variant that sounds like something a design system would have. Then it will not compile, because none of those were read from your library. They were predicted from thousands of libraries that resemble it.
This is not a flaw that a better prompt fixes. A prop common across similar libraries is a likely next token whether or not your version has it, and nothing inside the generation step can distinguish the two. The failure is structural: the model is answering from a frozen snapshot, and your component surface is not in it.
A design system is an unusually good candidate for a protocol like this, because almost everything an assistant needs is already written down and already machine-readable. The props exist as types. The variants exist as a finite set. The tokens exist as a configuration. Nothing has to be authored for the server that the library does not already have to define.
What a server exposes
The useful surface is the part that is checkable. A component's props and their types, so an invented one can be rejected rather than discovered at build time. Its variants, so a value outside the set fails immediately. The design tokens behind it, so a generated screen inherits the brand instead of hard-coding a hex. The accessibility contract: what carries a label, what the keyboard has to reach, because that is the part a generated component most often drops.
Version matters as much as content. An assistant asking about a library is really asking about a library at a version, and a server can answer for the one you have installed rather than for whichever release happened to be current when the model was trained.
Connecting an editor
The server is not live yet. It arrives with the code library, and until it does there is nothing to point an editor at, so this page does not print an endpoint that would fail, or a config block that looks runnable and is not.
What it will not do
It does not make an assistant good at design. A server can say a component takes a size prop with three values; it has no opinion on which of them belongs on the page you are building. Layout judgement, hierarchy and restraint stay yours.
It does not remove review. A generation validated against a real schema is correct in the narrow sense that every prop and import exists, which is a smaller claim than the code being right, and worth keeping separate in your head.
It is also not a substitute for documentation that a person reads. The two audiences want different things: a person wants the reason, an agent wants the shape. This page is the first kind. The server is the second.
Questions
What is the Model Context Protocol?
MCP is an open standard for connecting AI assistants to external tools and data over a structured interface. A server declares the operations it offers and the shape of their inputs and outputs; a client such as an editor or agent discovers those operations at connection time and calls them during a task. It replaces pasting context into a prompt with the assistant fetching what it needs.
Why does an AI coding assistant invent component props?
Because it is predicting plausible code from a frozen snapshot of public repositories, not reading the library you installed. A prop that is common across similar libraries is a likely next token whether or not your version has it, and nothing in the generation step can tell the difference. The fix is not a better guess but a source of truth the model can query.
Which editors and tools support MCP?
Anything that implements the client side of the protocol. Cursor, Claude Code and Windsurf speak it directly, and the list has grown steadily since the specification was published. Because the protocol is the contract rather than any one vendor's plugin API, a server written once is reachable from every client that speaks it.
Is an MCP server different from a documentation site?
Yes, in what reads it. Documentation is written for a person and parsed by a model only incidentally, in whatever form it was scraped in. An MCP server returns the component surface as structured data on request, at the version being asked about, which means an agent can check a prop exists before writing it rather than after a build fails.
All documentation
Getting started
Foundations
All components