Eine kompakte Markdown-Ebene vor Figma MCP für KI-Implementierungs-Workflows.
Dieser MCP-Server akzeptiert eine Figma-Knoten-URL, ruft intern get_design_context des Figma Desktop MCP auf und gibt kompaktes Markdown zurück – wobei rohe React/Tailwind-Durchreichungen entfernt werden, die die Token-Kosten erhöhen, ohne einen Mehrwert für die Implementierung zu bieten.
~45% Token-Reduzierung bei typischen Design-Kontext-Payloads (Beispiel: 1.053 → 582 Token).
User → implementation request + Figma node URL
→ figma-to-markdown MCP
→ Figma Desktop MCP (get_design_context + get_metadata)
→ compact markdown
→ implementation agentDie kompakte Ausgabe behält das bei, was für die Implementierung wichtig ist:
Beibehalten | Entfernt |
Quell-Metadaten | Rohe React/Tailwind-Durchreichungen |
Knotenname, Typ, Frame | Repetitive Wrapper-Boilerplate |
Layout- und Abstands-Spezifikationen | Ausführliche Klassenattribut-Dumps |
Text- und Typografie-Fakten | |
Asset-Referenzen | |
Implementierungshinweise |
Related MCP server: figma-mcp-server
Figma Desktop App muss ausgeführt werden
Dev Mode MCP in den Figma Desktop-Einstellungen aktiviert
Das Dokument mit dem angeforderten Knoten muss der aktive Tab sein
Node.js 18 oder neuer
Kein Installationsschritt erforderlich. Verwenden Sie npx und es wird bei Bedarf ausgeführt:
npx figma-to-markdown-mcpOder installieren Sie es global, falls bevorzugt:
npm install -g figma-to-markdown-mcpRegistrieren Sie den Server in der Konfigurationsdatei Ihres MCP-Clients. Das JSON-Format ist über alle Clients hinweg gleich – nur der Dateispeicherort unterscheidet sich.
Konfigurationsdatei: ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"figma-to-markdown": {
"command": "npx",
"args": ["-y", "figma-to-markdown-mcp"]
}
}
}Konfigurationsdatei: .claude/settings.json (Projekt) oder ~/.claude/settings.json (global)
{
"mcpServers": {
"figma-to-markdown": {
"command": "npx",
"args": ["-y", "figma-to-markdown-mcp"]
}
}
}Konfigurationsdatei: .cursor/mcp.json
{
"mcpServers": {
"figma-to-markdown": {
"command": "npx",
"args": ["-y", "figma-to-markdown-mcp"]
}
}
}Konfigurationsdatei: ~/.codex/config.toml (global) oder .codex/config.toml (Projekt)
[mcp_servers.figma-to-markdown]
command = "npx"
args = ["-y", "figma-to-markdown-mcp"]Sobald registriert, geben Sie Ihrem Agenten eine Figma-Knoten-URL und bitten Sie um eine Implementierung.
Agenten-Ablauf:
Der Benutzer sendet eine Figma-Knoten-URL mit einer Implementierungsanfrage.
Der Agent ruft get_design_context_compact mit der URL auf.
Dieser Server ruft intern den Design-Kontext vom Figma Desktop MCP ab.
Die rohe Ausgabe wird in Markdown komprimiert und zurückgegeben.
Der Agent implementiert basierend auf dem kompakten Markdown.
Nur wenn Fakten fehlen, sollte der Agent auf rohe Figma MCP-Tools zurückgreifen.
Tool: get_design_context_compact
{
"figma_url": "https://www.figma.com/design/FILE_KEY/Name?node-id=123-456",
"include_stats": false
}Parameter | Typ | Erforderlich | Beschreibung |
| string | ja | Vollständige Figma-URL inklusive |
| boolean | nein | Token-Größenstatistiken an die Ausgabe anhängen |
Beispielausgabe:
# 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 wird zur Nachverfolgbarkeit aus der Eingabe-URL extrahiert.
get_metadata wird parallel als Ergänzung abgerufen und führt nicht zum Abbruch der Hauptanfrage, falls nicht verfügbar.
Wenn das Vertrauen in die Komprimierung gering ist, enthält die Ausgabe einen ## QA Flags-Abschnitt.
Roher Upstream-Code wird standardmäßig weggelassen. Setzen Sie include_stats: true, um die Payload-Größe zu sehen.
Aktuelle Version: 1.0.0
Lizenz: 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.
