Por qué uso Cursor con el MCP de Figma — y por qué igualmente pruebo en un iPhone con cable

"Frontend asistido por IA" antes significaba pegar una captura en un chat y recibir un CSS que quedaba cerca, pero nunca con el espaciado exacto, el gris exacto, el line-height exacto. El Model Context Protocol cambió justo esa parte del handoff de diseño. Cursor habla con el servidor MCP de Figma, y en vez de aplanar un frame en píxeles que el modelo debe adivinar, recibe el árbol real de nodos: auto-layout, valores de espaciado, variables vinculadas, nombres de componentes, escala tipográfica. Es en esa parte donde realmente me apoyo cada día.

1. Lo que el MCP realmente acierta

Selecciono un frame en Figma, le doy el enlace a Cursor, y consulta al servidor MCP por ese nodo exacto. Lo que vuelve es estructurado: un gap de 8px es el número literal 8, no algo que mido con una herramienta de regla sobre un PNG. Un color es el token de diseño o el hex que la diseñadora vinculó, no un valor que elijo con un cuentagotas esperando que coincida. Peso de fuente, line-height, radio de esquina, la jerarquía real de componentes — todo llega como datos, no como una imagen que hago ingeniería inversa.

• Espaciados que coinciden con el sistema de diseño, no con el número redondo más cercano que adiviné.
• Colores y tipografía como tokens, así un rebranding actualiza una variable en vez de un grep en todos los componentes.
• Límites de componentes que coinciden con cómo la diseñadora realmente agrupó las cosas, lo que facilita mantener semántico el markup generado.

2. Lo que sigo comprobando a mano

Los datos estructurados no son criterio. Un frame de Figma muestra un breakpoint a la vez; no le dice a Cursor qué pasa entre 768px y 1024px, ni cómo se ve una tarjeta con un título de dos líneas en vez de una. No hay estado vacío, ni estado de error, ni skeleton de carga, porque esos nunca tuvieron un frame de diseño. Y el markup generado puede ser estructuralmente fiel al frame y seguir siendo un div donde debería ir un botón, un nav o un encabezado — sigo leyendo cada componente en busca de semántica y acceso por teclado antes de fusionarlo.

3. Por qué un emulador no basta

La barra de dispositivos de Chrome DevTools es Chromium renderizando un viewport redimensionado. No es WebKit, no tiene el comportamiento de viewport dinámico de Safari en iOS, y no te mostrará los bugs que solo existen en el motor real. Así que el último paso antes de que algo salga a producción es conectar un iPhone real a mi Mac con un cable. Ajustes → Safari → Avanzado → Inspector web, activado una vez en el teléfono. Luego un cable Lightning o USB-C al Mac, el menú Develop de Safari detecta el dispositivo, y obtengo un Web Inspector en vivo — DOM real, consola real, panel de red real — conectado a una página que realmente corre en Safari de iOS, no una simulación.

Ahí es donde atrapo los bugs que un emulador esconde: un padding safe-area-inset que se ve bien en DevTools y se recorta bajo el notch en el teléfono real, un salto de 100vh cuando la barra de direcciones de Safari se colapsa al hacer scroll (dvh lo arregla, pero solo probarlo en vivo lo demuestra), el salto de foco del input cuando se abre el teclado con un footer fijo en pantalla, el overscroll elástico que arrastra todo el layout, y cómo se comporta realmente la página agregada a la pantalla de inicio como PWA independiente. Nada de eso aparece en un emulador. Todo eso aparece la primera vez que un cliente real abre el enlace en su propio teléfono — así que prefiero verlo yo primero.

4. Por qué Safari específicamente — el navegador para el que realmente entrego

Miro las analíticas antes de decidir qué significa siquiera "correcto" para un proyecto. Para la mayoría de los sitios de pequeños negocios y servicios que construyo, la clienta que abre el sitio está en el teléfono, llegando desde Instagram, Telegram, Google Maps o un mensaje de texto — y para una gran parte de ese tráfico, ese teléfono es un iPhone. Chrome de escritorio es donde desarrollo. Safari de iOS es donde realmente está la persona con la tarjeta. Optimizar la perfección de píxel para el navegador que miro todo el día y saltarme el que realmente sostiene la clienta de mi cliente es optimizar para la audiencia equivocada.

El ciclo real

Frame de Figma, seleccionado y entregado a Cursor a través del MCP. Componente construido con tokens reales, no píxeles adivinados. Una pasada por la semántica, los estados y los breakpoints que el frame nunca mostró. Luego el iPhone sale del cajón, se conecta al Mac, y la misma página corre en vivo en el Web Inspector de Safari sobre el motor real. Solo después de eso se fusiona algo. Dos herramientas distintas, dos trabajos distintos: una me acerca rápido al diseño, la otra me dice la verdad sobre el dispositivo que la clienta de mi cliente realmente va a usar.

¿Quiere que se vea realmente bien en el teléfono de su cliente?

Este es el pipeline que ejecuto en cada build: tokens de diseño reales entran, dispositivo real sale. Escriba por el formulario de contacto y dígame qué plataforma usan realmente sus clientes — construiré y probaré para esa, no para el navegador que me resulte cómodo.