Design-Code Registry MCP
Design-Code Registry MCP
一个确定性的、与项目无关的 MCP 服务器,将设计组件、令牌和模式映射到它们的代码实现——适用于任何设计工具和任何框架。
它是 Figma Code Connect 的一个轻量级、对 git 友好的替代方案,作为一个通用知识层构建,任何兼容 MCP 的 AI 编码代理(Claude Code、Cursor、Codex、OpenCode 等)都可以查询它。
Figma Design ↕ Design Component / Token / Pattern ↕ Code Implementation为什么存在
AI 编码代理擅长编写代码,但不擅长知道"这个项目是否已经有 Button 组件,如果有,它叫什么名字、在哪里?"如今,这些知识要么存在于代理的模糊推断中(不可靠),要么与某个特定设计工具 + 框架的组合紧密耦合(Figma Code Connect,仅支持 React/Figma)。
核心原则:精确的注册表数据胜过 AI 推断。 如果注册表中有明确的映射,代理就不应该需要猜测。如果没有,代理应该被告知"未解析",而不是凭空编造。
这个项目是:
不是 AI 模型。 它是一个通过 MCP 工具暴露的结构化知识层。
不是向量数据库 / RAG。 解析仅限精确匹配(id、设计引用、规范名称、别名)——绝不用嵌入或模糊相似度。
不绑定任何框架或设计工具。 React、Vue、Svelte、SwiftUI、Flutter、HTML——以及 Figma、Sketch、Penpot 或任何其他工具——在模式中都只是字符串,而不是代码中的特例。
架构
AI Agent (Claude Code, Cursor, ...)
│
↓
MCP Protocol (stdio)
│
↓
Design-Code Registry MCP (this package — the generic engine)
│
FileRegistryProvider
│
┌──────────────┼──────────────┬─────────────┐
↓ ↓ ↓ ↓
components.json tokens.json patterns.json rules.json
│
.design/registry/ (your project — the data)服务器(这个 npm 包)是通用的,可以在完全不同的项目中复用。注册表(你项目中的 .design/registry/)存放所有项目特定的事实,以纯 JSON 文件形式存在,在 git 中可读、可 diff、可合并。
注册表概念
概念 | 文件 | 捕获的内容 |
清单 |
| 模式版本、项目信息、主要设计工具。 |
组件 |
| 一个设计组件(例如 Button)→ 一个或多个代码实现,跨语言/框架。 |
令牌 |
| 一个设计令牌(颜色、间距、排版等),具有稳定的 id 和值。 |
模式 |
| 组件的更高级组合(例如"空状态"= message + Button)。 |
规则 |
| 代理必须遵守的结构化项目决策(例如"复用 Button,不要创建新的")。 |
一个组件可以有多个实现——同一个设计概念同时映射到 React、Vue、SwiftUI 和 Flutter,如果你的项目需要的话:
{
"id": "button",
"name": "Button",
"implementations": [
{ "language": "typescript", "framework": "react", "component": "Button", "sourcePath": "src/components/Button.tsx" },
{ "language": "dart", "framework": "flutter", "component": "AppButton", "sourcePath": "lib/widgets/app_button.dart" }
]
}设计引用也是通用的——tool 是一个开放字符串,而不是枚举,因此为新的设计工具添加支持永远不需要模式迁移:
{ "tool": "figma", "fileId": "abc123", "nodeId": "12:340", "url": "https://figma.com/file/abc123?node-id=12-340" }参见 src/schema/ 获取完整、带注释的模式(Zod),以及 examples/fictional-project/ 获取完整的示例。
确定性解析
registry_find_by_design_reference 和底层解析器从不猜测。它们按以下固定顺序尝试,并在第一个产生匹配的策略处停止:
精确设计引用(tool + node/file/url/name)
精确注册表 id
精确规范名称
显式别名
否则:
unresolved
如果某个策略匹配到多个组件,解析在该处停止并报告 ambiguous,同时列出所有候选——它从不静默地选一个:
// unresolved
{ "status": "unresolved" }
// ambiguous
{ "status": "ambiguous", "strategy": "alias", "candidates": [ /* ... */ ] }
// resolved
{ "status": "resolved", "strategy": "design-reference", "component": { "id": "button", /* ... */ } }MCP 工具
读取
工具 | 用途 |
| 获取注册表元数据(模式版本、项目、设计工具)。 |
| 列出组件,可选地按状态/标签过滤。 |
| 按精确 id 获取一个组件。 |
| 在 id/名称/别名/标签中进行确定性子字符串搜索。 |
| 将设计工具引用解析为组件(见上文)。 |
| 列出令牌,可选地按类别过滤。 |
| 按精确 id 获取一个令牌。 |
| 列出 UI 模式。 |
| 按精确 id 获取一个模式。 |
| 获取完整的结构化规则文档。 |
| 运行完整的注册表验证(见下文)。 |
写入
工具 | 用途 |
| 创建新的入门注册表。如果已存在则失败(除非使用 |
| 创建组件。如果 id 重复则失败。 |
| 修补现有组件。如果 id 不存在则失败。 |
| 将组件标记为已弃用(不存在破坏性删除)。 |
| 相同的创建/更新契约,用于令牌。 |
| 相同的创建/更新契约,用于模式。 |
| 替换完整的规则文档(发送完整的期望列表)。 |
变更安全性: 创建已存在的 id 是错误(请使用 update);更新不存在的 id 是错误(请使用 create);组件没有破坏性删除——请使用 registry_deprecate_component,以便历史记录在 git 中保留。
验证
registry_validate(以及 CLI 中的 design-code-registry validate)检查整个注册表:
组件/令牌/模式/规则内的重复 id
重复的设计引用(两个组件声称拥有同一个 Figma 节点)
损坏的引用(模式指向不存在的组件、弃用的
replacedBy指向空、规则的appliesTo.id指向空)循环模式引用(模式 A → 相关模式 B → 相关模式 A)
已批准组件缺少实现(警告,不是错误)
{
"valid": false,
"errorCount": 1,
"warningCount": 0,
"issues": [
{ "severity": "error", "code": "BROKEN_REFERENCE", "message": "Pattern \"empty-state\" references component \"buton\", which does not exist.", "location": "pattern:empty-state" }
]
}CLI
面向人类的界面,使用与 MCP 工具相同的 RegistryService——两者之间的行为永远不会漂移。
npx design-code-registry-mcp init --name "My Project" --design-tool figma
design-code-registry validate
design-code-registry list components --status approved
design-code-registry list tokens --category color
design-code-registry list patterns
design-code-registry add component --id button --name Button
design-code-registry add token --id color-primary --name "Primary" --category color --value "#3B5BFF"
design-code-registry add pattern --id empty-state --name "Empty State" --components button每个命令都接受 -p, --path <path> 来指向特定注册表,或读取 DESIGN_REGISTRY_PATH。
安装
npm install -g design-code-registry-mcp
# or, without installing:
npx design-code-registry-mcp initClaude Code 设置
将服务器添加到你的 Claude Code MCP 配置中(项目根目录的 .mcp.json,或通过 claude mcp add):
{
"mcpServers": {
"design-code-registry": {
"command": "npx",
"args": ["-y", "design-code-registry-mcp"]
}
}
}或者,使用显式注册表路径(在 monorepo 中很有用):
{
"mcpServers": {
"design-code-registry": {
"command": "npx",
"args": ["-y", "design-code-registry-mcp", "--registry-path=./packages/design-system/.design/registry"]
}
}
}服务器通过 stdio 与任何兼容 MCP 的客户端一起工作——Claude Code 只是众多客户端之一,而不是服务器本身的依赖。
Figma MCP 集成
这个服务器不与 Figma API 通信,也不检查 Figma 文件——那是 Figma 自己的 MCP 服务器 的工作。两者被设计为互补的:
Figma MCP → design context (fileKey, nodeId, ...) → Design-Code Registry MCP → explicit mapping → AI agent → code典型的代理工作流程:
代理向 Figma MCP 请求所选节点的
fileKey/nodeId。代理使用这些标识符在此服务器上调用
registry_find_by_design_reference。如果
resolved,代理复用返回的实现。如果unresolved,代理可以(根据你项目的规则)提议新组件,并使用registry_create_component注册它。
多框架示例
单个注册表可以描述完全不同的代码库中的实现:
Button (design concept)
├── React → src/components/Button.tsx
├── Vue → src/components/Button.vue
├── SwiftUI → Sources/Button.swift
└── Flutter → lib/widgets/app_button.dart服务器不会因为你的项目使用其中哪一个而改变——模式将 language 和 framework 视为开放字符串。
示例项目
examples/fictional-project/ 包含一个完整、经过验证的示例注册表(Button、Input、Card、Modal、两个模式、七个令牌、五条规则),用于一个虚构的"Aurora Design System"。从那里复制 .design/registry/ 作为起点,或运行:
cp -r examples/fictional-project/.design .AI 代理使用契约
连接到这个服务器的代理应该:
在创建任何可复用的 UI 组件之前查询注册表。
首先解析精确映射——永远不要猜测可能存在的映射。
复用现有的已注册实现,而不是重复它们。
在生成样式/布局之前读取相关令牌和模式。
诚实地报告
unresolved,而不是编造映射。当
registry_find_component/registry_find_by_design_reference显示等效组件已存在时,永远不要创建新的规范组件。仅在没有合适的现有组件时才提议新组件。
将所有注册表变更视为明确、有意的操作——而不是偶然的副作用。
将注册表视为项目特定 Design ↔ Code 事实的权威来源。
同时,注册表并不拥有良好的工程判断力:当它不完整或明显有更可维护的方法时,代理应该说出来——区分已验证的注册表事实、推断的信息和建议——而不是机械地服从一个不完整的注册表。
开发
npm install
npm run build # compile TypeScript → dist/
npm test # build + run the full vitest suite (56 tests, including a real stdio subprocess e2e test)
npm run lint
npm run typecheck在提交 PR 之前,请参阅 CONTRIBUTING.md 了解项目的设计原则。
限制与未来改进
目前只提供本地、基于文件的注册表提供程序。
RegistryService层与提供程序无关,因此远程/API 支持的提供程序是可能的,无需触及 MCP 工具逻辑——只是尚未实现。还没有可选的 HTTP/SSE 传输(仅 stdio),遵循"不要过度设计第一版"的原则。
registry_find_component是确定性子字符串搜索,不是排名/模糊搜索——这是有意为之,但意味着非常宽松的查询可能返回空结果,而人类会期望近似匹配。没有内置的 Figma/Sketch/Penpot API 客户端——这个服务器有意保持在 Figma MCP 等工具的下游,而不是重复它们的工作。
许可证
This 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.
Related MCP Connectors
Connect AI coding agents to Anima Playground, Figma, and your design system.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
UI design from prompts, screenshots, and URLs for AI coding agents and theme tokens.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/mrasadi/design-code-registry-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server