MCP — Model Context Protocol — permite que los agentes de IA hagan llamadas a herramientas en tiempo de ejecución a servicios externos. Figma publica un servidor MCP oficial, y la comunidad ha construido varios más. La propuesta: tu agente puede pedirle a Figma datos de diseño directamente, a demanda, en medio de una conversación. Sin paso de exportación. Siempre en vivo.

figmascope hace la apuesta arquitectónica opuesta: exporta una vez, envía un bundle, nunca vuelvas a conectar. Estas son elecciones genuinamente diferentes con implicaciones distintas. Aquí está lo que cada una realmente cuesta y gana.

Qué es el servidor MCP de Figma

Model Context Protocol es el estándar abierto de Anthropic para conectar agentes de IA a herramientas externas mediante una interfaz de servidor. Un servidor MCP expone herramientas tipadas que el agente puede llamar: "get_file," "get_node," "get_styles," etc. Cuando el agente necesita contexto de diseño, llama a la herramienta, el servidor MCP llama a la API de Figma, y el resultado regresa como contexto para el prompt actual.

El servidor MCP oficial de Figma cubre lectura de archivos, inspección de nodos, recuperación de componentes y acceso a comentarios. Los servidores MCP de la comunidad (hay varios en GitHub) extienden esto con esquemas personalizados, transformaciones adicionales o alcances más estrechos optimizados para flujos de trabajo de agentes específicos.

Para usar cualquier servidor MCP de Figma, lo configuras en tu cliente de agente (Claude Desktop, Cursor, Continue, etc.), proporcionas un PAT de Figma, y el servidor corre como un proceso local. Cuando tu agente necesita contexto de Figma, llama a la herramienta. No exportas nada explícitamente — el agente obtiene lo que necesita cuando lo necesita.

El modelo MCP en la práctica

Un flujo de trabajo típico de Figma impulsado por MCP se ve así: abres Cursor, inicias una conversación, dices "implementa la pantalla de checkout de este archivo de Figma", y el agente llama a get_file, descarga el árbol de nodos y tiene los datos de diseño en contexto. Si luego dices "el diseñador actualizó los tokens del botón," el agente puede llamar de nuevo y obtener datos frescos.

Este modelo de conexión en vivo es real y convincente para algunos flujos de trabajo. El agente está trabajando con datos actuales. No gestionas artefactos de exportación. No hay paso manual entre "el diseñador publicó un cambio" y "el agente lo tiene."

Dónde gana MCP

Datos en vivo, sin paso de exportación. El agente obtiene el estado actual a demanda. Si el diseño cambió hace diez minutos, el agente puede verlo. figmascope requiere una re-exportación manual para capturar cambios.

Exploración de diseño conversacional. "¿Cuál es el color del botón CTA?" "¿Cuántas pantallas referencian este componente?" Con MCP, un agente puede responder esto llamando a Figma. Con un bundle, la respuesta solo es tan fresca como la última exportación.

Editar Figma directamente. Algunos servidores MCP exponen operaciones de escritura — crear nodos, actualizar propiedades, publicar comentarios. Esto solo es posible con una conexión en vivo. Un bundle estático no tiene ruta de escritura.

Sin flujo de trabajo manual. Para desarrolladores que ya usan configuraciones de agente conectadas por MCP, sin paso de exportación significa una cosa menos de olvidar. La gestión del contexto se delega al agente.

Dónde pierde MCP

El modelo de conexión en vivo tiene costos arquitectónicos que son fáciles de subestimar.

Estado vinculado a la sesión. Las llamadas MCP ocurren en el contexto de una sesión de conversación. Los datos que el agente recuperó en la sesión A no están disponibles en la sesión B sin volver a obtenerlos. Si inicias un nuevo chat, el agente comienza de cero. Un bundle de figmascope persiste entre sesiones, entre desarrolladores y entre herramientas — son solo archivos.

Opaco para git. No hay artefacto. Nada que confirmar. El contexto de diseño que informó tu código no vive en el repositorio. Seis meses después, si quieres entender cómo se veía el diseño cuando se construyó un componente, no hay registro. Con un bundle en el repo, tienes un historial de confirmaciones de intención de diseño.

Requiere conexión. MCP necesita un servidor en ejecución, una conexión en vivo a la API de Figma y un PAT con acceso. Red caída, API de Figma caída, PAT vencido — el agente no tiene contexto. Un bundle funciona en un avión.

Recuperación dependiente del modelo. Lo que el agente pide a través de MCP depende de lo que decida pedir. Puede que no obtenga los valores de tokens. Puede que no descargue el inventario de componentes. Puede que solicite solo el subárbol de nodos que cree que necesita, perdiendo contexto espacial de nodos adyacentes. La recuperación es probabilística, no determinista. figmascope obtiene todo, siempre, con un esquema fijo.

Más difícil de probar y reproducir. "Mi agente construyó este componente desde estos datos de Figma en este punto del tiempo" no es verificable con MCP. La obtención es efímera. Con un bundle, puedes repetir exactamente: mismo bundle, mismo agente, mismo prompt — salida determinista. Esto importa para la depuración, la revisión de código y la responsabilidad de las versiones.

