AI実装ワークフローのための、Figma MCPのフロントに位置するコンパクトなMarkdownレイヤーです。
このMCPサーバーはFigmaノードのURLを受け取り、内部でFigma Desktop MCPの get_design_context を呼び出し、コンパクトなMarkdownを返します。実装の価値を生まないのにトークンコストを増大させる、生のReact/Tailwindのパススルーを除去します。
一般的なデザインコンテキストのペイロードで 約45%のトークン削減 を実現します（サンプル: 1,053 → 582トークン）。
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-mcpMCPクライアントの設定ファイルにサーバーを登録します。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 | いいえ | 出力にトークンサイズの統計情報を付加する |
出力例：
# 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 を設定してください。
現在のバージョン: 1.0.0
ライセンス: MIT
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.
