一个位于 Figma MCP 前端的紧凑型 Markdown 层，专为 AI 实现工作流设计。
此 MCP 服务器接收 Figma 节点 URL，在内部调用 Figma Desktop MCP 的 get_design_context，并返回紧凑的 Markdown —— 剔除了那些在不增加实现价值的情况下增加 Token 成本的原始 React/Tailwind 透传代码。
在典型的设计上下文负载中，Token 减少约 45%（示例：1,053 → 582 tokens）。
User → implementation request + Figma node URL
→ figma-to-markdown MCP
→ Figma Desktop MCP (get_design_context + get_metadata)
→ compact markdown
→ implementation agent紧凑的输出保留了实现所需的重要信息：
保留 | 移除 |
源元数据 | 原始 React/Tailwind 透传代码 |
节点名称、类型、框架 | 重复的包装器样板代码 |
布局和间距规范 | 冗长的类属性转储 |
文本和排版事实 | |
资源引用 | |
实现说明 |
Related MCP server: figma-mcp-server
运行中的 Figma Desktop 应用程序
在 Figma Desktop 设置中启用了 Dev Mode MCP
包含所请求节点的文档必须是活动标签页
Node.js 18 或更高版本
无需安装步骤。使用 npx 即可按需运行：
npx figma-to-markdown-mcp或者，如果您愿意，也可以全局安装：
npm install -g figma-to-markdown-mcp在您的 MCP 客户端配置文件中注册该服务器。JSON 格式在不同客户端之间是相同的 —— 只有文件位置不同。
配置文件：~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"figma-to-markdown": {
"command": "npx",
"args": ["-y", "figma-to-markdown-mcp"]
}
}
}配置文件：.claude/settings.json（项目）或 ~/.claude/settings.json（全局）
{
"mcpServers": {
"figma-to-markdown": {
"command": "npx",
"args": ["-y", "figma-to-markdown-mcp"]
}
}
}配置文件：.cursor/mcp.json
{
"mcpServers": {
"figma-to-markdown": {
"command": "npx",
"args": ["-y", "figma-to-markdown-mcp"]
}
}
}配置文件：~/.codex/config.toml（全局）或 .codex/config.toml（项目）
[mcp_servers.figma-to-markdown]
command = "npx"
args = ["-y", "figma-to-markdown-mcp"]注册完成后，为您的代理提供一个 Figma 节点 URL 并要求其进行实现。
代理流程：
用户发送带有实现请求的 Figma 节点 URL。
代理使用该 URL 调用 get_design_context_compact。
此服务器在内部从 Figma Desktop MCP 获取设计上下文。
原始输出被压缩为 Markdown 并返回。
代理根据紧凑的 Markdown 进行实现。
仅当缺少事实时，代理才应回退到原始 Figma MCP 工具。
工具：get_design_context_compact
{
"figma_url": "https://www.figma.com/design/FILE_KEY/Name?node-id=123-456",
"include_stats": false
}参数 | 类型 | 必需 | 描述 |
| string | 是 | 包含 |
| boolean | 否 | 在输出中附加 Token 大小统计信息 |
输出示例：
# Figma Design Context
## Source
- provider: `figma-mcp`
- transformed-by: `figma-to-markdown`
- node-id: `123:456`
- file-key: `ExampleFileKey123`
- mode: compact implementation handoff
## Node Summary
- component: `BasicNavi`
- type: `instance`
- frame: `375 x 48`
## Compact Element Spec
- `basic navi` → flex, items center; bg `#f6f6f6 (neutral/100)`
- inner content row → flex, flex `1 0 0`, gap `8px`; px `10px`, py `4px`
## Text Spec
- text "Label" → font `Pretendard Regular`, size `19px`, line `24px`, color `neutral/900`file-key 从输入 URL 中提取以进行可追溯性分析。
get_metadata 作为补充并行获取，如果不可用，不会导致主请求失败。
当压缩置信度较低时，输出包含一个 ## QA Flags 部分。
默认省略原始上游代码。设置 include_stats: true 以查看负载大小。
Call this first for a Figma node URL. It fetches upstream Figma get_design_context internally, removes raw React/Tailwind passthrough, and returns compact markdown with layout, text, asset, and implementation notes.
| Name | Required | Description | Default |
|---|---|---|---|
| figma_url | Yes | Full Figma design URL including node-id query parameter, e.g. https://www.figma.com/design/FILE_KEY/Name?node-id=123-456 | |
| include_stats | No | Append markdown size statistics to the output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains that the tool internally calls get_design_context and removes raw React/Tailwind passthrough, providing relevant behavioral context. However, it does not disclose potential side effects, permissions needed, or rate limits, which are not critical for a read-only like operation but could be improved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys purpose, behavior, and output format without extraneous words. It could be slightly more structured, but it is efficient and front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema, the description does a good job summarizing the output as 'compact markdown' with specific content types. With 2 parameters and no nested objects, the description is sufficiently complete for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add extra meaning to the parameters beyond what the schema provides, but the schema descriptions are detailed enough. The description briefly mentions 'layout, text, asset, and implementation notes' which hints at output structure, but does not explain parameters specifically.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to be called first for a Figma node URL, fetching design context and returning compact markdown. It specifies the verb 'fetch' and resource 'Figma node URL', and distinguishes itself with a clear role as the initial call in a workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this first for a Figma node URL', establishing a clear usage precedence. However, it does not mention when not to use it or alternatives, which is acceptable given no sibling tools exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_design_context_compactScored across 1 tool
Only one tool exists, so no disambiguation is needed, but the lack of additional tools means any other functionality would be ambiguous.
Single tool name is descriptive and follows verb_noun pattern, scoring neutrally due to no other names to compare.
One tool for a domain like Figma design is far too few; users would need many more operations (e.g., list files, get components).
The single tool only fetches design context; no tools for creating, updating, or managing Figma resources, leaving major gaps.
Convert documents and web pages to clean Markdown: PDF, DOCX, XLSX, EPUB, scanned files, any URL.
Convert PDF, DOCX, HTML, and URLs to clean, LLM-ready markdown with tables preserved
High-fidelity PDF to structured Markdown conversion and document field extraction.
Web scraping for AI agents. Converts URLs to clean, LLM-ready Markdown with anti-bot bypass.
