MCP Apps: interfaces interactivas en el chat en octubre de 2026

MCP Apps es la extensión oficial de MCP (io.modelcontextprotocol/ui) para que un servidor entregue interfaces HTML interactivas, como gráficos, formularios o paneles. El host las muestra dentro de la conversación, en un iframe aislado. Una tool enlaza su vista con _meta.ui.resourceUri, y la vista habla con el host por postMessage con métodos ui/* (overview de MCP Apps).

Versión de la especificación de MCP Apps: 2026-01-26.

Cuando escribimos sobre MCP Apps en noviembre de 2025, lo que había era una propuesta, la SEP-1865. Casi un año después, el panorama es otro. La extensión tiene especificación estable y la muestran Claude, ChatGPT, VS Code, Microsoft 365 Copilot y Cursor, entre otros. Entre agosto y octubre de 2026, además, recibió una versión mayor de su SDK que no toca el protocolo.

En este artículo verás en qué estado está, qué cambió con ext-apps 2.0 y qué no, y por dónde empezar si quieres que tu servidor devuelva algo más que texto.

Qué es MCP Apps

Una tool de MCP devuelve texto y datos estructurados. Eso basta para que el modelo razone, pero no siempre para el usuario. Elegir fechas en un calendario, revisar una tabla de cien filas o confirmar un pedido viendo el detalle se hace mejor con una interfaz que con un párrafo. MCP Apps cubre ese hueco sin que cada host tenga que inventar su propio formato.

El mecanismo tiene tres piezas, según la especificación de la extensión:

1. Negociación. El cliente anuncia la extensión io.modelcontextprotocol/ui en sus capacidades, con la lista obligatoria de mimeTypes que sabe mostrar, por ejemplo text/html;profile=mcp-app. Como toda extensión oficial, solo se usa si las dos partes la declaran.
2. Recurso de UI. La vista es un recurso MCP normal con URI de esquema ui:// y mimeType text/html;profile=mcp-app. El host lo obtiene con resources/read. En su _meta.ui puedes declarar tres cosas: csp (connectDomains, resourceDomains) para limitar los orígenes que la vista puede cargar, permissions para pedir capacidades adicionales y prefersBorder.
3. Enlace entre tool y vista. En la definición de la tool, _meta.ui.resourceUri apunta al recurso ui://. El campo opcional _meta.ui.visibility vale ["model", "app"] por defecto. Con "model", el agente ve la tool y puede llamarla. Con "app", solo la llama la vista del mismo servidor. Una tool marcada solo como ["app"] no debe aparecer en la lista de tools del agente.

La vista y el host hablan un dialecto propio de MCP sobre postMessage: ui/initialize, ui/notifications/initialized, ui/notifications/tool-input, ui/notifications/tool-result y otros. Fíjate en que ese ui/initialize va del iframe al host. No tiene nada que ver con el protocolo entre cliente y servidor, que en 2026-07-28 ya no tiene handshake.

sequenceDiagram
  participant H as Host
  participant S as Servidor MCP
  participant V as Vista (iframe)
  H->>S: tools/list
  S-->>H: tool con _meta.ui.resourceUri
  H->>S: resources/read ui://...
  S-->>H: HTML de la vista (mcp-app)
  H->>S: tools/call
  S-->>H: resultado con content
  H->>V: Renderiza la vista aislada
  V->>H: ui/initialize
  H->>V: ui/notifications/tool-input
  H->>V: ui/notifications/tool-result
  Note over H,V: Canal postMessage, no cliente-servidor

Conviene tener presentes dos reglas de diseño desde el principio. La primera es que, si el host no soporta Apps, la tool se comporta como una tool normal. Por eso siempre tiene que devolver un content con sentido, aunque tenga vista. La segunda es que la forma plana _meta["ui/resourceUri"] está deprecada, así que usa el objeto _meta.ui.

Estado: extensión oficial con especificación 2026-01-26

MCP Apps es una extensión oficial, fuera del núcleo del protocolo, y vive en el repositorio modelcontextprotocol/ext-apps. La especificación que enlaza el README sigue siendo la versión 2026-01-26, con estado Stable. Entre el 1 de agosto y el 3 de octubre de 2026 no cambió de versión.

Sobre su madurez solo hay un movimiento, y es un borrador. SEP-3392 (Extension Lifecycle), abierta el 25 de septiembre de 2026, propone tres fases para las extensiones (Experimental, Beta y Stable) o su promoción al núcleo. En ella, ext-apps aparece como Stable, junto a ext-auth. Es una propuesta, no una decisión.

Si lees la especificación de Apps, te encontrarás un detalle. Su ejemplo de negociación todavía usa una petición initialize, el handshake que la versión 2026-07-28 del protocolo eliminó. Las páginas del sitio principal sí muestran la declaración actual. Ahí la extensión va en las capacidades del cliente, que viajan en el _meta de cada petición, y en la respuesta de server/discover del servidor.

A 3 de octubre no hemos encontrado una revisión de la especificación de Apps reescrita para 2026-07-28, así que, para la negociación, guíate por la documentación del sitio principal.

ext-apps 2.0: rompe dependencias, no el protocolo

El 8 de septiembre de 2026 salió ext-apps v2.0.0. Es una versión mayor del paquete, no del protocolo:

• Migra al SDK de TypeScript 2.0, con sus paquetes separados (@modelcontextprotocol/client y @modelcontextprotocol/server), y exige zod 4.2 o superior.
• Rompe dependencias y la API de TypeScript. Si tu servidor usa @modelcontextprotocol/ext-apps 1.x, la actualización te obliga a pasar también al SDK 2.
• No rompe la interoperabilidad. El protocolo de MCP Apps es compatible en ambos sentidos, así que una vista 2.x funciona en un host 1.x y una vista 1.x en un host 2.x.

Las versiones 2.0.1, 2.0.2 y 2.0.3, del 24 y 25 de septiembre, solo arreglan los servidores de ejemplo: compatibilidad con Node anterior a 20.11 y dependencias con avisos de seguridad.

En la práctica, puedes migrar tu servidor a ext-apps 2.0 a tu ritmo, sin preocuparte por la versión que tengan los hosts de tus usuarios. El calendario lo marca la migración al SDK de TypeScript 2, no MCP Apps.

Qué clientes muestran MCP Apps

Según la matriz de soporte por cliente de la documentación oficial, estos clientes muestran MCP Apps:

Además, el 12 de agosto de 2026 se añadió Alpic Playground a la lista de clientes del README del repositorio (PR #729).

Ten en cuenta de dónde sale la tabla. La matriz la mantiene la comunidad y no es una certificación. Sirve para saber dónde merece la pena probar, no como garantía de que cada cliente implementa todos los detalles de la especificación.

Claude Code no aparece en la matriz como cliente que muestre MCP Apps. Lo que sí hizo, en la versión 2.1.281 del 23 de septiembre de 2026, fue dejar de mostrar los recursos de UI de MCP Apps en las listas de recursos y en el autocompletado de @-menciones (CHANGELOG de Claude Code). Es decir, en un terminal tus recursos ui:// ya no ensucian la lista.

Confirmaciones oficiales del periodo

Más allá de la matriz, entre agosto y octubre llegaron confirmaciones directas de quienes construyen los clientes:

• Anthropic, 25 de septiembre. Al abrir el portal de envío de plugins y conectores, Anthropic cita MCP Apps “for interactive UI inside chat” entre lo que soportan los plugins de Claude. Lo pone junto al núcleo sin estado de 2026-07-28 y Enterprise Managed Auth (Build plugins for Claude). Qué más soporta Claude de esa versión, y quién más la soporta, lo tienes en MCP 2.0 en producción.
• OpenAI. Su documentación “Add UI to your MCP server” dice que ChatGPT implementa el estándar abierto MCP Apps y recomienda usar _meta.ui.resourceUri y el bridge ui/* en lugar de los alias window.openai (documentación de OpenAI). Si tienes una app de ChatGPT hecha con esos alias, ese es el camino de migración que propone la propia OpenAI.
• AWS, 11 de septiembre. Publicó una guía, con el caso “Unicorn Rentals”, para crear MCP Apps sobre Amazon Bedrock AgentCore, probadas en ChatGPT y Claude (blog de AWS).
• Claude Code, 23 de septiembre. El cambio de la versión 2.1.281 que acabamos de ver: los recursos de UI salen de las listas.
• MCP Inspector 2.9.0, 30 de septiembre. “advertise the MCP Apps UI extension only from a client that renders Apps” (releases del Inspector). El Inspector solo anuncia la extensión cuando de verdad puede mostrar la vista. Es lo que debe hacer cualquier cliente, porque declarar io.modelcontextprotocol/ui sin renderizar engaña al servidor.

Ejemplos reales

Si quieres ver MCP Apps funcionando antes de escribir nada, hay material oficial y de terceros:

• Excalidraw en Claude, el ejemplo que muestra el README de ext-apps.
• Los 21 servidores de ejemplo publicados, por ejemplo @modelcontextprotocol/server-pdf.
• El ejemplo de AWS sobre AgentCore, probado en dos clientes distintos.

Un caso aparte es llevar MCP Apps a una aplicación propia, sin pasar por Claude o ChatGPT. CopilotKit publica integraciones para hacerlo mediante AG-UI (blog de CopilotKit). AG-UI es el protocolo que conecta un backend agéntico con la interfaz del usuario, y llegó a la versión 1.0 el 30 de septiembre de 2026.

AG-UI y MCP se complementan. MCP conecta el agente con sus herramientas, y AG-UI conecta el agente con la interfaz. Con MCP Apps sí hay cierto solapamiento, porque las dos piezas entregan interfaz. Dónde queda cada protocolo de esa capa, junto a A2UI y Agent Client Protocol, lo explicamos en el mapa de protocolos de agentes de IA.

Cómo empezar

Si mantienes un servidor MCP y quieres añadir una vista:

1. Empieza por la tool, no por la vista. Diseña una tool que devuelva un content útil por sí solo. La vista se añade encima, y los hosts sin Apps seguirán usando la tool como siempre.
2. Sirve la vista como recurso ui:// con mimeType text/html;profile=mcp-app y enlázala desde la tool con _meta.ui.resourceUri. Si la vista necesita cargar recursos externos, decláralos en _meta.ui.csp, que controla qué orígenes puede cargar.
3. Usa visibility para las tools auxiliares. Si la vista necesita llamar al servidor (paginar, filtrar, guardar un cambio), esas tools pueden ir marcadas como ["app"] para que no aparezcan en la lista de tools del agente y solo las llame la vista.
4. Usa ext-apps 2.x con el SDK de TypeScript 2. El paquete es @modelcontextprotocol/ext-apps. Si partes de 1.x, recuerda que lo que cambia es tu árbol de dependencias, no lo que ve el host.
5. Prueba en más de un cliente. La matriz es comunitaria. Claude y ChatGPT tienen documentación propia (guía de Claude y guía de OpenAI). La documentación completa de la extensión está en apps.extensions.modelcontextprotocol.io.

Si vienes de una app de ChatGPT con window.openai, da el paso que recomienda OpenAI: _meta.ui.resourceUri y el bridge ui/*. Así la misma vista puede funcionar también en el resto de clientes de la tabla, aunque conviene probarla en cada uno.

El marco general de extensiones (cómo se negocian, qué pasa si solo una parte las soporta) se ve en la lección «Interacción con el usuario y extensiones» del curso. En el nivel Experto, el «Caso de estudio: Nortia» plantea MCP Apps como una evolución posible de la plataforma de la empresa ficticia del curso: una interfaz dentro de la conversación. Y señala la condición que tendría que cumplirse para adoptarla.

MCP Apps no es la única extensión que se movió en el periodo. La otra novedad fue normativa: la extensión Skills llegó a Final el 13 de septiembre, con la adopción todavía por hacer. MCP Apps está en el punto contrario. Su texto lleva meses estable, y lo que ha cambiado es que los grandes clientes ya la muestran. Si tu servidor tiene una tarea que se entiende mejor viéndola que leyéndola, este es buen momento para probar.