Most AI coding assistants write interface code from a frozen picture of the public internet. The model read a great deal of React before its training cut off, and it read a great many component libraries, so it knows the shape of the thing you are asking for. What it cannot know is your library, at the version you installed this morning, with the theme your team configured last week. So it guesses, and the guess is convincing: a prop that sounds exactly like a prop you would have written, an import path that follows the convention every other library uses, a variant name that is one synonym away from the real one. The result reads as correct in review and fails at the type checker, or, worse, compiles and renders something quietly wrong.

A training snapshot is not a documentation problem

The reflex when an assistant invents a prop is to give it more to read: paste the docs into the prompt, add a rules file, keep a cheat sheet of the component API somewhere in the repository. That helps, and it does not hold. Context windows are finite, and a pasted document competes with the rest of the task for room. Docs go stale the moment someone renames a variant. And when the pasted page disagrees with what the model already believes, nothing in the prompt says which source wins, so it splits the difference and produces something that exists in neither.

The deeper trouble is that a prompt is a copy, and every copy of an API can drift from the original. Drift in this direction is silent: the code type-checks against the page you pasted and breaks against the package you installed. What an assistant needs is not a better copy. It needs to be able to ask.

What the Model Context Protocol adds

Model Context Protocol is an open standard for connecting an assistant to an outside system over a structured channel. A server advertises what it can do as a set of tools, each carrying a schema that describes its arguments and its result. The client opens a connection, discovers that list, and hands the model the schemas alongside the conversation. When the model needs something it does not know, it calls a tool and gets a structured answer back instead of reconstructing one from memory.

The discovery step is the part that matters. Capabilities are negotiated when the connection opens, which means the server decides what exists rather than the model recalling what once existed. Point the same assistant at a different server, or at the same server after a release, and its picture of the API moves with no retraining and no pasted documentation.

A typed component library is already a schema

A library that takes its types seriously has most of this work done. Props are typed. Variants are unions of string literals rather than free text. The colours a component accepts are a closed set of token names. Which children a component expects, and where they go, is expressed in the types of its slots. None of that is prose waiting to be summarised; it is structure, and structure is exactly what a tool schema wants.

So the server's job is mostly publication: expose the props a component really takes, the variant values it really accepts, the tokens that resolve in the current theme, and the accessibility contract each pattern carries. An assistant that asks about a component gets the answer the compiler would give, in a form it can act on.

Validation is what removes the guess

Publishing a schema is half of it. Generations are validated against the live component schemas before code is written: props that do not exist, missing required variants and invented imports are rejected, and the agent corrects itself against the real API. That is the difference between an assistant that is better informed and one that cannot be wrong about the surface it is calling.

Rejecting beats warning because of who has to read the message. A warning in a pull request costs a person a review cycle. A rejection on the tool call costs the agent one retry, in the same turn, with a machine-readable reason attached, so the failure lands where it is cheapest to fix.

Connecting it, and what changes afterwards

Connecting is a single configuration entry pointing at mcp.orvain.dev. Any assistant that speaks the protocol can use it, which today means Cursor, Claude Code, Windsurf and a growing list, and it is the same connection whichever of them a given engineer prefers.

What changes is the content of review. Nobody spends the first pass asking whether a prop exists, because that question was answered by something that knows. The pass that remains is the one worth a person's attention: whether the screen says the right thing, whether the empty state is useful, whether this was the component the situation called for at all.

The Orvain UI team

Writing about design systems and the tools that ship them.

All articles