What an MCP server is, briefly
The Model Context Protocol is an open standard for connecting AI agents and applications to external tools and data through one integration layer. Instead of the model answering from what it absorbed during training, it calls a tool, gets a current answer, and works from that.
For a design system, that means a server sitting in front of your documentation and code, exposing a handful of search or lookup tools. The agent decides when to call them during a session.
A real one, tool by tool
IBM's Carbon Design System publishes an MCP server, currently in public preview, and its documented tool list is a good template because it is specific rather than aspirational:
| What it returns | |
|---|---|
docs_search | Component guidance, usage, accessibility and reference documentation |
code_search | React and Web Components code examples, icons and pictograms — as complete example files, with props and imports |
get_charts | Charts examples across React, Angular, Vue, Svelte, vanilla JS and HTML |
labs_search | Experimental components — AnimatedHeader, Processing, Resizer, WhatsNew, Labs UIShell |
IBM's stated reasons are instant access to design standards, higher-fidelity generated code that follows best practices, and consistent answers from a shared source of truth that reduces drift and rework.
Notice that code_search returns *complete example application files*, not signatures. That is the design decision that makes these servers work. A model given a full working example reproduces the surrounding conventions — import style, composition, prop ordering — that a bare type signature does not carry.
The problem it actually solves
Ask a coding agent to build a form with your component library and watch what breaks. It will not usually be the layout. It will be a prop that was renamed two majors ago, an import path that moved when the package was restructured, a variant name that never existed, or a component that was deprecated and replaced.
This is a recall problem, and it has a specific and nasty property: wrong output looks exactly like right output. A hallucinated prop name is syntactically valid, semantically plausible, and reads correctly in review. You find out at runtime, or in a type error if you are lucky enough to have types.
A hallucinated prop name is syntactically valid, semantically plausible, and reads correctly in review. Retrieval beats recall because recall fails silently.
It gets worse with age. A model's knowledge of your library is frozen at its training cutoff and drifts further from reality every release. A private or internal design system is worse still: the model never saw it, so every call it writes is invention. MCP is the correct fix for both, because it replaces memory with a lookup.
The cost model nobody mentions
MCP is often discussed as strictly better than static context. It is not — it is a different trade, and the trade is legible once you write it down.
| MCP tool call | File in the repository | |
|---|---|---|
| When it is available | When the agent decides to call it | Every turn, unconditionally |
| Freshness | Always current | As current as the file |
| Cost | A round trip and tool-call tokens per query, repeatedly | Context tokens once per session |
| Scale | Unbounded — a 4,000-component library is fine | Bounded by the context window |
| Reliability | Depends on the agent choosing to call it | It is simply there |
| Setup | A running server, configuration, sometimes auth | Write a file, commit it |
The reliability row is the one that surprises people. An MCP server only helps if the agent calls it, and an agent that is confident it already knows your Button component will not call anything. That is exactly the case where you most needed it to.
If you install a design system MCP server and see no change in output quality, check whether it is being called at all before concluding it does not work. Confident wrongness does not trigger a lookup. A line in your repository instructions saying "always query the design system server before writing a component" is often the missing piece.
The scale row is where MCP is genuinely irreplaceable. A large component library with hundreds of components, each with variants and accessibility notes, cannot be pasted into context. That is a retrieval problem and always will be.
Why the agent still designs badly
Here is the part that gets skipped. Give an agent a perfect MCP server for your component library and it will produce code that compiles, uses real props, and follows the library's conventions. It will still produce an interface with no point of view: uniform card grids, hierarchy carried by font weight, the accent colour applied wherever an accent seems plausible, spacing that is technically from the scale and rhythmically arbitrary.
That is not a knowledge failure. The agent knew every component. It is a judgement failure, and it happens because nothing told it what your product should look like.
| MCP server | Design guidance in the repo | |
|---|---|---|
| Answers | "What is this component's API?" | "What should this screen look like?" |
| Owned by | The library's maintainers | You |
| Content | Props, variants, imports, accessibility notes, examples | Colour roles, type scale, spacing rhythm, motifs, prohibitions |
| Failure without it | Code that does not run | Code that runs and looks like everyone else's |
The second failure is the more expensive one, because it ships. A build error stops you. A generic interface does not.
We sampled 299 DESIGN.md files published for AI agents to read, checking whether they answer the second column. Most do not: 86% specify colours as raw hex with no semantic role, 76% state no prohibitions at all, 57% define no distinctive motifs, 69% say nothing about dark mode, and 44% contain no concrete size value anywhere. 54% lean on at least one vague adjective, most commonly "clean" (39%) and "modern" (36%) — words a model satisfies by producing the average of everything it has seen.
No MCP server fixes that, because no MCP server knows the answer. It is your design decision, and it has to be written down somewhere the agent reads every time.
Identity Forge design kits are that second column: semantic colour roles across light and dark, type and spacing scales, motifs, and explicit do's and don'ts, serialised into a DESIGN.md that sits in the repository alongside whatever MCP servers you run. Browse the kits, or read what a DESIGN.md file is.
What belongs where
A working rule, applied to the things a design system contains:
| Where | Why | |
|---|---|---|
| Component APIs, props, variants | Server | Large, changes often, only needed on demand |
| Code examples | Server | Too many to hold in context; retrieved by need |
| Icon catalogue | Server | Hundreds of names, needed one at a time |
| Colour roles and what each is for | File | Small, applies to every decision the agent makes |
| Type and spacing scale | File | Needed continuously, not on demand |
| Prohibitions | File | An agent never thinks to ask what is forbidden. It has to already know |
| Motifs and personality | File | This is the part that makes the design yours |
The prohibitions row is the sharpest test. Retrieval only surfaces what the agent thought to query, and an agent about to add a drop shadow has no reason to search for "are drop shadows allowed". Constraints have to be present before the decision, which means static context, not a tool.
Setting one up alongside a design kit
If you use Identity Forge, both halves are available. The design kit gives the agent the design decisions as a file; the MCP server gives it access to your kits, tokens and export formats as tools.
{
"mcpServers": {
"identityforge": {
"command": "npx",
"args": ["-y", "identityforge@latest", "mcp"]
}
}
}Run that alongside your component library's own server if it has one — Carbon's, Figma's, or your internal one. They answer different questions and do not conflict.
A short evaluation checklist
Before adopting any design system MCP server, five questions worth asking:
- Does `code_search` return complete examples or just signatures? Complete examples transfer conventions. Signatures do not.
- Is it versioned against the library you actually run? A server tracking
latestwhile you are pinned two majors back is worse than no server, because it is confidently wrong in a new way. - Does it cover accessibility guidance? Component APIs without accessibility notes produce components that render and exclude people.
- What is the auth story? Several published servers are gated to the vendor's own staff during preview, with a request form for everyone else. Check before planning around it.
- Are your agents actually calling it? Check the logs. An uncalled server is a configuration file, not a capability.
What does a design system MCP server actually do?
It exposes your design system's documentation, component code examples, tokens and icons to an AI agent as callable tools. The agent queries it during a session instead of relying on what it learned during training, which means it writes against your current API rather than a remembered one.
Will an MCP server make AI-generated UI look better?
It will make it work better — correct props, real imports, current variants. It will not make it look like your product, because the server holds the component API and not your design decisions. Visual quality comes from guidance about roles, scale, rhythm and prohibitions, which belongs in a file the agent reads every session.
Do I need an MCP server if I already have a DESIGN.md?
If your component library is large or private, yes — a file cannot hold hundreds of component APIs, and the agent will invent the ones it does not know. If you use a small or very widely known library, the file may be enough on its own. They solve different problems and neither substitutes for the other.
Why is my MCP server not improving anything?
Check whether it is being called. Agents only invoke a tool when they judge they need it, and an agent confident it knows your Button will not query anything. Adding an explicit instruction in your repository rules to consult the design system server before writing components usually fixes it.
Can I run more than one design system MCP server?
Yes, and it is common. A component library server, a design tool server and a design kit server answer different questions and do not conflict. Watch total tool count rather than server count — a very large combined tool list makes it harder for the agent to pick the right one.