MCP
The substrate exposes a Model Context Protocol (MCP) JSON-RPC server alongside the pages you're reading right now, plus a small set of plain GET endpoints for agents that don't need the full MCP envelope. Point an MCP-capable agent at it and it can query components, tokens, and research notes directly — no separate service to stand up, no copy of the registry to keep in sync by hand.
On-prem MCP endpoint
This same binary exposes a Model Context Protocol (MCP) server alongside the pages you're reading right now. Point an MCP-capable agent at it and it can query components, tokens, and research notes directly — no separate service to stand up, no copy of the registry to keep in sync by hand.
Runs on your own infrastructure
The MCP server ships inside the same binary as this documentation site. When you run
it on your own hardware, every tool call — from a single get_token lookup
to a full list_components sweep — is answered locally. Nothing about your
codebase, your prompts, or which components an agent is asking about is sent to any
third party; it never leaves your own network.
There is no hosted alternative — on-prem, as described on Self-host, is the only way this surface is offered.
list_components(category?)
Returns every component the registry currently knows about, optionally filtered by origin category (generic substrate, GIS-origin, wiki-engine-origin), with a pointer to its full recipe.
get_component_recipe(name)
Returns the HTML/CSS recipe, token dependencies, and accessibility targets for one named component — the same data a human reads on its Components page.
get_token(name)
Resolves a single design token by its CSS custom property name
(--cds-interactive) or DTCG path (semantic.interactive-primary).
search_design_system(query)
Full-text search across every indexed vault document — components, tokens, research, guidelines, developing, designing, about — for an agent that doesn't yet know the exact name of what it needs.
Registry / machine API
There is no single aggregate registry file to fetch. Component recipes, the token bundle, and full-text search are three separate real endpoints — verified directly against the running server's own route table.
curl -s https://design.pointsav.com/mcp \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_component_recipe","arguments":{"name":"button"}}}'{
"jsonrpc": "2.0",
"id": 1,
"result": {
"content": [{ "type": "text", "text": "{ ...recipe.json, as a string... }" }]
}
}curl -s https://design.pointsav.com/components/button/recipe.json/mcp, /components/:slug/recipe.json, and
/tokens/search all read the same vault files every human-facing page on
this site renders from. There is no second copy of this data to fall out of sync.
DTCG token export
Agents that only need the token values — not full
component recipes — can pull the registry's DTCG-format export directly, without going
through /mcp at all.
Why this matters
Every endpoint on this page — /mcp,
/components/:slug/recipe.json, /tokens/search,
/bundles/tokens/* — reads from the same registry that drives every other
page on this site, including the token counts and swatches on
Tokens. There is no separate code path reserved for machines.
Important Information
Design System disclosure
This site provides open-source design tokens, documentation, and self-hostable software published by Woodfine Capital Projects Inc. Information here is for general reference only and does not constitute an offer, warranty, or a guarantee of fitness for any particular purpose. Statements regarding planned, intended, or targeted future features are forward-looking and subject to change without notice; they are not undertaken to be updated except as required by law.