The conversation about AI and design systems usually starts in the wrong place. Teams ask: "How do we make our components available to AI?" But the more honest question is: "Do we even have what AI needs to find them?"
The answer, most of the time, is no.
The first and most foundational step to making a design system work with AI coding tools — whether that's Claude Code, Cursor, or any agentic IDE — is adding an MCP server. This article explains what that means, why it matters, and what it still won't solve on its own.
The infrastructure problem
There's a reason design system teams keep running into the same problems: adoption, consistency, documentation debt, handoff friction. And there's a reason those problems never fully go away.
Perhaps the reason design systems keep reinventing governance models, documentation strategies, and maintenance workflows is that we still frame them primarily as a design initiative. Looking at them as infrastructure changes the problem space entirely. Instead of creating new processes, we can adapt proven ideas from platform engineering, where managing shared dependencies, standards, and change across many teams has always been a core responsibility.
AI coding tools have made this distinction unavoidable.
When a developer prompts Claude Code or Cursor to build a component, the tool not reaches out to Figma, Storybook or your documentation site — it reaches out to whatever is connected to it via protocol. If your design system isn't connected, the AI invents something. Usually shadcn. More on that shortly.
To be available to AI tools, a design system must function like infrastructure: always on, queryable, returning structured data on demand. An MCP server is the interface that makes this possible.
What an MCP Server actually does (Step by Step)
Model Context Protocol (MCP) is the standard Anthropic introduced for connecting AI assistants to external tools and data. Cursor, Codex, Kiro - most agentic coding tools supports it. But what does it actually do?
Here is the cleanest definition: a Model Context Protocol is how you give an AI on-demand access to your design system knowledge.
The flow works like this: imagine a child building with LEGO.
- You say: "Build a house."
- The child doesn't remember the instructions.
- So they ask a helper to find the right instruction booklet.
- The helper brings it.
- The child follows the instructions and builds the house correctly.
Here:
- The AI is the child.
- MCP is the helper.
- Your design system documentation is the instruction booklet.
The key phrase is "on demand." The MCP doesn't push everything to the AI constantly — it responds when called. This is different from rules or system prompts, which are always active. Treat the MCP as on-demand access; treat rules as always-on instructions. Never confuse the two.
For design systems, this distinction matters enormously. Your component metadata — names, props, variants, usage guidelines — lives in the MCP. Your brand rules, tone of voice, and global constraints live in the system prompt. Each has its place.
How to connect your Design System: what this looks like in practice
shadcn already did this, and it's worth studying. Their MCP server lets AI assistants browse, search, and install shadcn components directly. A developer says, "Find me a login form from the shadcn registry," and the AI does it — pulling the exact component, configured per project through components.json.
This shifted shadcn from "the design system AI tools happen to use as a default" to "the design system AI tools have a protocol for." The overlap isn't happening by chance anymore - it's becoming infrastructure.
To connect your own design system, the setup follows a similar pattern:
In Cursor: Add the MCP configuration to your .cursor/mcp.json file, pointing to your server endpoint. The server can be local or hosted. Components and metadata are registered and queryable.
In Claude Code: MCP servers are configured in your claude.json or via the /mcp command. Once connected, Claude Code can call the server's tools directly during a session.
The MCP server itself needs to expose tools — functions the AI can call. Typical tools for a design system MCP include: search_components, get_component_props, get_usage_examples, and list_tokens.
JSON over markdown: the formatting decision that saves you thousands
Once you've set up the MCP, the next decision is how to format your component metadata inside it.
The winner is JSON, it beats Markdown formats and hybrid Markdown + JSON formats.
Why does JSON win? Because JSON is like a contract: explicit keys, values, boundaries, no ambiguity. It tells the LLM exactly what it sees and how to use it.
One important nuance: JSON is for structured component metadata — props, variants, token values, slot names. For natural language rules and instructions — usage guidelines, accessibility notes, do/don't patterns — Markdown is still the right tool.
The practical split looks like this:
- Component definitions, prop tables, token values → JSON in the MCP
- Usage guidelines, patterns, design rationale → Markdown with front matter
The shadcn wake-up call
When we ask AI to generate a component, it often starts with shadcn.
A shared default has quietly emerged across AI-assisted development. It wasn't established through a standards committee or adopted by design organizations. AI tools simply converged on a component library that was easy to access, generate, and extend.
The most influential design system in today's AI workflow wasn't created by a design team. It became the default because it is integrated into the ecosystem where AI operates. It's a reflection of how the tooling landscape has evolved. In an AI-first workflow, having a well-crafted design system isn't enough if AI can't discover and use it.
This is where MCP changes the equation. Instead of your design system living only in Figma files or documentation pages, it becomes a source of knowledge that AI tools can access on demand. The shift is from "we have a design system" to "every AI tool in our workflow can build with our design system."
MCP alone is not enough
Here's where the honest conversation has to begin.
Adding an MCP server to your design system is necessary, but not sufficient.
For the MCP to return useful results, your design system needs to have something worth returning. That means:
- Component APIs — each component needs clearly defined props, variants, and types that the AI can read and apply
- Contracts — explicit rules about what a component does and doesn't support, what it expects from its context
- Descriptions — semantic names and usage intent, not just visual descriptions
Without these, the MCP server queries your system and gets back noise. Structurally incomplete component data confuses the AI the same way it confuses a new developer. The MCP is the delivery mechanism; the component API is the content.
(For a deeper dive into what makes a design system AI-readable at the component level — contracts, prop schemas, semantic tokens — that's a separate article in this series.)
The designer's real role in an AI-assisted workflow
There's a tempting assumption buried in all of this: if you make your design system AI-readable and connect it via MCP, the AI will design your interfaces for you.
It won't. At least not well.
Even a fully connected, fully structured, AI-readable design system won't produce a good dashboard redesign on its own. The AI can pull the right components. It cannot determine the right layout, hierarchy, information architecture for your specific user and context. It doesn't know what problems your users actually have or which pattern serves them best. For that, you still need patterns defined — and even then, you're not guaranteed a good result.
Making your design system AI-readable doesn't remove the designer from the process. It changes the designer's role.
Instead of specifying every component from scratch, the designer evaluates what the AI generated, spots what's wrong, and makes targeted corrections. The AI is a fast drafting tool; the designer is the critical judgment layer. The system produces a starting point; the designer shapes it into something real.
This is not a lesser role. It requires understanding the system deeply enough to evaluate the AI's output — and to know when the output is wrong even if it looks right.
What to do next
If your design system isn't connected to an MCP yet, start there. It is the infrastructure decision that makes everything else possible.
The steps are:
- Set up an MCP server that exposes your component library as queryable tools
- Structure your component metadata in JSON (usage guidelines can stay in Markdown)
- Connect the server to Claude Code or Cursor via the respective configuration
- Test with real developer prompts to see what the AI returns and fix the gaps
Then audit your component APIs. The MCP is only as good as the data it serves.
And keep the designer in the loop — not as the bottleneck, but as the evaluator. The quality of AI-assisted design work scales with the quality of the system feeding it and the quality of the judgment reviewing it.
Both of those are still design problems.
