19 October 2026
Design system MCP: what it is, who has one, what it can't do
The top organic result for "design system mcp" is a Reddit thread from someone who cannot work out what the term means. That is the honest state of this topic.
Quick answer: "Design system MCP" is used for three different things, and most articles only describe one of them. (1) A server that knows about design systems in general, like Southleft's design-systems-mcp, which indexes W3C and WCAG material rather than your system. (2) A server that knows your design system, which is what Storybook's MCP addon and the design system platforms (zeroheight, Knapsack, Supernova) actually ship. (3) A server that knows your design files, which is the Figma MCP server. Only the second kind lets an agent import your real components, and it requires a component library and a manifest before it does anything. None of the three governs what the agent does on a screen you have no component for yet, because every one of them answers queries instead of setting rules.
Why the term is confusing
The query's SERP is a near-perfect illustration of the conflation. At rank 1 is r/FigmaDesign "MCP & design systems. Am I missing something?", whose opening line in Google's own snippet reads: "Lately been seeing some movement around design systems and the mcp, but seems like I cannot get the full picture of it. I see a lot of demos of people ..."
At rank 2 is a GitHub repo. At ranks 4 through 20 sit guides, vendor posts and practitioner write-ups, several of which are genuinely good, each describing a different one of the three categories as though it were the category. Google's AI Overview for the query defines it as "a standardized bridge that connects your design system's components, tokens, and guidelines directly to AI coding assistants and IDEs," which describes category two, and then cites the repo that is category one.
So start with the split.
The three kinds of design system MCP
1. A server that knows about design systems in general
southleft/design-systems-mcp is the GitHub result at rank 2 and one of the sources Google's AI Overview builds its definition from. It is MIT licensed, created 25 June 2025, and sits at 222 stars as of 19 October 2026.
Read its own description and the category becomes obvious. It is "An AI-powered Model Context Protocol (MCP) server providing intelligent access to authoritative design systems knowledge. 395 curated entries spanning W3C standards, WCAG guidelines, design system practice" and the 2025 to 2026 agent-interface protocols. Its README reports "395 entries in production database" and "4,800+ content chunks". It runs as a hosted connector at https://design-systems-mcp.southleft.com/mcp and exposes five tools: search_design_knowledge, search_chunks, browse_by_category, get_all_tags and browse_by_tag. (The README's setup section says four tools immediately above a list of five. Minor, but it is the kind of thing worth knowing before you promise a team a tool count.)
This is a reference library, not a connection to your product. It will tell an agent what WCAG 2.2 says about contrast. It knows nothing about your button.
Use it for: accessibility rules, token specification questions, general design system practice. Do not expect: your components, your tokens, your naming.
2. A server that knows your design system
This is what most people mean and the only category that lets an agent write code against your real library.
The clearest shipped example is Storybook. Its MCP addon reads your component library from the Storybook you already run, and the design intent behind it is unusually explicit. The Storybook Design Systems with Agents RFC, dated 22 September 2025, states: "The MCP server is intended for consumers of the Storybook, not the builders (although they could use it too if they want to)." Consumers, meaning the product teams and agents assembling screens out of a library someone else maintains. We go through the tool surface, the setup and the version requirements in Storybook MCP: the nine tools and the gates on them.
The design system platforms are the other half of this category. Supernova's survey of who has one, published 30 August 2026, puts it plainly: "Figma, Storybook, zeroheight, Knapsack and Supernova all have MCP servers," and splits them into source tools (Figma for design, Storybook for code) and platforms that hold "the tokens, the components, the documentation, and the connections between them." The same post reports zeroheight capping calls at "500/month on Free and Starter" and Knapsack announcing its MCP "as a beta in July 2025". Those are a vendor's numbers about its own market, so treat them as a map rather than a measurement, but the map matches what the vendors publish.
You can also build your own, and the best practitioner write-up on the SERP does exactly that. James Ives's Your Design System Needs An MCP Server (25 May 2026, updated 30 June 2026) exposes five tools: List Components, Get Component with props, slots and events, List Documentation, Get Documentation, and Get Component Examples. He builds it on @modelcontextprotocol/sdk, the Custom Elements Manifest for web components, and TypeScript AST parsing for Storybook stories. His argument for the work is the token argument: "Every token an AI wastes guessing how your components work is money left on the table."
At the small end, yajihum/design-system-mcp (25 stars, last pushed 14 April 2026) is a minimal example that "provides information about component props and design tokens". Useful to read if you want to see how little code the category needs.
Use it for: making an agent import your components with the right props instead of rebuilding them. Do not expect: it to help on a screen where the right component does not exist yet.
3. A server that knows your design files
The Figma MCP server is the one most teams meet first, and it is a different job: it reads a selection in a Figma file and hands the agent layout, text, component properties, variables and styles. Supernova's survey counts 24 published tools for it. Figma's own developer docs listed 35 tools plus one prompt when we went through them on 11 September 2026, so the counts differ by what each source counts as published. Either way, the full picture is in Figma MCP: 35 tools, the real limits, the missing layer.
Use it for: translating a specific frame into code. Do not expect: consistency across frames, because every read tool is scoped to the selection you point it at.
What you need in place before any of this is worth wiring
The guide that Google's AI Overview leans on hardest, Into Design Systems' Design Systems MCP guide, is blunt about sequencing: "Naming conventions, token taxonomy, component intent. Structure before automation." It recommends starting with 5 to 10 components rather than the whole library, and settling a parser strategy for turning documentation into structured JSON before you build anything.
Storybook makes the same point in code rather than prose. Its addon does nothing useful until you turn on features.componentsManifest in .storybook/main.ts, and most of its tools stay hidden unless the matching capability exists in your setup.
A short readiness test:
- ✅ You have a component library an agent could import from, published or local
- ✅ Components have typed props, documented slots or events, and names you would defend
- ✅ Tokens exist in one place with one naming scheme
- ❌ Your "design system" is a Figma file plus tribal knowledge, in which case an MCP will serve the agent your inconsistencies faster
- ❌ Nobody owns the library, in which case the server goes stale and the agent trusts stale answers
The limit every one of these shares
An MCP server is a query interface. The agent gets what it asks for, and the quality of the result depends on it asking.
Into Design Systems states the failure case exactly: "MCP only returns what you asked for. If the prompt says 'build me a card,' the LLM fills gaps with assumptions." The same guide notes that guidelines delivered this way are soft, "Guidelines are not laws", because a prompt usually wins over a guideline file.
That is the gap. An agent building a screen asks for the card, gets a faithful card, then invents the spacing around it, the heading size above it, the empty state inside it, and the hover treatment on the link, because none of those were a component it could query. Across twenty screens that is exactly how AI-generated product UI ends up looking almost right and uniformly generic, which is the pattern we traced in why AI-generated apps all look the same.
Headway reached a similar conclusion on 17 September 2026, framing it as audience: "A DESIGN.md file is for anyone who can't use your coded components" while "a design system MCP is for agents working in the same stack as your component library." They conclude "most organizations need both" and that "the best setup has one feeding the other."
That is right as far as it goes, and we would sharpen it on one point. The division is not only who the reader is, it is what kind of statement each artifact can make. An MCP answers questions about things that already exist. A rules file makes claims that apply to things that do not exist yet: the scale every new heading snaps to, the single accent you are allowed, the radius, the shadow policy, the density, what an empty state has to contain. No query can return a rule for a component nobody has built. A file in the repo that the agent reads on every task can.
The duply workflow
- Wire the MCP server for the layer you actually have. Component library in Storybook, use the addon. Design system platform, use its server. Figma files and no component library yet, the Figma MCP is the honest starting point.
- Put the rules that apply to every screen in a DESIGN.md your agent reads on every task. Tokens, type scale, spacing, elevation, density and the hard nos, in one file, in the repo, in version control.
- Start from a system that already holds together instead of writing one from a blank file. The duply library publishes production design systems as DESIGN.md files: see Linear, Stripe and Vercel.
- Give the agent both and check the first screen it produces against the rules, not against your taste. The full setup is in how to give your AI agent a design system.
FAQ
What is a design system MCP? A Model Context Protocol server that gives an AI coding agent structured access to design system information. The term covers three different things in practice: servers that index general design system knowledge such as W3C and WCAG material, servers that expose your own component library and tokens, and servers that read your design files. Only the second kind lets an agent import your real components.
What is an MCP in design? MCP is the Model Context Protocol, a standard way to connect an AI tool to a source of information. In design work it is how an agent reads a Figma selection, a component library or a documentation site directly instead of having a screenshot pasted into a chat window.
Which design systems have an MCP server? Per Supernova's August 2026 survey, Figma, Storybook, zeroheight, Knapsack and Supernova all ship one. Figma and Storybook are source tools, reading design files and code respectively. The other three are design system platforms serving tokens, components and documentation together. Plenty of teams also build their own in a few hundred lines.
Is there a design system MCP on GitHub?
Several. The most visible is southleft/design-systems-mcp (222 stars, MIT), which serves general design systems knowledge rather than your system. Storybook's addon now lives inside the main storybookjs/storybook monorepo at code/addons/mcp. yajihum/design-system-mcp is a minimal example of the serve-your-own-tokens pattern.
Do I need an MCP server for my design system? Only if you have a component library worth importing from. If your system is a Figma file plus conventions in people's heads, an MCP will serve the agent those gaps faster. Get naming, tokens and 5 to 10 documented components in order first, which is the sequencing Into Design Systems recommends.
Is a design system MCP better than a DESIGN.md file? They answer different questions. The MCP tells an agent how your existing components work, with real props and real tokens. A DESIGN.md states the rules for everything you have not built, which is most of any new screen. Headway's conclusion is that most organizations need both and that the best setup has one feeding the other, and that matches what we see in practice.
Will a design system MCP stop AI-generated UI looking generic? Partly, where a component exists. It will not fix the parts of a screen the agent invents, because an MCP returns only what was asked for. Consistency comes from rules that apply before any component is chosen.
Can Cursor or Claude Code use a design system MCP?
Yes. All of these are ordinary MCP servers, so any MCP client connects: Claude, Claude Code, Cursor, VS Code, Codex and the rest. Storybook's addon serves over streamable HTTP at /mcp on the dev server, and Southleft's runs as a hosted connector URL.
Summary
- "Design system MCP" means three different things: general design systems knowledge, your component library, or your design files
- The GitHub repo ranking second on the query is category one, a reference library of W3C and WCAG material at 395 entries, not a connection to your product
- Storybook, zeroheight, Knapsack and Supernova are the shipped examples of category two, per Supernova's August 2026 survey
- Figma MCP is category three and is scoped to the selection you point it at
- Nothing is worth wiring until naming, tokens and a handful of documented components are in order
- Every one of these is a query interface, so it covers what exists and leaves what the agent invents untouched
- The missing layer is rules that apply before a component is chosen, which is what a DESIGN.md is for
Start from a system that already holds together: browse the duply library.
Related reading