Una capa compacta de markdown frente a Figma MCP para flujos de trabajo de implementación con IA.
Este servidor MCP acepta una URL de nodo de Figma, llama internamente a get_design_context de Figma Desktop MCP y devuelve un markdown compacto, eliminando el código React/Tailwind sin procesar que aumenta el costo de tokens sin añadir valor a la implementación.
~45% de reducción de tokens en cargas útiles de contexto de diseño típicas (ejemplo: 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 agentLa salida compacta mantiene lo que importa para la implementación:
Conservado | Eliminado |
Metadatos de origen | Código React/Tailwind sin procesar |
Nombre del nodo, tipo, marco | Código repetitivo de envoltorio |
Especificaciones de diseño y espaciado | Volcados extensos de atributos de clase |
Datos de texto y tipografía | |
Referencias de activos | |
Notas de implementación |
Related MCP server: figma-mcp-server
Aplicación Figma Desktop en ejecución
Dev Mode MCP habilitado en la configuración de Figma Desktop
El documento que contiene el nodo solicitado debe ser la pestaña activa
Node.js 18 o superior
No se requiere paso de instalación. Usa npx y se ejecutará bajo demanda:
npx figma-to-markdown-mcpO instálalo globalmente si lo prefieres:
npm install -g figma-to-markdown-mcpRegistra el servidor en el archivo de configuración de tu cliente MCP. El formato JSON es el mismo en todos los clientes; solo cambia la ubicación del archivo.
Archivo de configuración: ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"figma-to-markdown": {
"command": "npx",
"args": ["-y", "figma-to-markdown-mcp"]
}
}
}Archivo de configuración: .claude/settings.json (proyecto) o ~/.claude/settings.json (global)
{
"mcpServers": {
"figma-to-markdown": {
"command": "npx",
"args": ["-y", "figma-to-markdown-mcp"]
}
}
}Archivo de configuración: .cursor/mcp.json
{
"mcpServers": {
"figma-to-markdown": {
"command": "npx",
"args": ["-y", "figma-to-markdown-mcp"]
}
}
}Archivo de configuración: ~/.codex/config.toml (global) o .codex/config.toml (proyecto)
[mcp_servers.figma-to-markdown]
command = "npx"
args = ["-y", "figma-to-markdown-mcp"]Una vez registrado, proporciona a tu agente una URL de nodo de Figma y solicita una implementación.
Flujo del agente:
El usuario envía una URL de nodo de Figma con una solicitud de implementación.
El agente llama a get_design_context_compact con la URL.
Este servidor obtiene el contexto de diseño de Figma Desktop MCP internamente.
La salida sin procesar se compacta en markdown y se devuelve.
El agente realiza la implementación a partir del markdown compacto.
Solo si faltan datos, el agente debe recurrir a las herramientas nativas de Figma MCP.
Herramienta: get_design_context_compact
{
"figma_url": "https://www.figma.com/design/FILE_KEY/Name?node-id=123-456",
"include_stats": false
}Parámetro | Tipo | Requerido | Descripción |
| string | sí | URL completa de Figma incluyendo el parámetro de consulta |
| boolean | no | Añadir estadísticas de tamaño de tokens a la salida |
Ejemplo de salida:
# 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 se extrae de la URL de entrada para trazabilidad.
get_metadata se obtiene en paralelo como complemento y no hará fallar la solicitud principal si no está disponible.
Cuando la confianza en la compactación es baja, la salida incluye una sección ## QA Flags.
El código original ascendente se omite de forma predeterminada. Establece include_stats: true para ver el tamaño de la carga útil.
Versión actual: 1.0.0
Licencia: 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.
