eds-mcp-server
Auto-syncs token and component changes to Storybook documentation, ensuring design system docs stay up-to-date without manual rebuilding.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@eds-mcp-server list color tokens"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
eds-mcp — the Edwson Design System over MCP + HTTP
Your design-system token + component contract, served three ways from one engine — to AI agents (Model Context Protocol), to any app (a zero-dependency HTTP REST API with an OpenAPI spec), and to Node code (import the pure library). Not just to read, but to scaffold correct code, lint a proposed usage, discover components by the regulation they serve, and export the theme — one source of truth, auto-synced across the org, with your AI-token bill going down instead of up.
This is the runnable backbone behind the "AI-Native Development" section of the design system showcase.
MCP: 29 tools · 5 resources · 3 prompts HTTP: 29 REST endpoints · OpenAPI 3.1 Library: createCore()
65 institutional contracts across 14 domains **+ the Consumer Design System pack: 118 B2C categories across 11 domains** · reads + code-generation + linting + accessibility & compliance audits + flow composition + theme export + a machine-carried agent protocol👉 Fastest way to see what this is for:
npm run example. One plain-English requirement → a shipped, compliant, tested feature, in one command — eds-mcp drives the design-system spine of the whole intake → planning → PRD → R&D → QA → launch lifecycle and writes real artifacts at every stage. Walkthrough + a committed sample run:examples/lifecycle/.
Use it in one line
① As an MCP server — for AI agents (Claude Desktop / Code, Cursor, Codex). No install, no clone:
{ "mcpServers": { "eds": { "command": "npx", "args": ["-y", "github:Edwson/eds-mcp"] } } }Drop that into your MCP client config and the agent gains all 29 tools. (Once it's on npm:
"args": ["-y", "eds-mcp-server"].)
② As an HTTP REST API — for any language, any tool, curl, a browser. Runs with zero dependencies:
npx -y --package=github:Edwson/eds-mcp eds-mcp-http # or: git clone … && node http.js (no npm install needed)
curl localhost:8787/v1/theme/css # the dual-theme token CSS
curl localhost:8787/v1/regulation/FINRA%202111 # components that satisfy a rule
curl -X POST localhost:8787/v1/scaffold -d '{"component":"OrderTicket"}' # a method-compliant skeletonGET / lists every endpoint; GET /openapi.json is a full OpenAPI 3.1 spec you can load into Swagger or
Postman. Deploy it anywhere — or docker build -t eds-mcp . && docker run -p 8787:8787 eds-mcp.
③ As a library — in Node code. The pure engine, importable directly:
import { createCore } from 'eds-mcp-server'; // server, http, library: all the same core.jsRelated MCP server: @dsk/mcp
Why an enterprise adopts this (and doesn't leave)
1 · It cuts your AI-token spend. The expensive way teams use AI for UI today: paste a 6–15 KB CSS/theme file plus a screenshot into the agent every turn, let it regenerate full hex/CSS, and correct it 2–3 times. This server serves targeted, reference-based, cache-friendly slices — and goes further by generating the structure so the agent never invents it:
Mechanism | Effect on tokens |
Targeted retrieval — | a colour slice is ~78% smaller than the full token file |
Reference output — agent emits | output tokens drop sharply |
Generation — | the agent completes, it doesn't architect from scratch |
Contract correctness — | correction loops (the real cost driver) collapse toward 1 |
2 · It auto-syncs across the org. build-manifest.js hashes every contract file into
manifest.json (version + per-file SHA-256). Consumers compare their cached manifest and pull only
the changed files (diff_since). A token change propagates everywhere — apps, Storybook, agents —
without a rebuild, because everything references tokens, never literals.
3 · It enforces consistency + compliance. One signed manifest = one source of truth; checksums
prevent drift; SemVer gates breaking changes. Regulated components carry their rule in the contract;
lint_usage rejects hardcoded colours and non-canonical states before they ship; find_by_regulation
makes "which component satisfies FINRA 2111?" a one-call question.
Tools (29)
Every tool returns a text block and structuredContent (the same object, machine-parseable);
failures set isError: true instead of masquerading as data.
Tokens & theme
Tool | Returns |
| group names only (cheapest orientation) |
| only the requested token group |
| resolve one token by name + its canonical CSS var (theme-aware) |
| the whole token set as css · json · scss · tailwind (dual-theme) |
Component discovery
Tool | Returns |
| every id + purpose + domain + regulatory flags |
| one component's full contract |
| data shape + required render states |
| the four-cell register (when / when-not / a11y / regulatory) |
| ranked keyword search (id > domain/regulatory > purpose) |
| every component that serves a rule, e.g. |
| NL use case → ranked picks, each with its |
| resolve |
Generation & checks
Tool | Returns |
| a paste-ready skeleton: |
| issues by severity: unknown tokens, non-canonical states, hardcoded colours, inline styles |
| a dependency-free, runnable conformance test (tokens resolve · states canonical · anchors intact · a11y passes · CSS tokens-only) |
Accessibility, compliance & composition
Tool | Returns |
| static a11y audit against the contract (a11y text, error state, dual-theme lock-step, reduced-motion, anchor) + per-token contrast in both themes |
| the WCAG 2.1 contrast ladder for the token set, both themes, with AA / AA-large / AAA + a failures list |
| a jurisdiction ( |
| a dependency-resolved multi-component flow with a per-step decision register + the union of tokens + anchors |
Meta
Tool | Returns |
| version + per-file checksums |
| changed files since a version (auto-sync delta) |
| the nine non-negotiables + verification gates — the Ed-agent operating contract |
| version, component + domain counts, regulatory coverage, token count |
Consumer Design System pack (the second system, same engine)
The server also carries a bundled snapshot of the author's Consumer Design System
— 118 B2C component categories across 11 domains (commerce, social, media, onboarding, growth, trust & safety, and a
22-entry AI & Agents domain), each anchored to a public platform guideline (Apple HIG, Material 3, WCAG 2.2,
App Store / Play policy, GDPR, COPPA, FTC). The live contracts at edwson.com/cds/ are canonical; the snapshot makes
them deterministic offline.
Tool | Returns |
| the B2C catalogue — id, name, domain, anchor, canonical URL |
| one entry with its bundle obligations attached (paywall arrives owing a cancellation flow) |
| keyword search across names, summaries, domains, anchors |
| regulation-first discovery: "COPPA" → the entries + hard rules that answer to it |
| bundled-by-contract pairs — dependencies as data, not tribal knowledge |
| the machine-carried reading logic: seven-step read path + blockable hard rules |
Resources (5, whole-file)
eds://tokens · eds://components · eds://manifest · eds://method · eds://regulatory
(the last maps every regulation to the components that serve it).
Prompts (3, contract-grounded)
build-regulated-component {id} · compliance-review {regulation} · accessibility-audit {id} —
reusable workflows that wire the tools together the right way.
Integrations · The Agency (agency-agents)
eds-mcp ships a drop-in specialist for
The Agency — Matt Sitarzewski's open-source
(MIT) collection of AI agent personas. The Agency gives an agent a personality and a workflow;
eds-mcp gives it the design-system backend to build regulated UI and prove it. See
integrations/agency-agents/ for the
Regulated-Finance Design-System Engineer persona (authored in The Agency's open format) plus an
example MCP config. This is interoperability with attribution — no upstream files are copied or
redistributed; please support the upstream project.
HTTP REST API (for everyone who isn't an MCP client)
The same engine, over plain HTTP + JSON, zero dependencies (Node built-ins only — runs straight from
a clone with no npm install). CORS is open; every bad input returns { error } with a 4xx.
Method & path | Equivalent of |
| liveness · counts · the operating contract |
| token groups · a group · one token |
|
|
|
|
|
|
|
|
|
|
|
|
| self-describing index · OpenAPI 3.1 spec |
node http.js # serve on $PORT (default 8787) — no install required
npm run serve # same, via the package script
curl localhost:8787/v1/components?domain=payments
curl -s -X POST localhost:8787/v1/lint -d '{"tokens":["accent","nope"],"css":"a{color:#fff}"}'The killer move: scaffold_component
Ask for a component and get correct structure back, not a guess:
// scaffold_component { "id": "OrderTicket" } →
{
"prefix": "ot", "sectionId": "sec-order-ticket",
"tokensUsed": ["accent2","green","red","radius.md","space.4"],
"files": {
"html": "<section class=\"ds-section\" id=\"sec-order-ticket\">…four-cell register…</section>",
"css": ".ot-wrap{font-family:var(--type-font);color:var(--text1)} …tokens only, dual-theme…",
"js": "(function(){ var root=document.getElementById('ot-root'); … delegated, render-once … })();"
}
}The CSS it emits is guaranteed tokens-only (the test asserts zero hardcoded hex), the HTML carries the four-cell decision register, and the JS is a delegated, render-once, reduced-motion-safe stub — the Edwson method baked into the output.
Use it as a library (not only as an MCP server)
The logic lives in a pure, dependency-free core.js. Import it directly:
import { createCore } from 'eds-mcp-server'; // or './core.js'
import tokens from './tokens.json' assert { type: 'json' };
import components from './components.json' assert { type: 'json' };
const eds = createCore({ tokens, components });
eds.exportTheme('tailwind'); // → tailwind.config theme.extend
eds.scaffoldComponent('SuitabilityGate'); // → { files: { html, css, js } }
eds.lintUsage({ css: '.x{color:#f00}' }); // → { ok:false, issues:[{code:'hardcoded-color'…}] }
eds.findByRegulation('SEC 17a-4'); // → components with WORM-retention anchorsserver.js is a thin MCP adapter over the same core.js, so the MCP tools and the library API can
never drift apart.
Run from source
git clone https://github.com/Edwson/eds-mcp && cd eds-mcp
node http.js # HTTP REST API on :8787 — runs with NO npm install (zero deps)
npm install # only the MCP server (the SDK/zod) + the test suites need this
npm start # MCP server over stdio
npm run serve # HTTP API (same as node http.js)
npm run build:manifest # regenerate manifest.json after any token/component changeRegister the local MCP server with a client (mcp.json):
{ "mcpServers": { "eds": { "command": "node", "args": ["server.js"], "cwd": "./eds-mcp" } } }Requires Node 18+. The contract lives in tokens.json + components.json; edit those, re-run
build:manifest, and every consumer picks up the delta.
65 component contracts span fourteen domains — trading, compliance, payments, lending, wealth, identity, ai, ml,
ai-cost, data-eng, ai-infra, b2b, a11y, platform.
Quality & CI
Every push runs CI on Node 18 / 20 / 22: syntax check, ESLint, a manifest-drift check
(build-manifest must produce no diff), and three test suites — the dependency-free contract test
(npm test), the end-to-end MCP integration test that boots the real server over stdio and exercises
tools / resources / prompts through the SDK client (npm run test:mcp), and the HTTP API integration
test that boots the real REST server and hits every endpoint (npm run test:http).
npm run validate # everything CI runs, locally: build:manifest + lint + test + test:mcp + test:httpTyped (core.d.ts), MIT-licensed, SemVer-versioned (CHANGELOG). See
CONTRIBUTING, SECURITY, and runnable examples/.
Files
core.js pure engine — all logic, dependency-free, importable as a library + test-covered
core.d.ts TypeScript declarations for the library API
loadCore.js builds a ready core from the bundled JSON (shared by server, http, tests)
server.js thin MCP adapter — 29 tools + 5 resources + 3 prompts over stdio
http.js zero-dependency HTTP REST API — 29 endpoints + OpenAPI 3.1 (node http.js)
build-manifest.js auto-sync engine — hashes contracts -> manifest.json
tokens.json token contract (color light/dark, space, radius, type, density)
components.json component contracts (purpose, when-to-use/not, props, a11y, regulatory, dataContract)
consumer.json the Consumer Design System pack — 118 B2C entries + agentProtocol + bundles + hardRules
test.js dependency-free test — contract shape + manifest sync + full engine behaviour
test-mcp.js end-to-end integration test — boots the real MCP server, exercises it via the SDK client
test-http.js end-to-end integration test — boots the real HTTP API, hits every endpoint
manifest.json generated — version + SHA-256 per file
Dockerfile zero-dependency image for the HTTP API
.github/ CI workflow (Node 18/20/22), issue + PR templates, dependabot
examples/ library usage + an MCP client configAvailable Tools
29 toolsaudit_accessibilityAudit accessibilityC
Static accessibility audit of a component against its contract: a11y contract present, error state declared (status in words not colour alone), every colour token defined for both themes in lock-step, reduced-motion guard, regulatory anchor — plus a per-token contrast read in both themes. Verifies the contract, not a running DOM.
Inputs: id (required).
bundle_componentsBundle componentsC
Resolve requires transitively and return a dependency-ordered set (deps first) plus the union of tokens + regulatory anchors. For composing a surface.
Inputs: ids (required).
compliance_checkCompliance coverage checkC
Map a jurisdiction (us | eu | uk | au | sg | jp | global) and optional feature keywords to the regulatory anchors and guardrail components PRESENT in this design system. A coverage map for design, not legal advice.
Inputs: feature, jurisdiction.
compose_flowCompose a flowA
Assemble a multi-component flow from a list of ids: dependency-resolved order (deps first), per-step decision register, and the union of tokens + regulatory anchors across the flow. For building a KYC / order / onboarding surface end to end.
Inputs: ids (required), name.
contrast_reportContrast reportA
The WCAG 2.1 contrast ladder for the token set in both themes (or one): foreground tokens over backgrounds with AA / AA-large / AAA classification and a failures list. The machine version of the Accessibility Lab contrast checker.
Inputs: theme.
diff_sinceDiff since versionB
Given a consumer version, report whether a newer contract exists so it pulls only the delta. Auto-sync primitive.
Inputs: version (required).
export_themeExport themeA
Emit the whole token set as ready-to-use css | json | scss | tailwind. Dual-theme, self-consistent with scaffold_component variable names.
Inputs: format (required).
find_by_regulationFind by regulationA
Find every component that serves a given rule (e.g. "FINRA 2111", "NACHA", "SEC 17a-4"). Compliance-driven discovery.
Inputs: rule (required).
find_consumer_by_anchorFind consumer components by anchorB
Regulation-first discovery over the consumer catalogue: "COPPA" / "GDPR Art 7" / "FTC" / "WCAG" / "EU AI Act" returns the entries (and hard rules) that answer to it. Start from the rule, not the widget.
Inputs: rule (required).
get_agent_protocolGet the agent protocolB
The consumer system's machine-carried reading logic: the seven-step read path (discover → fetch index → select → read register → resolve bundles & hard rules → build from tokens → gate to a human) plus the hard rules that can BLOCK a build.
Inputs: no named parameters.
get_componentGet component contractC
Full contract: purpose, props, whenToUse/whenNot, a11y, regulatory anchors, tokens, dataContract.
Inputs: id (required).
get_consumer_bundlesGet consumer bundlesC
Bundled-by-contract pairs (paywall→cancellation, UGC→report & block, checkout→order tracking, agent-confirm→agent-trace). All of them, or the obligations of one id — include them unprompted.
Inputs: id.
get_consumer_componentGet a consumer componentC
One consumer entry with its bundle obligations attached (what it requires, what requires it). The when-not-to cell of the register at url is binding.
Inputs: id (required).
get_data_contractGet data contractC
The data shape + required render states (loading / empty / error / stale) for a component.
Inputs: id (required).
get_decision_registerGet decision registerD
The four-cell register (when to use / when not & instead / behaviour & a11y / regulatory) — the line between a kit and a system.
Inputs: id (required).
get_manifestGet manifestA
Version + per-file SHA-256 checksums for sync verification.
Inputs: no named parameters.
get_methodGet the methodB
The Edwson operating contract — the nine non-negotiables + verification gates that every component and scaffold satisfies. The Ed-agent in machine-readable form.
Inputs: no named parameters.
get_statsGet system statsA
System overview: version, component + domain counts, regulatory-framework coverage, token count.
Inputs: no named parameters.
get_tokenGet one tokenA
Resolve a single token by name (e.g. "accent2", "space.4", "radius.md") to its value(s) + canonical CSS var, theme-aware for color.
Inputs: name (required), theme.
get_tokensGet tokensA
Return only the requested token group (and theme for color). Avoids shipping the whole system.
Inputs: group (required), theme.
lint_usageLint a usageA
Validate a proposed usage against the system: token names must resolve, render states must be canonical, and CSS must be tokens-only (no hardcoded hex/rgb, no inline styles). Returns issues by severity.
Inputs: css, states, tokens.
list_componentsList componentsB
Every component id + purpose + domain + regulatory flags, optionally filtered by domain.
Inputs: domain.
list_consumer_componentsList consumer componentsA
The Consumer Design System (B2C sibling, 118 categories / 11 domains incl. a 22-entry AI & Agents domain). List entries — id, name, domain, platform anchor, canonical URL — optionally filtered by domain (e.g. "ai", "commerce", "growth").
Inputs: domain.
list_token_groupsList token groupsA
Token group names only — the cheapest way to orient before fetching values.
Inputs: no named parameters.
recommend_componentRecommend a componentA
Describe a use case in natural language; get ranked component recommendations, each with its whenNot warning so the agent avoids misuse.
Inputs: useCase (required), limit.
scaffold_componentScaffold a componentA
Generate a paste-ready, method-compliant skeleton (ds-section HTML + scoped tokens-only CSS + delegated reduced-motion-safe JS + the four-cell register) from a component contract. The killer tool: the agent gets correct structure, not invented structure.
Inputs: id (required).
scaffold_testScaffold a conformance testC
Generate a dependency-free, runnable contract-conformance smoke test for a component (tokens resolve, states canonical, regulatory anchors intact, a11y contract passes, scaffold CSS tokens-only). Ships the test discipline with the component.
Inputs: id (required).
search_componentsSearch componentsA
Ranked keyword search across id, domain, regulatory, purpose, whenToUse. Returns ids + purpose + score.
Inputs: query (required).
search_consumer_componentsSearch consumer componentsB
Keyword search across consumer names, summaries, domains and anchors, e.g. "paywall", "child", "cancel".
Inputs: query (required).
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 29 tools
Each tool targets a distinct resource or action: tokens, components, consumers, compliance, accessibility, scaffolding, etc. Even similar tools like 'search_components' and 'recommend_component' serve different query methods (keyword vs. natural language), eliminating ambiguity.
All 29 tools follow a consistent verb_noun pattern in snake_case (e.g., list_token_groups, get_component, bundle_components, scaffold_component). There are no deviations or mixed conventions.
29 tools is above the typical well-scoped range (3-15) and falls into the 'heavy' category (16-25+). While each tool serves a specific purpose, the count is borderline and could benefit from consolidation in some areas (e.g., multiple search/find tools).
The tool surface covers the full design system lifecycle: discovery (list, search, recommend), retrieval (get, find), validation (lint, audit, contrast), scaffolding, compliance, and versioning. No obvious gaps for an agent working with the system.
Maintenance
Related MCP Connectors
Give your agent a real design system: tokens, measured WCAG contrast, and rules to follow.
Give AI agents your deeepSpace design system: components, tokens, styles and code mappings.
1Governed app access for AI agents: 1,000+ apps & 12,000+ tools via Code Mode MCP.
Build and manage your design system with AI: tokens, themes, components, icons, Figma and code.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceMCP server that exposes your design system components and tokens to AI agents, preventing duplicate component creation and hardcoded token values.4 npm9MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that gives AI assistants structured access to a design system's tokens, components, guidelines, and patterns, enabling them to read, lint, and author design system data.1MIT
- FlicenseNot gradedqualityBmaintenanceThe Wellx Design System MCP enables AI agents to access the single source of truth for Wellx design, including tokens, component specs, rules, and search, ensuring consistent design implementation across surfaces.-
- AlicenseNot gradedqualityCmaintenanceMCP server for design tokens that gives AI agents read access to design systems, enabling token resolution, listing, and component usage lookups via natural language.Apache 2.0