Problema y solución dual
Liad Yosef (AI & MCP Lead en Monday.com, comoderador del grupo de trabajo de UI) presenta MCP-UI como solución a un problema dual. Primero, las interfaces basadas en texto crean muros de texto para los usuarios. Segundo, y más crítico, los proveedores (Shopify, Airbnb, Amazon) pierden su identidad cuando envían solo texto: el chat decide cómo mostrarlo, privándolos de su lugar en la cadena de valor. MCP-UI permite que cada aplicación envíe "fragmentos de UI" (UI chunks) - piezas de su identidad - preservando el reconocimiento visual y la experiencia de usuario perfeccionada durante años.
Arquitectura técnica y seguridad
MCP-UI es un protocolo abierto + SDK para enviar UI a través de MCP y estandarizar la comunicación host/UI. La arquitectura se apoya en sandboxed iframes que garantizan la seguridad: el código de la UI no accede al origin del host, no puede robar cookies/memoria, y se comunica únicamente vía post messages. Se admiten tres tipos de contenido: URLs externas, HTML en bruto, remote DOM (un concepto potente que separa la definición de la estructura del renderizado - el mismo servidor MCP puede enviar una respuesta idéntica a distintos clientes que la renderizarán con sus propios componentes).
Espectro de comunicación y estado
MCP-UI define un espectro de comunicación que representa niveles de responsabilidad de la UI sobre las acciones del usuario: (1) Notify - la UI ejecuta una acción backend y notifica al chat; (2) Tool call - la UI solicita el disparo de una herramienta específica; (3) Prompt - la UI solicita la ejecución de un prompt; (4) Intent - la UI envía la intención del usuario, el host decide qué hacer. Esta arquitectura de islands (distintas islas de UI compuestas dentro de un mismo contexto) requiere una gestión de estado sofisticada en 4 niveles: contexto del agente (para el flujo agéntico), estado interno de la aplicación (preferencias, steppers vía cookies/localStorage), backend (datos no relevantes para el flujo agéntico pero necesarios para la sincronización), y estado compartido entre componentes.
Demostración concreta: gestión de sprints
La demo muestra a un engineering manager preguntando "estado del sprint". En lugar de texto inútil, MCP-UI devuelve un widget interactivo de Monday con un desglose visual. Al hacer clic en "tareas bloqueadas" → se muestra la tarea "implementar autenticación" asignada a Sarah. Al hacer clic en "analizar" → el mecanismo de comunicación envía un prompt al agente que, conectado a Gmail vía otro servidor MCP, obtiene correos automáticamente descubriendo que Sarah está enferma y que Jordan conoce el código. El widget inyecta un análisis coloreado sugiriendo la reasignación a Jordan. Al hacer clic en "reasignar" → un mensaje de intent dispara una llamada a herramienta MCP completando el flujo. Es crucial señalar que: el proveedor no construyó la integración con Gmail - el agente estableció la conexión usando el contexto existente.
Theming multicapa
Para evitar una experiencia de "compilación de UIs de terceros", MCP-UI admite un theming sofisticado: CSS personalizado (Shopify ya lo implementa), variables CSS, theme tokens, y remote DOM (el más potente - la UI remota se renderiza con componentes del host, garantizando coherencia visual mientras se preserva la estructura/interacciones del proveedor).
Adoptantes y ecosistema
Adopción masiva ya en marcha: despliegue completo de Shopify, Postman, Goose, Libra chat (hosts); Hugging Face (todos los spaces exponen MCP-UI), 11 Labs, MCP storefront (proveedores). SDKs comunitarios en Ruby, Python, TypeScript, Go. Proyecto comunitario en mcpui.dev con guías completas.
Visión de futuro: web fragmentada recompuesta
Visión transformadora: hoy se abren 10 pestañas distintas (Amazon, Calendar, Booking) para una sola tarea (planificar un cumpleaños), cada una con una UI compleja de la que el 90% es irrelevante. Futuro: un asistente personal compone átomos de UI de los proveedores - Google Calendar envía un fragmento de evento, Amazon un fragmento de lista de productos, Booking un fragmento de listados+mapa. No se necesita integración proveedor-a-proveedor - el asistente tiene el contexto completo. Resultado: aplicaciones deconstructibles en componentes reutilizables, un Jarvis accesible porque desaparece la sobrecarga de integración.
Retos de la hoja de ruta
Tres retos principales: (1) Auth/SSO - actualmente el estado está incrustado en el contexto/UI o en autenticación dentro de la UI, se necesita un SSO fluido; (2) Clientes nativos - ChatGPT/Claude volviéndose nativos, muchos no admiten iframes/webviews, se explora un payload abstracto convertible a HTML o nativo con negociación de capacidades; (3) Adopción de la estandarización - la tecnología está lista, necesita impulso comunitario.