Why it matters
The agent stays on-system without carrying the registry
Pasting the whole component library into a prompt is expensive and goes stale the moment the registry changes. The MCP server flips that: the agent queries components, tokens, and the design rule live, so its context stays small and always current. It authors against the real source instead of a remembered approximation.
This is one third of the on-system loop. The design rule tells the agent what on-system looks like, the server hands it the live primitives and foundation tokens to build with, and the lint catches anything that drifts off-system before it ships.
Install
Add the server to your MCP host
Drop this config into your MCP host (Cursor, Windsurf, Claude Desktop, or any MCP-compatible client). No global install needed, npx pulls the package on first use.
Tools
Six tools exposed to the agent
Every tool is read-only. The server never writes to the consumer's project, it only surfaces information the agent needs to stay on-system.
- search_componentsFull-text search across all registry components and their metadata.
- get_component_sourceFetch the raw source of any registry component by slug.
- check_on_systemCheck a TSX snippet for off-system code (raw colors, foreign primitives, missing house utilities). Returns violations with line numbers.
- get_design_ruleReturn the full byronwade-ui.mdc design rule so the agent stays on-system.
- list_design_tokensList every CSS custom property defined in the foundation token set.
- list_house_utilitiesList all house utility classes (bg-grid, glow-brand, text-gradient, mask-fade-x, …).
Supported hosts
Anywhere that speaks MCP
The same mcpServers block from installation works in any Model Context Protocol client.
- CursorAdd to .cursor/mcp.json or the global MCP config.
- WindsurfAdd under mcpServers in the Cascade settings.
- Claude DesktopAdd to claude_desktop_config.json, then restart.
- Any MCP-compatible clientSame JSON, anywhere the Model Context Protocol is spoken.
How an agent uses it
A typical on-system flow
Asked for a status indicator, the agent searches first, reads the real source, checks whether it is already installed, then pulls the rule and tokens so the markup it writes never drifts off-system.
Pairs with
The rest of the on-system toolchain
The server is most useful alongside the other two halves of the loop. The AI design rule ships the conventions the agent reads through get_design_rule, and the on-system lint enforces them in CI — turning the same guidance the agent consumed into a hard gate. Rule, server, and lint share one source of truth.