MCP Apps: cuando una tool necesita una interfaz y no otro párrafo
MCP Apps existe para los casos donde una tool necesita que una persona vea y elija algo. Un calendario, una tabla de resultados o una aprobación con varios campos no mejoran porque el modelo los describa en prosa. Necesitan una interfaz, pero sin convertir el servidor MCP en una aplicación web sin límites.
La extensión oficial MCP Apps permite que una tool enlace a un recurso HTML que el cliente muestra embebido. El modelo sigue llamando tools; la interfaz presenta los datos y puede pedir acciones dentro de un canal definido por el protocolo.
El resultado de la tool no tiene que ser solo texto
Imagina una tool que prepara cambios para veinte facturas. Un resultado textual obliga al agente a resumir una lista larga y al usuario a aprobar a ciegas. Con una App, la tool puede devolver los datos estructurados y enlazar a una vista que los renderiza.
La especificación obliga a registrar el recurso de UI antes de usarlo, bajo una URI ui://, y a referenciarlo desde la metadata de la tool en _meta.ui.resourceUri. Con la plantilla separada de los datos, el host puede inspeccionarla o precargarla antes de ejecutar nada, y un cliente que no implemente la extensión se queda con la respuesta de texto. Es lo que permite que la tool siga sirviendo en clientes distintos sin exigirles que rendericen tu interfaz.
El iframe no recibe carta blanca
Una MCP App se ejecuta en un iframe sandboxed. La UI habla con el host mediante mensajes JSON-RPC sobre postMessage; no obtiene acceso directo al servidor ni a las tools porque sí. Si quiere llamar una herramienta, el host media la petición y decide qué aprobar.
Una vista que llega de un servidor remoto es código ejecutándose en el cliente. El host debe limitar dominios con una Content Security Policy, mostrar de dónde viene la acción y aplicar el mismo modelo de permisos que aplicaría a una tool invocada por el agente.
Agente → tool del servidor → datos + recurso ui://
Host → iframe sandboxed → vista interactiva
Vista → petición de tool → host decide si la reenvíaEl servidor no debería usar una UI para esconder una operación que el usuario no habría aprobado como tool. Si la vista solicita "enviar factura", el host debe poder atribuir esa llamada al servidor y aplicar confirmación o una política explícita.
Cuándo vale la pena crear una App
No la uses para mostrar un resultado que cabe en una frase. Tiene sentido cuando la persona tiene que comparar filas, editar campos o revisar una acción antes de ejecutarla, y por eso un formulario o un flujo con estado la aprovechan mucho más que una respuesta a la que solo le falta formato.
La especificación pide además que el servidor ofrezca un comportamiento de solo texto para toda tool con UI, y que la tool devuelva un array content con contenido significativo aunque la interfaz esté disponible. MCP Apps es una extensión opcional, así que un cliente que no la implemente tiene que seguir recibiendo la información que necesita.
Preguntas frecuentes
¿MCP Apps reemplaza a una aplicación web?
No. Es una UI pequeña servida por una tool dentro de un cliente MCP. Para un producto completo sigues necesitando tu aplicación, autenticación y rutas normales.
¿La App puede llamar cualquier tool?
No. La especificación da a cada tool un campo visibility, que por defecto vale ["model", "app"], y obliga al host a rechazar una petición tools/call que venga de la App para una tool que no incluya "app". Con visibility: ["app"] una herramienta queda disponible para la interfaz y oculta al modelo.
¿Funciona en todos los clientes MCP?
No necesariamente. Es una extensión opcional, por eso el fallback de texto es parte del diseño.
Fuentes
¿Tienes un proyecto en mente?
Trabajo con Laravel, WordPress, SEO técnico y servidores MCP. El primer paso es una llamada de descubrimiento, sin costo ni compromiso, donde me cuentas qué necesitas y te digo con honestidad si puedo ayudarte.