Figma MCP para design systems: el circuito diseño-código sin handoff

Qué es el Figma MCP

Figma expone un servidor Model Context Protocol que permite a un agente leer archivos de diseño: frames, componentes, variables, estilos y sus propiedades. El cliente (Claude Code, Cursor o cualquier agente compatible con MCP) consulta el archivo en vivo y razona sobre lo que hay, en lugar de trabajar desde una captura de pantalla o una descripción.

El cambio de fondo: el handoff deja de ser un documento y pasa a ser una consulta. El agente no recibe “el diseño dice 16px de padding”; pregunta al archivo cuánto padding tiene el frame y de qué variable viene. La especificación deja de ser un PDF que envejece y pasa a ser el propio archivo, consultado en el momento.

Cómo se conecta

El servidor MCP de Dev Mode corre desde la aplicación de escritorio de Figma, no en la nube. Lo activas en Dev Mode y queda sirviendo en un endpoint local (un servidor SSE en 127.0.0.1). Después registras ese endpoint en tu cliente:

// Claude Code · .mcp.json
{
  "mcpServers": {
    "figma": {
      "url": "http://127.0.0.1:3845/sse"
    }
  }
}

A partir de ahí el contexto lo marca tu selección: seleccionas un frame o un componente en Figma y el agente trabaja sobre esa selección. No le das una URL larga; le das foco. Esto importa porque el agente no necesita cargar el archivo entero para responder sobre un botón.

Qué expone exactamente

No es “dame el diseño” en bloque. Son consultas acotadas, cada una con un propósito:

Código de la selección. El servidor genera una primera implementación del frame seleccionado. Es un punto de partida, no el entregable: lo interesante es que parte de la estructura real, no de una foto.
Definiciones de variables. Devuelve qué variables y tokens usa la selección, con sus valores. Aquí es donde el circuito gana sentido: el agente ve spacing/md = 16 en vez de 16px a secas.
Imagen de la selección. Una representación visual para que el agente contraste lo que lee con lo que se ve. Útil cuando la estructura y el render no coinciden.
Mapa de Code Connect. Si tienes Code Connect configurado, devuelve a qué componente de código corresponde cada componente de Figma. Esta es la pieza que cierra el circuito de verdad.

El circuito completo

Figma (variables + componentes)
   │  Figma MCP
   ▼
Agente (Claude Code / Cursor)
   │  consulta también el MCP del design system
   ▼
Código (componentes con tokens del sistema)

El matiz que separa una demo de un flujo de producción está en la segunda consulta. Un agente con acceso solo a Figma reproduce lo que ve: valores literales. Un agente con acceso a Figma y al servidor MCP de tu design system puede mapear: “este #2563EB del frame corresponde al token color.action.primary del sistema, uso el token”.

Sin esa segunda fuente, el agente produce código que se parece al diseño pero no pertenece al sistema: colores quemados, espaciados sueltos, componentes que reimplementan lo que ya existe. Con ella, produce código que un revisor reconoce como propio.

Qué necesita tu design system para que esto funcione

Variables de Figma alineadas con los tokens. Si las variables del archivo se llaman como los tokens del sistema (o mapean vía convención documentada), el agente resuelve la correspondencia sin heurísticas. Si el archivo usa estilos sueltos con valores directos, el agente solo puede adivinar.
Un servidor MCP propio del sistema que exponga los tokens vigentes y la API de componentes. Cómo montarlo está en la guía de MCP servers.
Componentes de Figma con nombres que existan en código. El agente que ve Button/Primary en Figma y encuentra Button variant="primary" en el sistema cierra el circuito. Rectangle 347 no cierra nada.
Code Connect, si lo tienes. Es lo que convierte “esto se parece a un botón” en “esto es <Button>”. Sin Code Connect el agente infiere por nombre; con él, lo sabe.

Una consulta real

El valor no está en “genérame la pantalla”. Está en pedir lo que un humano tardaría en cruzar a mano:

Lee la selección. Para cada color, espaciado y tipografía, dime si corresponde a un token del sistema (consulta el MCP del design system) o si es un valor suelto. Devuélveme solo las divergencias.

La respuesta útil no es código: es una lista de tres líneas que dice dónde el diseño se ha salido del sistema. Eso es el drift, y antes aparecía en QA dos semanas después.

Flujo de trabajo realista (equipo de DS)

Auditoría de drift. Pedir al agente que compare las variables del archivo Figma con los tokens del sistema y liste las divergencias. Es la tarea con mejor relación valor/esfuerzo de todo el circuito: el drift diseño-código que antes se descubría tarde aparece en minutos.
Implementación de variante. El diseñador publica la variante en Figma; el agente la lee, la mapea a tokens y propone el PR. La revisión humana sigue siendo obligatoria.
Documentación sincronizada. Generar la tabla de props y tokens de la página de documentación desde el archivo y el código a la vez, marcando inconsistencias en lugar de ocultarlas.

Límites honestos

El MCP de Figma lee; no sustituye el criterio sobre qué merece ser componente.
Archivos desordenados producen respuestas desordenadas: el agente amplifica la calidad (o la falta de ella) de la estructura del archivo.
La correspondencia variable-token es tan buena como tu disciplina de nomenclatura. El protocolo no arregla un sistema mal nombrado; lo expone.
Es un punto de partida, no un autopiloto. El código que devuelve necesita el mismo ojo crítico que cualquier PR. Lo que cambia es de dónde parte la conversación, no quién decide.

Ver también

El circuito Figma MCP + Claude Code + servidor propio se monta sobre tu sistema real en el bootcamp, de la semana 3 a la 8.