Dejar de devolver JSON: Enviar una interfaz de usuario interactiva con las aplicaciones MCP

Durante la mayor parte de las primeras etapas de MCP, el ciclo de interacción se mantuvo limitado: los agentes invocan herramientas, estas las ejecutan, los servidores responden con texto o datos estructurados, y los modelos reformulan el resultado para las personas.

Aún hay muchas preguntas que encajan en ese patrón. Para contar las implementaciones exitosas no se necesita nada especial: basta con llamar a get_deployments(), leer un objeto compacto como {"total": 12, "healthy": 10, "degraded": 2}, y responder en una sola línea.

La situación cambia cuando las personas quieren interactuar con el resultado. Los paneles de control, las aprobaciones, las tablas filtrables, los formularios de configuración, los gráficos, los paneles de implementación, los flujos de trabajo de múltiples pasos y los controles que involucran a un humano requieren algo más que un simple archivo JSON. Durante mucho tiempo, MCP no ofreció ningún estándar interhost para esto. Ahora sí lo tiene, bajo el nombre de MCP Apps, y amplía lo que un servidor MCP puede representar.

Los servidores MCP eran en su mayoría interfaces para máquinas

El primer modelo mental era orientado a agentes. Los servidores exponen herramientas como search_projects(), create_ticket(), restart_service() y get_customer(). Los modelos los descubren, los llaman, reciben datos, y las personas ven lo que el modelo decide mostrar. Eso es poderoso porque las operaciones se realizan a través de un único protocolo en lugar de una integración personalizada para cada agente. La limitación es que las capacidades estaban diseñadas para máquinas, por lo que el humano queda un paso alejado del resultado bruto.

Eso está bien hasta que la interacción es inherentemente visual. “Muéstrame todos los servicios de producción” puede devolver un bloque JSON correcto con estados, CPU y memoria, pero un panel compacto con barras de progreso, insignias y controles funcionales para registros/renovación/escale es mucho más útil. MCP Apps tiene como objetivo cerrar esa brecha.

¿Qué son exactamente las MCP Apps?

MCP Apps amplía el Model Context Protocol para que los servidores puedan ofrecer interfaces de usuario interactivas junto con sus herramientas: no capturas de pantalla, ni Markdown que simule una interfaz de usuario, sino aplicaciones reales en HTML/JavaScript renderizadas dentro de un host MCP. La documentación describe herramientas que anuncian recursos ui://, hosts que muestran esos recursos dentro de iframes aislados, y el mismo host que tanto inyecta los datos de las herramientas en la vista como permite que la vista invoque nuevamente a las herramientas únicamente a través de ese host.

MCP App = MCP Tool + UI Resource + Host/View protocol

Una herramienta sigue llamando a APIs, consultando bases de datos, ejecutando lógica empresarial y devolviendo datos estructurados. También puede incluir una interfaz de usuario para presentar esos resultados. La UI es un recurso MCP como ui://services/dashboard y puede contener todo el frontend: HTML, CSS, JavaScript, React, gráficos, formularios y botones. Así, una sola operación cuenta tanto con una capacidad orientada a máquinas como con una interfaz para usuarios, estandarizada en todos los hosts.

¿De dónde provienen las aplicaciones MCP?

La extensión es nueva. Los desarrolladores que implementaron servidores MCP hasta 2025 no se perdieron ninguna función secreta; el estándar oficial aún no existía.

A finales de noviembre de 2025 se presentó SEP-1865, la propuesta para Apps desarrollada en colaboración con contribuyentes y mantenedores de MCP-UI provenientes de los principales laboratorios de modelos. Ya existían experimentos paralelos (MCP-UI, Apps SDK); lo que faltaba era una forma interoperable mediante la cual un servidor pudiera entregar herramientas, datos y una interfaz de usuario que cualquier sistema compatible pudiera renderizar. La publicación del blog de MCP de noviembre de 2025 sobre la propuesta de Apps registra el anuncio de SEP-1865.

A finales de enero de 2026, el mismo grupo denominó a Apps la primera extensión oficial lista para producción, con especificaciones más precisas, un SDK y servidores listos para su despliegue. ChatGPT, Claude, Goose y Visual Studio Code fueron mencionados como clientes iniciales. La publicación del blog de MCP de enero de 2026 declara a Apps como la primera extensión oficial.

