MCP Apps y A2UI colocan interfaces interactivas dentro de las conversaciones con agentes, pero funcionan de forma opuesta. Este artículo compara el renderizado, la seguridad, el soporte de hosts y el costo, y luego ofrece una tabla de decisión que asocia cada estándar con los trabajos que mejor resuelve.
Tu agente acaba de dar la respuesta correcta, y aun así aparece como un muro de texto. Dos estándares abiertos resuelven ese problema, y en casi todo lo demás no se ponen de acuerdo. MCP Apps entrega una pequeña aplicación web que se ejecuta dentro de un iframe aislado. A2UI envía un plano en JSON y deja que el host lo dibuje con sus propios componentes nativos. Uno da al servidor el control de los píxeles. El otro traspasa ese control al cliente.
Esta comparativa analiza el renderizado, la seguridad, el soporte de hosts y el costo del día a día, y termina con una tabla de decisión que puedes aplicar hoy a tu propio agente. Todas las afirmaciones sobre las dos especificaciones provienen de la documentación oficial de MCP, del sitio del proyecto A2UI y del blog para desarrolladores de Google, verificadas en octubre de 2026.
La diferencia se explica en pocas palabras. MCP Apps trata una UI como un recurso que un servidor entrega. A2UI trata una UI como datos que un agente describe. Todo lo demás de este artículo se deriva de esa única diferencia.
MCP Apps empezó como la propuesta SEP-1865 en noviembre de 2025. Anthropic, OpenAI y los mantenedores del proyecto comunitario MCP-UI la escribieron juntos, basándose en MCP-UI y en el Apps SDK de OpenAI. En enero de 2026 se convirtió en la primera extensión oficial del Model Context Protocol, con su propia especificación fechada el 2026-01-26 en el repositorio ext-apps.
El mecanismo reutiliza dos primitivas ordinarias de MCP, una herramienta y un recurso:
_meta.ui.resourceUri, que apunta a un recurso ui://.text/html;profile=mcp-app.postMessage, un dialecto de JSON-RPC con métodos ui/ como ui/initialize.
Como la carga útil es código web normal, tú eliges el framework. El repositorio ext-apps incluye plantillas de inicio para React, Vue, Svelte, Preact, Solid y JavaScript puro. La clase App de @modelcontextprotocol/ext-apps es un envoltorio de conveniencia, no un requisito. Si quieres menos dependencias, puedes implementar tú mismo el protocolo postMessage.
A2UI, abreviatura de Agent-to-User Interface, es el estándar abierto de Google, publicado bajo la licencia Apache 2.0 en diciembre de 2025. El agente no envía HTML. Transmite JSON declarativo que nombra los componentes y sus datos. El cliente mantiene un catálogo de componentes en los que confía, valida cada mensaje contra ese catálogo y traduce el resultado a un árbol de UI nativa.
El lema del propio Google lo resume: seguro como los datos, expresivo como el código. La especificación está en v0.9.1, y la v1.0 se encuentra en versión candidata a octubre de 2026. Existen renderizadores para Angular, Flutter y Lit, y Google ya usa A2UI en Opal, Gemini Enterprise y el Flutter GenUI SDK. Las cargas útiles viajan con el tipo MIME application/a2ui+json.
💡 Modelo mental: MCP Apps es "enviar una miniatura de sitio web". A2UI es "enviar un plano y dejar que el host lo construya con piezas aprobadas".
Con MCP Apps, el servidor decide cómo se ve todo. El host solo aporta el marco, el sandbox y el puente de mensajes. Eso te da la plataforma web completa: gráficos D3, escenas WebGL, visores de PDF, mapas, un globo CesiumJS o una escena Three.js. Son ejemplos reales del repositorio ext-apps, junto con un asignador de presupuesto, un mapa de calor de cohortes y un monitor del sistema.
El precio es la deriva visual. Un iframe no hereda por sí solo el sistema de diseño del host, así que tu aplicación puede parecer un elemento extraño dentro del chat. Además, carga con el peso de una página del navegador: sus propios scripts, su propia memoria y su propio tiempo de carga.
Con A2UI, el cliente decide cómo se ve todo. El agente dice "una tarjeta con un título, un gráfico y dos botones", y el cliente renderiza su propia tarjeta, su propio gráfico y sus propios botones. El tema visual lo aporta el host, así que el resultado coincide con la aplicación que lo rodea, en web, móvil o escritorio, sin necesidad de un webview.
El formato también es amigable para los modelos de lenguaje. Es pequeño, estructurado y está diseñado para el streaming, de modo que un modelo puede emitir una interfaz paso a paso mientras el usuario la ve armarse. El límite es el catálogo: si el cliente no tiene un componente para lo que quieres, no puedes inventarlo dentro de la carga útil.
Esta es la comparativa en una sola vista:
| Dimensión | MCP Apps | A2UI |
|---|---|---|
| Carga útil | Paquete HTML en una URI ui:// | Mensajes JSON |
| Quién renderiza | El host de IA, dentro de un iframe aislado | El cliente, a partir de un catálogo aprobado |
| Quién controla el aspecto | El desarrollador de la aplicación | La aplicación host |
| Flujo de acciones | La aplicación solicita llamadas a herramientas mediadas por el host | El cliente valida y enruta las acciones declaradas |
| Streaming | Las entradas de las herramientas pueden transmitirse a una aplicación precargada | Diseñado para la generación incremental |
| Plataformas | Web primero | Web, móvil, escritorio |
| Estado | Extensión oficial de MCP | Liderado por Google, Apache 2.0, especificación v0.9.1 |
Detrás de los dos diseños hay modelos de amenaza muy distintos. Uno aísla el código. El otro se niega a aceptar código de ningún tipo.
La aplicación se ejecuta en un iframe aislado, así que no puede acceder al DOM de la página padre, leer las cookies o el almacenamiento local del host, ni redirigir la página padre. Todo el tráfico cruza la frontera postMessage, y el host decide qué pasa. La defensa tiene varias capas:
ui:// desde el principio, el host puede precargar y revisar una plantilla antes de que se ejecute cualquier herramienta._meta.ui.csp enumera los orígenes externos desde los que una aplicación puede cargar contenido._meta.ui.permissions.
A2UI elude la cuestión del sandbox porque nunca ejecuta nada. El renderizador acepta solo JSON validado y solo componentes que existen en el catálogo. Google llama a esto seguridad basada en capacidades: el cliente renderiza componentes de confianza y nada más.
Eso no hace que A2UI sea seguro de forma automática. Un botón del catálogo puede seguir disparando una acción, así que el cliente debe autorizar cada acción declarada y validar cada carga útil. La lista de permitidos protege la UI. No protege la lógica de negocio.
Ambos estándares trasladan contenido de un agente a una pantalla, así que heredan las debilidades del agente. Un modelo que lee una página web hostil puede ser convencido de renderizar un formulario falso y convincente, ya esté en un iframe o en una tarjeta del catálogo. Trata las llamadas a herramientas disparadas desde cualquier UI generada como entrada no confiable: verifica los permisos en el servidor, limita los tokens al mínimo necesario y exige confirmación para cualquier cosa que gaste dinero o modifique datos.
El soporte de hosts es el argumento más sólido a favor de MCP Apps en este momento. La documentación oficial enumera Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam y Archestra.AI, y ChatGPT también los renderiza. El proyecto MCP mantiene una matriz de clientes, y es importante: el soporte de la UI de las aplicaciones es más limitado que el de las herramientas básicas de MCP. Un cliente que llama a tus herramientas puede seguir ignorando tu recurso ui://.
Si construyes tu propio host, tienes dos caminos. El paquete @mcp-ui/client proporciona componentes de React, y el módulo App Bridge del SDK se encarga del renderizado aislado, el paso de mensajes, el proxy de llamadas a herramientas y la aplicación de políticas.
El soporte de A2UI depende del renderizador que incluya tu cliente, no de una lista de productos de chat. Eliges Angular, Flutter o Lit, defines tu catálogo y conectas un transporte. El protocolo A2A transporta A2UI entre agentes, y AG-UI, el protocolo de CopilotKit, anuncia compatibilidad desde el primer día. A2UI también puede viajar sobre MCP: las cargas útiles llegan mediante resources/read para pantallas estáticas o tools/call para dinámicas, bajo un esquema de URI a2ui://.
Elige según el trabajo, no según la marca. Esta tabla muestra cómo suelen repartirse el trabajo los equipos:
| Escenario | Mejor opción | Por qué |
|---|---|---|
| Integración de producto con autenticación y estado de la cuenta | MCP Apps | El servidor controla los permisos y el estado |
| Flujos de aprobación para cambios de gasto o de datos | MCP Apps | Entregas una superficie estable y probada |
| Contenido multimedia, mapas, 3D, visores de PDF | MCP Apps | Plataforma web completa dentro del iframe |
| Exploración de datos con diseños cambiantes | A2UI | El agente elige el gráfico, la tabla o la tarjeta |
| Informes generados | A2UI | Diseños flexibles, datos cambiantes |
| Una misma UI para web y móvil | A2UI | Misma carga útil, renderizado nativo |
| Coincidencia cercana con un sistema de diseño | A2UI | Se aplica el tema del host |
Elígelo cuando ya tienes un producto web y quieres llevarlo al chat. Tu servidor mantiene la lógica, controlas cada píxel y puedes reutilizar los componentes de React que ya tienes. Elígelo también cuando importa la velocidad de prototipado: basta un solo archivo HTML para publicar.
Elígelo cuando la pantalla no se conoce de antemano. Un agente que responde "muéstrame el último trimestre" con una tabla hoy y con un gráfico mañana encaja mucho mejor con un catálogo que con una página construida a mano para cada caso. Elígelo también cuando tu cliente sea nativo, o cuando tu equipo de seguridad no vaya a aprobar scripts de terceros en el chat.
La elección no es excluyente. El blog para desarrolladores de Google, publicado el 17 de junio de 2026, describe tres patrones de integración, y cambian lo que significa "elige uno".
a2ui://. No se necesita iframe.Para la mayoría de los equipos funciona un reparto por trabajo. Pon las superficies estables y en las que hay mucho en juego, como aprobaciones, ajustes y vistas de cuenta, en MCP Apps. Pon las superficies flexibles y generadas, como informes y resúmenes, en A2UI. Sirve ambas desde el mismo servidor MCP para que tu agente mantenga una sola conexión. El patrón 3 es tu vía de escape cuando un host no tiene renderizador.
Revisa el reparto cada trimestre. Si una superficie generada empieza a necesitar gráficos personalizados que el catálogo no puede dibujar, esa pantalla ha superado A2UI y debe pasar a una MCP App. Si una MCP App se reconstruye una y otra vez para cada nueva forma de datos, es candidata a convertirse en un catálogo.
Escribir cargas útiles de A2UI a mano resulta tedioso, y un modelo de lenguaje que devuelve JSON estricto es un buen compañero para redactarlas. GPT 5 Structured en PicassoIA está pensado exactamente para esto: defines un esquema JSON y cada respuesta se ajusta a él.
model: gpt-5, gpt-5-mini o gpt-5-nano.instructions. Enumera los componentes que acepta tu cliente, con sus propiedades.prompt, por ejemplo "un resumen de pedido con una tabla de artículos y un botón de confirmar".json_schema con el esquema de mensajes de la especificación de A2UI. Usa json_schema en lugar de simple_schema, porque la versión simple no admite objetos anidados.reasoning_effort en minimal para borradores rápidos. Para diseños densos, súbelo y aumenta max_output_tokens, porque el razonamiento extenso puede agotar el presupuesto y devolver una respuesta vacía.💡 Trata la salida del modelo como un borrador. El validador de tu renderizador es el control final, tal como pretende el modelo de seguridad de A2UI.
¿Quieres comparar borradores de otros modelos? Claude Sonnet 5 y Gemini 3.5 Flash también están disponibles en PicassoIA, así que puedes ejecutar el mismo catálogo y el mismo prompt en cada uno y quedarte con el resultado más limpio.
Elijas el estándar que elijas, las pantallas de tu agente necesitan imágenes: miniaturas de producto, banners principales, fotos de cabecera para los informes. MCP Apps muestra las imágenes como HTML normal. A2UI las muestra mediante el componente de imagen que defina tu catálogo. En cualquier caso, primero necesitas las imágenes.
PicassoIA reúne los generadores en un solo lugar. Seedream 5 Pro, Flux 2 Pro, Imagen 4 y PicassoIA Image están todos en la colección de texto a imagen, así que puedes ejecutar un mismo prompt en varios modelos y quedarte con la versión que mejor encaje en tu diseño. PicassoIA también expone sus generadores a través de conexiones MCP, de modo que un agente que hable el protocolo descrito arriba puede solicitar imágenes directamente.
Abre la colección, escribe un prompt para tu próxima tarjeta o banner y genera algunas variantes. Elige una pantalla de tu propio agente, dale una imagen real y comprueba lo rápido que el aspecto visual se pone al nivel de la lógica.
Elige tu idioma
