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 "Install 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-serverlist 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-server — the Edwson Design System over MCP
A read-only Model Context Protocol server that hands your design-system token + component contract to any AI agent (Claude Code, Codex, Cursor, …) as callable tools — so the whole org builds UI from one source of truth, the system auto-syncs, and your AI-token bill goes down instead of up.
This is the runnable backbone behind the "AI-Native Development" section of the design system showcase.
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 or two into the agent every turn, let it regenerate full hex/CSS, and correct it 2–3 times. That's ~10K+ input tokens × several loops per component.
This server instead serves targeted, reference-based, cache-friendly slices:
Mechanism | Effect on tokens |
Targeted retrieval — | a color slice is 78% smaller than the full token file (measured) |
Reference output — agent emits | output tokens drop sharply |
Contract correctness — | correction loops (the real cost driver) collapse toward 1 |
Deterministic + compact — same input → same small output | the static slice sits behind prompt caching |
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 (build), Storybook (docs), agents (MCP) — 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 (risk warnings, KYC gates, sign-off bars) carry their rule in the contract and are marked non-removable, so neither a human in a hurry nor an agent can ship the surface without them.
Related MCP server: my-design MCP Server
Tools (all read-only)
Tool | Returns |
| group names only (cheapest orientation) |
| only the requested token group |
| matching ids + one-line purpose |
| one component's full contract |
| data shape + required render states |
| version + per-file checksums |
| changed files since a version (auto-sync delta) |
Run
npm install
npm run build:manifest # regenerate manifest.json after any token/component change
npm start # speaks MCP over stdioRegister with an MCP client (example for Claude Code / Cursor 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.
Files
tokens.json token contract (color light/dark, space, radius, type, density)
components.json component contracts (purpose, when-to-use/not, props, a11y, regulatory, dataContract)
build-manifest.js auto-sync engine — hashes contracts -> manifest.json
server.js MCP server — read-only tools over stdio
manifest.json generated — version + SHA-256 per fileThis server cannot be installed
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Latest Blog Posts
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Edwson/eds-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server