La versión candidata de julio de 2026 mejoró en general las extensiones: identificadores estables, negociación de capacidades, repositorios separados, versionado independiente y una sección “Extensions Track” que enumera las aplicaciones. También se destacó que las llamadas controladas por botones siguen pasando por la ruta JSON-RPC del host, manteniendo a Agent → Tool y Human → Button → Tool bajo un mismo plano de control. La publicación sobre la versión candidata de julio de 2026 en el blog de MCP trata sobre la sección “Extensions Track”.

En septiembre de 2026, un artículo de AWS Bedrock AgentCore mostró un patrón de hosting concreto sin limitar las aplicaciones únicamente a AWS: host → gateway → runtime → servidor MCP (herramientas + recursos de interfaz) → Lambda/DynamoDB. La demostración utilizó ChatGPT y señaló que Claude y otros hosts de aplicaciones funcionan de la misma manera. Consulte el artículo del blog de AWS Machine Learning sobre aplicaciones MCP interactivas con Bedrock AgentCore para ver el proceso paso a paso.

¿Quién realmente soporta las aplicaciones MCP?

Brindar soporte a MCP no es lo mismo que brindar soporte a las aplicaciones MCP. Un cliente puede manejar herramientas y recursos ordinarios sin implementar la extensión de aplicaciones. El anuncio de enero de 2026 mencionó a ChatGPT, Claude, Goose y VS Code; la documentación actual describe el renderizado en línea en Claude, ChatGPT y otros clientes compatibles, señalando al mismo tiempo que el soporte del host varía. Diseñe teniendo en cuenta esta realidad: no asuma que todos los clientes entienden las aplicaciones. La ecuación útil es El servidor soporta aplicaciones MCP + El host soporta aplicaciones MCP = UI interactiva, y un servidor cuidadoso debería recurrir al texto o al contenido estructurado cuando el host no pueda renderizar la aplicación.

La única pregunta que realmente importa

Si el recurso de la interfaz de usuario es HTML estático, ¿cómo llegan hasta él los cambios en los datos de la herramienta? La CPU puede estar al 21% ahora y al 87% diez segundos después; regenerar todo el frontend en cada llamada a la herramienta sería absurdo. La solución está en la separación: la interfaz de usuario y los datos son artefactos distintos. Considere a la herramienta como el productor de datos, al recurso como la capa de presentación y al host como el elemento que los conecta. La herramienta devuelve datos dinámicos; el recurso devuelve una aplicación que sabe cómo renderizar esa información; el host los conecta en tiempo de ejecución.

Cómo funcionan realmente las aplicaciones MCP

Considere get_servers(), que devuelve objetos de servidor con id, nombre, estado, CPU y memoria, y cuyos metadatos apuntan a ui://servers/dashboard. El ciclo de vida es el siguiente:

El modelo llama a get_servers(). El servidor ejecuta su lógica —base de datos, API en la nube, Kubernetes, servicio interno— y devuelve datos estructurados. El host recibe los metadatos de la interfaz de usuario para ui://servers/dashboard y emite una solicitud resources/read. El servidor devuelve el paquete del frontend (React, Vue o JavaScript puro). Las filas actuales del servidor no se incluyen en ese HTML; la interfaz de usuario solo conoce el contrato esperado (servers[].id, servers[].status, etc.).

El host renderiza la aplicación en un iframe aislado para que el código de la interfaz de usuario proveniente de un servidor MCP no pueda acceder libremente al DOM, a la sesión o a las credenciales del host. Luego, el host entrega el resultado de la herramienta en la vista en ejecución, generalmente mediante JSON-RPC a través de postMessage entre el host y la vista aislada.

La interfaz frontal recibe los datos de la misma manera que cualquier SPA y los muestra en consecuencia. Un servidor genera una tarjeta; cincuenta servidores generan cincuenta tarjetas. La aplicación permanece invariable; solo cambian los datos.

En comparación con una aplicación web clásica, donde React llama a GET /api/servers, en las MCP Apps el agente activa tools/call, la herramienta devuelve JSON, y el anfitrión inyecta ese JSON en una aplicación React dentro de un iframe. La interfaz no siempre obtiene los datos por sí misma; el anfitrión puede enviarle los resultados directamente.

Pero las MCP Apps no son solo resultados de herramientas más atractivos

Una característica más profunda es que la aplicación también puede llamar a herramientas. Los botones, formularios y gráficos no son meramente decorativos; pueden utilizar las mismas herramientas MCP que emplea el agente, a través del anfitrión.

MCP App → call tool → Host → tools/call → MCP Server → restart_server()

Por ejemplo, un control de reinicio dentro del panel de control puede llamar a restart_server a través del anfitrión, en lugar de crear un canal lateral:

