← Volver al blog
7 min

Cómo sincronizo Figma con código en producción usando MCP servers

El handoff diseño → código murió en mi equipo. Llevo 6 meses con un flujo bidireccional Figma ↔ repo vía MCP. Esto es lo que aprendí.

MCPFigmaDesign SystemsIA

Durante 8 años, el handoff entre diseño y código fue siempre el mismo ritual: el diseñador entrega un Figma estático, el ingeniero lo abre, intenta replicarlo, y a la tercera revisión la fidelidad ya se perdió. Tokens distintos, paddings inventados, animaciones aproximadas. Es un problema viejo y la mayoría de equipos lo dan por irresoluble.

Llevo 6 meses con un flujo donde no hay handoff. Cualquier cambio en Figma llega al repo automáticamente, y cualquier cambio en código vuelve documentado al sistema de diseño. Esta es la versión completa.

Por qué MCP y no un export plugin

Los plugins de export Figma → código (tipo "DevMode" o "Anima") generan markup pero no integran con tu pipeline real: sigues teniendo que copiar, pegar, ajustar tokens. MCP (Model Context Protocol) es distinto: es un servidor que tu LLM (Claude, en mi caso) consulta directamente. Le pides "ajústame el componente X según el último Figma" y la IA tiene contexto en vivo del archivo.

La diferencia operativa es que el flujo deja de ser punctual ("voy a actualizar este componente") y pasa a ser continuo ("la IA mantiene el componente sincronizado en cada PR").

La arquitectura mínima

  • Servidor MCP que expone el archivo Figma vía API oficial (REST + Variables API).
  • Cliente: Claude Desktop / Cursor con el MCP configurado en `mcp.config`.
  • Repo Next.js con sistema de diseño en `src/components/ui/`.
  • Workflow GitHub Actions que detecta cambios en variables Figma y abre PR automáticamente.

El paso clave: tokens como variables Figma

Esto es lo que la mayoría de tutoriales obvia: para que la sincronización funcione, los tokens (colores, spacings, radios, fuentes) deben vivir como variables en Figma, no como estilos. Las variables tienen API; los estilos no de la misma manera. Si tu DS está en estilos, primero migra a variables. Es 1 día de trabajo y desbloquea todo el flujo.

Qué cambia para el equipo

Marketing y dirección dejan de pedirme "el último Figma" porque saben que el repo siempre está al día. Ingeniería deja de adivinar valores. Yo dejo de explicar lo mismo en standups. El tiempo que antes dedicaba a documentar handoffs lo dedico a diseñar nuevas features.

Dónde rompe

No es magia. Tres cosas que aprendí por las malas: (1) animaciones complejas siguen requiriendo trabajo manual — Figma no expresa "spring physics" todavía. (2) Componentes con lógica de negocio (formularios, validación) no se generan, solo el shell visual. (3) Si dos personas editan el mismo componente en paralelo (uno en Figma, otro en código), Git resolverá el conflicto pero la fuente de verdad puede divergir si no estableces convenciones claras.

El recurso que recomiendo

Si quieres montar esto sin perder un mes leyendo, lee primero la spec oficial de MCP (modelcontextprotocol.io) y luego la API de variables de Figma. Con esos dos documentos abiertos, en 2 días tienes una primera versión funcional. La inversión vale cada hora.

¿Te ha aportado algo?

Si te gusta cómo pienso, hablemos sobre cómo encajaría en tu equipo.

Reservar 30 min