Supernova MCP: Making Your Design System Readable by Every AI Agent

When AI Agents Meet Design Systems: A Overlooked Disconnect

Today's product teams can't live without AI assistants — agents in Figma, Cursor, Claude, ChatGPT — they're everywhere in development and design workflows. But there's an awkward reality: these agents have no idea what your design system looks like. So they guess, and they get things wrong — hardcoded colors, buttons built from scratch, completely divorced from your team's established standards.

Supernova's MCP (Model Context Protocol) solution targets exactly this pain point. Its core idea is to open a two-way channel between your design system and AI agents: agents can either do work inside Supernova on your behalf, or read from your design system to inform what they build. This means AI stops being a loose cannon and becomes a collaborator that's been properly fed your specification context.

MCP (Model Context Protocol) is an open standard proposed by Anthropic in late 2024, designed to solve the integration problem between large AI models and external tools and data sources. Before MCP, every AI application that needed to connect to an external system required custom connector code, leading to severe fragmentation. MCP provides a unified "client-server" communication specification: AI applications (clients) can discover and invoke tools and resources exposed by any MCP Server through a standardized interface, without caring about the underlying implementation. This protocol has been rapidly adopted by mainstream AI development tools like Cursor, Claude, and Windsurf, and is becoming the de facto standard for AI toolchain interoperability. By packaging a design system as an MCP Server, Supernova leverages this protocol's ecosystem advantage — any MCP-compatible AI client can connect directly, with no need to build separate integrations for each tool.

Two Types of MCP: The Editor/Consumer Split

Supernova's MCP architecture is divided into two layers with clean separation of concerns.

Editor MCP is for design system teams. Agents can perform virtually any operation you could do inside Supernova — updating component documentation, creating tokens, writing pages, and more. It's the write-side entry point, with elevated permissions.

MCP Server is for everyone else. Each server is a read-only slice of the design system, filtered for a specific team. In other words, what the React team sees is different from what the design team sees — each gets exactly what they need.

This "editor/consumer" separation is critical: it avoids dumping the entire system on every agent at once, preserving both security boundaries and signal-to-noise ratio.

Steps 1 & 2: Connect an Agent and Put It to Work

The connection process is designed to be lightweight. Open the overview in the sidebar, find the MCP card, and click connect — you can install it into Cursor, copy it for Claude Code, or copy the MCP URL for Codex, ChatGPT, or Figma. It covers virtually every major AI tool in use today.

Once connected, agents can genuinely participate in the workflow. Two concrete scenarios are demonstrated:

• A designer adds a critical new variant to a button in Figma, opens the agent right next to the frame and mentions Supernova, and the agent updates the button's documentation via the Editor MCP.
• An engineer asks Claude Code to add a spacing token and document it — the agent creates the token, writes the corresponding page, and asks for confirmation before publishing anything.

That "ask before publishing" detail is worth calling out — it keeps humans in the loop on key decisions rather than letting AI directly modify production content.

Step 3: Filter by Team, Create Dedicated MCP Servers

All design system data flows into Supernova, from which individual MCP Servers are derived. The creation flow is: open MCP servers in the sidebar, click the plus button, start from your design system, name it something like "React Team," and then filter the data.

The filtering can be quite granular. For documentation pages, for example, you can switch to manual mode and keep only the pages the React team actually needs. The direct benefit: agents receive less noise and return more accurate answers. This aligns with a well-established principle in LLM application design — more context isn't always better; precise, relevant context is what produces high-quality output.

Steps 4 & 5: Flexible Distribution and Usage Visibility

Once a server is created, distribution is flexible. You can either share a dedicated link via the distribution settings, or give everyone the same address — mcp.supernova.io/mcp — and let them choose their own server. When someone connects with that address, Supernova asks what they want to share; the user selects Consumer MCP, picks the React Team server, and approves — no special link required.

The before/after contrast is striking: without MCP, an agent can only guess at colors and build a button from scratch; with MCP connected, the agent uses color primary directly and imports your existing button component. Design system consistency is preserved.

Finally, there's observability. Open the MCP monitoring panel in the sidebar and you can see every tool call, who made it, and which MCP Servers are used most frequently across teams. This gives design system teams valuable usage data to determine which resources are genuinely needed.

Conclusion: Design Systems Are Becoming the Context Layer for AI

The value of Supernova MCP isn't in any single flashy feature — it's in how it redefines the role of design systems in the age of AI: upgrading from a specification document written for humans to a structured context layer fed to agents. The editor/consumer dual-layer architecture, per-team filtering, pre-publish confirmation, and usage observability combine to form a pragmatic, real-world solution.

For product teams already surrounded by AI tools, this solves a genuine collaboration friction: getting AI to understand "our conventions" rather than "some generic approach." As the MCP protocol spreads across more tools, this kind of tight binding between design systems and AI agents may well become standard practice for teams everywhere.

The concept of a "Context Layer" is becoming increasingly important in large language model application architecture. LLMs themselves don't store organization-specific knowledge — they rely on context injected at runtime to understand "who this team is and what standards they follow." Design systems are a natural carrier for this kind of structured private knowledge: they contain naming conventions, token hierarchies, component usage patterns, and the reasoning behind design decisions. Converting them into machine-readable context follows the same logic as RAG (Retrieval-Augmented Generation) in enterprise knowledge base applications: rather than relying on the model's generalization ability to guess the right approach, you inject the relevant specifications precisely at inference time. This also explains why "filtering by team" matters so much — feeding redundant context to a model doesn't just increase inference cost, it dilutes the relevant signal and degrades output quality.