async function restartServer(serverId) {
  return app.callServerTool({
    name: "restart_server",
    arguments: { server_id: serverId }
  });
}

El host sigue siendo el encargado de gestionar los permisos, el registro y las políticas.

Una capacidad, dos interfaces

Por lo tanto, la misma operación en el backend puede presentarse de dos maneras: como una herramienta a la que recurre el modelo durante la conversación, y como una aplicación que opera visualmente un humano. Ninguna de las dos reemplaza a la otra. Los agentes siguen siendo eficaces en el razonamiento abierto; las aplicaciones destacan cuando es importante la estructura, la densidad o acciones repetidas.

Un ejemplo en producción: aprobación humana dentro de un flujo de trabajo de agentes

Imagínese a un agente redactando una historia de usuario que debe ser aprobada antes de poder archivarse. Sin aplicaciones, el modelo pega el borrador en el chat y espera que la persona escriba “aprobar” o “rechazar con razones”. Con aplicaciones, una herramienta como present_user_story_for_approval puede devolver el borrador junto con un recurso de interfaz que muestra los controles Aceptar / Solicitar cambios / Rechazar. Al hacer clic en Rechazar se abre un campo para las razones; al enviarlo, se puede llamar a una herramienta que registra la decisión y, opcionalmente, actualiza el contexto del modelo para que en la siguiente interacción ya se sepa por qué falló la versión 1.

Ese patrón implica la participación humana con una superficie de control real, y no un ritual frágil basado en el lenguaje natural.

No todos los botones necesitan ser herramientas visibles para el modelo

Algunas herramientas deberían ser exclusivas para agentes, otras solo para aplicaciones y otras compartidas. La paginación dentro de un panel de control podría accederse únicamente desde la vista, de modo que el modelo no se vea sobrecargado con herramientas para cambiar páginas. El servidor puede indicar diferentes niveles de visibilidad, creando un verdadero límite de acceso en lugar de una mera convención de nomenclatura.

También puede haber comunicación desde la aplicación hacia el contexto del modelo (cuando lo permite el anfitrión): una razón de rechazo introducida en la interfaz de usuario puede actualizar el contexto, permitiendo que la siguiente iteración del modelo mejore el borrador sin que el usuario tenga que volver a escribir la crítica en el chat.

MCP Apps no es una primitiva central nueva

A pesar del nombre, Apps no es un cuarto elemento junto a Herramientas/Recursos/Prompts. Es una extensión que estandariza la relación entre una herramienta y un recurso de interfaz de usuario, además de un protocolo de anfitrión/vista. Dado que las herramientas y los recursos ya son conocidos, Apps constituye una capa interactiva alrededor de ellos, y no un protocolo separado añadido posteriormente.

¿Qué cambia si posees la aplicación de chat?

Los equipos que desarrollan su propia plataforma de agentes se convierten en el anfitrión MCP. Ese anfitrión debe detectar los metadatos de la interfaz de usuario, leer los recursos, ejecutar la aplicación en un entorno aislado, enviar las operaciones de entrada/salida de las herramientas a la vista, enrutar las llamadas a herramientas autorizadas de vuelta al servidor, negociar capacidades y aplicar permisos. Se trata de una verdadera superficie arquitectónica.

Hay tres participantes: el servidor MCP, el anfitrión MCP y la vista de la aplicación MCP, y el SDK oficial separa a los desarrolladores de vistas, a los desarrolladores de anfitriones y a los creadores de servidores. Los paquetes auxiliares se encuentran en @modelcontextprotocol/ext-apps en TypeScript, lo que impide que la lógica empresarial quede confinada a Node. El MCP a nivel de conexión sigue utilizando metadatos de herramientas, recursos, contenido estructurado y solicitudes MCP, por lo que un servidor en Python/FastMCP funciona siempre que exponga lo que esperan los anfitriones con capacidad de aplicaciones. La vista está basada en tecnologías web; los backends existentes pueden permanecer sin cambios.

La seguridad no puede ser algo secundario

Las interfaces de usuario ejecutables elevan el riesgo. Los iframes en entornos aislados y las llamadas mediadas por el servidor ayudan, pero toda aplicación debe tratarse como una interfaz de usuario no fiable, especialmente cuando puede activar restart_service(), delete_resource(), approve_payment() o deploy_to_production(). Los diálogos de confirmación son útiles pero insuficientes. La autenticación, autorización, validación, políticas, registros de auditoría, idempotencia, verificaciones de versión y límites de frecuencia siguen correspondiendo al backend. La interfaz de usuario no constituye el límite de confianza.

