Adding an MCP server to your design system
A production-angle look at exposing a design system through the Model Context Protocol — what it actually gets you, where it falls apart, and what to ship first.
· Abstract — full post in progress
This is an abstract. The full post is in progress.
Most of what’s been written about MCP and design systems is “what if?”. This post is from the other side — having shipped an MCP server in front of a 11-team enterprise design system and watched what happened when real users hit it.
The full post will cover:
- What MCP actually adds beyond a docs site. When the model can read your component schemas at request time, prompts get shorter and outputs get more reliable. But not all schemas are worth exposing.
- The schema mapping problem. Your design system’s components were written for humans. Their props weren’t shaped to be tool inputs. What you change, what you wrap, and what you leave alone.
- Token economics. A 200-component DS does not fit in a prompt. How to scope an MCP response so the model gets enough context without blowing the context window.
- Versioning. Your DS ships breaking changes. Your MCP server has to speak to multiple versions of those components without confusing the model.
- Discoverability vs determinism. When you give the model a search tool it will use it creatively. Sometimes that’s good. Sometimes it invents components.
Until then, see the Gen UI demo on this site for one half of what an MCP-backed flow looks like in practice.