Presión sobre la ventana de contexto. Una llamada get_file ingenua sobre un archivo de Figma complejo devuelve un árbol JSON enorme. Los agentes tienen que hacer llamadas selectivas a herramientas para mantenerse dentro de los presupuestos de contexto. Esto introduce heurísticas y juicios que pueden salir mal. figmascope pre-procesa el árbol en un IR estructurado con solo lo necesario, de un tamaño conocido y acotado.

El modelo de bundle de figmascope: captura una vez, envía para siempre

figmascope exporta un .zip de archivos planos desde la API REST de Figma — sin plugin, sin servidor, corre en tu navegador. El bundle contiene:

Una vez exportado, el bundle es autocontenido e inmutable. Va en tu repositorio junto al código que describe. Cualquier agente, cualquier sesión, cualquier desarrollador, cualquier trabajo de CI puede leerlo. Sin conexión a nada requerida.

Diffs versionables: comparar bundles como código

Este es el argumento más fuerte del modelo de bundle. Dado que la salida es JSON estructurado y Markdown, puedes hacer diff.

Exporta un bundle antes de un sprint de diseño. Exporta otro después. Ejecuta diff en tokens.json:

- "spacing.4": "16px"
+ "spacing.4": "14px"

Ese es un cambio que rompe la escala de espaciado. Es visible, revisable y trazable a una confirmación. Con MCP, el mismo cambio ocurre silenciosamente — la próxima vez que el agente obtenga datos, recibe el nuevo valor, y no hay registro de que algo cambió.

Puedes ejecutar esto como un gate de PR: exporta el bundle como parte del handoff de diseño, confírmalo, requiere la aprobación del diseñador y el desarrollador sobre el diff antes de que comience la implementación. Eso es la especificación de diseño como código. MCP no tiene equivalente.

El argumento del determinismo

Misma versión de archivo de Figma + misma exportación de figmascope = mismo bundle. Siempre. El esquema IR es fijo. La lógica de origen de tokens es determinista. La extracción de claves de cadenas está basada en reglas.

La recuperación MCP no es determinista. El agente decide qué obtener. Diferentes agentes, diferente formulación del prompt, diferentes presupuestos de contexto — diferente comportamiento de obtención. La salida depende del modelo.

Para la generación de código UI de producción, el determinismo importa. Quieres que la especificación que generó un componente sea reproducible. Quieres poder regenerar el componente desde las mismas entradas y obtener resultados consistentes. Los bundles apoyan esto. Las sesiones MCP no.

Comparación

Dimensión Figma MCP Bundle de figmascope
Frescura de datos Siempre en vivo — obtiene el estado actual de Figma Instantánea — tan fresca como la última exportación
Requiere paso de exportación No Sí — una vez por versión de diseño
Controlable por versión No — sin artefacto Sí — el bundle es JSON + Markdown con diff
Persistente entre sesiones No — hay que volver a obtener en cada sesión Sí — los archivos persisten indefinidamente
Funciona sin conexión No Sí
Salida determinista No — recuperación dependiente del modelo Sí — misma entrada → mismo bundle siempre
Presión sobre la ventana de contexto Alta — el JSON raw de Figma es grande y no estructurado Baja — el IR está pre-procesado, tamaño acotado
Operaciones de escritura en Figma Sí (algunos servidores MCP) No — solo lectura
Especificación de diseño en historial git No Sí — confirma el bundle, traza el historial de diseño
Requiere configuración de agente Sí — configurar servidor MCP por cliente de agente No — cualquier agente que lea archivos funciona
Claves de cadenas i18n No en el esquema base de Figma MCP Sí — stringRef.key en IR + strings.json
IR espacial / de layout Árbol de nodos raw de Figma (sin tipos de layout semánticos) IR tipado: stack / overlay / absolute / leaf
Origen de tokens Variables si están configuradas; de lo contrario valores raw Variables → inferido por frecuencia → ninguno

MCP brilla para "editar Figma en vivo" — los bundles brillan para "construir UI de producción"

Este es el resumen honesto. Si tu flujo de trabajo es exploración de diseño conversacional — "cambia este componente," "anota esta pantalla," "cuáles son los tokens de color en este frame" — la conexión en vivo de MCP es el modelo correcto. El agente es un colaborador en el proceso de diseño y necesita datos actuales para hacer eso.

Si tu flujo de trabajo es construir UI de producción desde un diseño finalizado (o casi finalizado) — implementar componentes, conectar estado, escribir tests — el modelo de bundle es mejor. Quieres la especificación anclada en tu repositorio, con diff entre iteraciones de diseño, legible por cualquier agente sin configuración y determinista lo suficiente para construir sobre ella.

Los dos modelos son complementarios. Usa MCP cuando el diseño está en flujo y estás iterando de forma colaborativa. Exporta un bundle de figmascope cuando el diseño está estable y lo estás entregando a los ingenieros para su implementación. El bundle se convierte en la fuente de verdad contra la que se construye la implementación — trazable, revisable, reproducible.