Dónde realmente tienen sentido las aplicaciones MCP

No envuelva cada herramienta en una aplicación. Para devolver 42 o una cadena de versión no se necesita React. Las aplicaciones resultan útiles cuando la interacción tiene estructura:

Panoramas de operaciones — servicios, despliegues, infraestructura, registros, métricas, tareas, colas: inspeccionar y luego actuar.

Flujos de aprobación — aprobar/rechazar, aceptar/solicitar cambios, desplegar/cancelar, publicar/mantener en borrador. A menudo es la opción más adecuada para empresas.

RAG y búsqueda de conocimiento empresarial — filtros, casillas de verificación y la opción “Comparar seleccionados” superan a veinte resultados de texto plano, mientras el agente sigue encargándose del razonamiento.

Gobernanza de agentes — el lenguaje natural permite identificar quién puede acceder a Salesforce en producción; una vista de registro es más útil para revisar y aprobar cambios en los permisos.

Formularios y configuración — indicar “CPU 2, memoria 4GB, región us-east-1, réplicas 3” es peor que usar un formulario que el agente puede mostrar cuando sea necesario.

No cree una aplicación por cada herramienta

Evite la proliferación de tool_1 → app_1. Prefiera las aplicaciones basadas en dominio. Una aplicación de “Gestión de despliegues” puede agrupar operaciones como obtener datos, registrar información, reiniciar procesos, escalar recursos y revertir cambios. Una herramienta de entrada permite mostrar la aplicación; posteriormente, la interfaz puede llamar directamente a las operaciones relacionadas. De este modo, la interfaz de usuario mantiene su coherencia y la superficie MCP queda más ordenada.

El cambio arquitectónico más importante

El cambio interesante no es el iframe en sí. Las operaciones diseñadas para agentes ahora pueden ofrecer una capa de interfaz estándar para usuarios humanos:

OPERATION → Machine Interface (MCP Tool) + Human Interface (MCP App)

Si las capacidades se presentan como complementos para agentes, un paquete de Salesforce puede incluir instrucciones, herramientas (search_accounts, create_opportunity, update_lead), permisos, evaluaciones y aplicaciones (navegador de cuentas, formulario de oportunidades, panel de control del pipeline) todo junto. La capacidad resultante se convierte en una superficie de interacción completa tanto para agentes como para usuarios humanos.

El agente no necesita saber si existen React o iframes. Él llama a get_services(...) o present_user_story_for_approval(...); los metadatos le indican al host que existe una interfaz. La interfaz de usuario permanece en la capa de UI, donde se realiza el razonamiento con el agente, mientras que la lógica de negocio está en el backend.

Cómo introduciría esto en un sistema existente

En una plataforma que ya cuenta con chat personalizado, agentes y un servidor FastMCP, evite rediseñar todo. Comience con una funcionalidad de solo lectura como get_agents() junto con la vista más sencilla (ui://agents/list) que muestre nombres, estados y cantidad de herramientas; sin botones. Pruebe el ciclo: el agente llama a la herramienta, el host detecta la UI, lee los recursos, renderiza el iframe y el resultado de la herramienta llega a la vista.

Luego se agrega la opción de Actualizar, seguida de una operación real como Deshabilitar Agente, después la autorización y el registro de auditoría, y finalmente aplicaciones más avanzadas. La adopción avanza de forma gradual sin necesidad de reescribir la lógica del agente.

Los equipos que evalúan su adopción también deben presupuestar para la negociación de capacidades del host. Un servidor consciente de las aplicaciones que siempre incluye metadatos de interfaz de usuario puede seguir funcionando correctamente en clientes antiguos siempre y cuando el host ignore simplemente los campos desconocidos y el contenido estructurado de la herramienta permanezca completo por sí mismo. Por el contrario, un host que afirma tener soporte para aplicaciones debe implementar mecanismos de aislamiento, lectura de recursos y proxy para llamadas a herramientas antes de habilitar la función para los usuarios finales; los hosts implementados parcialmente generan iframes defectuosos que erosionan la confianza más rápido que el JSON puro.

La observabilidad debe formar parte del mismo plan de implementación. Registre qué herramientas contienen recursos de interfaz, qué servidores los renderizaron, cuáles de las llamadas a herramientas iniciadas desde botones tuvieron éxito y cuáles recurrieron al texto. Esas métricas le indican si las aplicaciones realmente cargan elementos interactivos o si los usuarios siguen prefiriendo escribir en el chat. Sin esa telemetría, es fácil lanzar paneles de control en los que nadie hace clic.

Finalmente, mantenga versionados los contratos de esquema. La aplicación y la herramienta deben acordar los nombres y tipos de campos. Si se divide servers[].cpu en objetos anidados sin actualizar el contrato de interfaz, se mostrarán widgets vacíos mientras el agente sigue recibiendo JSON correcto. Trate la carga esperada por la aplicación como una API pública propiedad del mismo equipo que desarrolla la herramienta.

Al medir el éxito después del lanzamiento, hay que diferenciar entre “Aplicación renderizada” y “Aplicación utilizada”. Un iframe que se muestra una vez y nunca recibe clics es algo curioso; en cambio, una aplicación que provoca reinicios, aprobaciones o cambios de configuración tiene un impacto real en el producto. Combine los análisis del producto con los registros de auditoría de MCP para poder mostrar qué acciones humanas provienen de las aplicaciones frente al chat, y si esas acciones redujeron el tiempo de resolución de los tickets que ya manejan los agentes.

Pensamiento final

MCP respondió a la pregunta de cómo los agentes pueden comunicarse con sistemas externos mediante un único protocolo. Las aplicaciones MCP plantean cómo los usuarios pueden aprovechar las mismas capacidades sin salir de la conversación.

Ayer el enfoque fue agente, herramienta, JSON y luego prosa. Hoy una sola capacidad puede dividirse: los modelos siguen llamando a herramientas durante la conversación mientras las personas usan una aplicación visual, y ambas ramificaciones terminan en los mismos servicios de dominio. El razonamiento permanece con el agente, la ejecución con las herramientas, y cuando el trabajo requiere estructura, el protocolo puede mostrar paneles de control, formularios, aprobaciones, gráficos, paneles de configuración y puntos de control humano dentro del chat, sin abandonar la capa MCP de la que ya dependen los agentes.

Por eso MCP Apps es algo más que respuestas más atractivas: los servidores están evolucionando de puntos finales orientados a máquinas a capas de interacción portátiles tanto para agentes como para humanos.

Indique explícitamente las soluciones de respaldo en el README de su servidor: qué herramientas declaran los recursos de la interfaz de usuario, qué servidores son conocidos por renderizarlos y cómo se verá el texto o la información estructurada como respaldo cuando las aplicaciones no estén disponibles. Esa documentación evita tickets de soporte del tipo “MCP está roto” cuando el problema real es que un servidor no tiene la extensión activada.

Leer más

La documentación principal para la extensión Apps se publica en apps.extensions.modelcontextprotocol.io (secciones de resumen y API). Las descripciones cronológicas aparecen en blog.modelcontextprotocol.io para la propuesta de 2025, la declaración de producción de 2026 y el track de extensiones en versión candidata. El blog de Machine Learning de AWS mostró posteriormente un patrón de hosting para Bedrock AgentCore que sigue siendo independiente del servidor.

Si actualmente mantienes varios servidores MCP, resiste la tentación de crear un mini-marco privado para cada equipo. Prefiere utilidades en el host compartido para el ciclo de vida del iframe, tipos TypeScript compartidos para los datos que consumen las aplicaciones, y una breve lista de verificación para la revisión del diseño: ¿Necesita esta herramienta una interfaz de usuario? ¿Existe ya alguna aplicación que pueda incorporarla? ¿Cuál es la solución de respaldo cuando el host no puede renderizar las aplicaciones? ¿Quién se encarga de la autorización para las llamadas activadas por botones? Esas cuatro preguntas evitan que la cantidad de aplicaciones crezca de forma prematura.

La capacitación también es importante. Los agentes que de repente ven menos herramientas porque algunas operaciones pasaron a estar disponibles únicamente dentro de la aplicación se comportarán de manera diferente. Actualice los mensajes del sistema y los conjuntos de evaluación al dividir los niveles de acceso, y mantenga una prueba de ruta estándar que abra la aplicación, haga clic en una acción segura y verifique que aparezca la fila de auditoría del backend. Sin esa prueba, las regresiones permanecen ocultas en el iframe hasta que un cliente informa de un botón inoperativo.

Con estos elementos en su lugar, las aplicaciones MCP dejan de parecer algo novedoso y comienzan a considerarse parte integral de las plataformas para agentes. Esto cierra el ciclo de adopción gracias a soluciones alternativas claras y un uso medible.