DOOM corre en Claude y ChatGPT gracias a MCP Apps

Un desarrollador llamado Chris Nager creó en abril de 2026 una MCP app completamente jugable de DOOM que se ejecuta inline dentro de ChatGPT y Claude, usando el Model Context Protocol como plataforma de renderizado. La app tiene dos herramientas MCP: una que abre la sesión de DOOM directamente en el chat, y otra que devuelve una URL de lanzamiento como fallback para clientes que no soportan UI inline.

Qué es el Model Context Protocol (MCP)

El Model Context Protocol (MCP) es un estándar abierto creado por Anthropic en noviembre de 2024 que define cómo los modelos de lenguaje se conectan con herramientas externas, bases de datos y recursos de contexto. La arquitectura tiene tres componentes: el host (el cliente IA, como Claude Desktop o ChatGPT), el MCP client (la capa que gestiona el protocolo dentro del host) y el MCP server (el servicio que expone herramientas o recursos). Toda la comunicación entre ellos corre sobre JSON-RPC 2.0.

El problema que resuelve MCP es concreto: antes de que existiera, cada integración entre una IA y una herramienta externa era un desarrollo a medida. Conectar Claude con tu base de datos requería una solución distinta a conectar GPT con esa misma base de datos. MCP estandariza ese contrato.

En marzo de 2026, Anthropic donó la especificación a la Linux Foundation, lo que convirtió a MCP en un estándar de gobernanza abierta. Hoy el SDK acumula más de 110 millones de descargas mensuales, y el roadmap 2026 incluye autenticación OAuth nativa, mejoras en los mecanismos de transporte y soporte para streaming bidireccional.

Apps MCP con interfaces interactivas: más allá de las herramientas

Acá viene lo bueno: MCP en su forma base solo maneja herramientas y recursos (datos). Un tool MCP devuelve texto, JSON, un archivo. Punto. Lo que cambia con MCP Apps es que el servidor puede devolver HTML y JavaScript que el host renderiza en un iframe seguro, embebido directamente en la interfaz del chat.

Según la especificación del protocolo, las MCP Apps son “aplicaciones UI interactivas que se renderizan dentro de hosts MCP como Claude Desktop”. Los hosts que hoy soportan esta funcionalidad incluyen Claude Desktop, ChatGPT, VS Code Insiders y Goose. Si el host no soporta UI inline, la misma app devuelve una URL de lanzamiento como fallback. Eso es progressive enhancement: un solo servidor, dos comportamientos según el entorno.

El modelo de seguridad usa iframes con políticas de Content Security Policy (CSP) configuradas por cada host. Ahí está buena parte de la complejidad técnica, como vamos a ver.

El experimento DOOM de Chris Nager

Ponele que te preguntás qué tan lejos puede llegar una MCP App. Chris Nager se hizo la misma pregunta y contestó con DOOM.

Según su propio relato, el proyecto arrancó con una pregunta simple: “¿Puede correr DOOM?”. La respuesta fue sí, pero la parte difícil no fue hacer correr DOOM en un browser (eso ya estaba resuelto). La parte difícil fue hacer que la misma sesión funcionara correctamente en Claude Desktop y en ChatGPT, que tienen reglas distintas sobre iframes, CSP y rendering de UI.

La arquitectura final es deliberadamente minimal:

• Un tool MCP que crea una sesión de DOOM inline (para hosts con soporte UI).
• Un tool MCP que devuelve una URL de lanzamiento plana (para el resto).
• Un sistema de signed tokens que pasa por la URL de lanzamiento y mantiene la sesión consistente entre clientes.
• Deploy en Netlify para el frontend.
• Doom.js como motor de emulación, que le dio el runtime real de DOOM sin tener que compilar el engine desde cero.

El proyecto usa la ROM shareware de DOOM por defecto (la versión distribuible legalmente), lo que mantiene al proyecto redistribuible sin problemas de licencia.

Cómo funciona técnicamente DOOM en MCP

El flow completo cuando pedís DOOM en el chat va así: el usuario escribe algo como “iniciá DOOM” → el host llama al MCP server → el server detecta si el host soporta UI inline → si lo soporta, devuelve el HTML/JS de la app con un signed token embebido → el host renderiza ese HTML en un iframe seguro → Doom.js inicializa el engine en un canvas HTML5 → el input de teclado y mouse se captura dentro del iframe y se procesa localmente.

Lo que no hay son iframes anidados. Nager simplificó la arquitectura para evitar la complejidad que eso implica en términos de CSP y permisos de input. El signed token es lo que permite que, si abrís la misma sesión desde un cliente diferente (que no soporta UI inline y te manda a la URL), la sesión sea la misma.

¿Y qué pasó con las diferencias de CSP entre Claude y ChatGPT? Exactamente lo que te imaginás: requirió ajustes específicos para cada host, porque cada uno tiene sus propias políticas sobre qué puede hacer un iframe embebido. No es algo que MCP resuelva de manera uniforme todavía (está en el roadmap 2026).

Otros ejemplos de apps MCP con interfaces interactivas

DOOM es el caso que agarró atención, pero en el repositorio oficial de MCP Apps en GitHub hay ejemplos que tienen más aplicación práctica inmediata:

Visualización geoespacial

Mapas 3D interactivos construidos con CesiumJS o Three.js que se renderizan inline en el chat. Útil para agentes de análisis geográfico donde el usuario necesita ver el mapa mientras hace preguntas sobre los datos.

Dashboards en tiempo real

Monitores de sistema que actualizan métricas dentro del chat sin abrir otro tab. Para equipos de DevOps que ya viven en el cliente IA, reducir el salto entre la conversación y la visualización tiene sentido.

Visualizadores de documentos

PDFs y partituras musicales que se renderizan con controles de navegación inline. La diferencia con un link al PDF es que el modelo puede ver lo mismo que vos y razonar sobre contenido específico de páginas.

Generadores con output visual

QR codes y gráficos que se generan y muestran directamente en la respuesta. Zafa para casos de uso donde el ciclo generar-verificar-ajustar beneficia de no salir del chat.

Por qué DOOM en MCP importa más allá de la novedad

DOOM no es el caso de uso. Es la prueba de concepto.

Lo que demuestra es que MCP Apps puede manejar aplicaciones con estado persistente, input en tiempo real y rendering complejo, no solo herramientas que reciben un input y devuelven texto. Eso abre la puerta a un paradigma donde los agentes IA tienen interfaces embebidas en vez de redirigirte constantemente a otro lugar.

Empresas como PayPal (agentes de commerce), Elastic (observabilidad de seguridad) y Microsoft (con Azure Functions como MCP servers) ya están construyendo sobre el protocolo, pero en el modelo herramientas-y-recursos clásico. La capa de UI interactiva todavía está en adopción temprana.

Dicho esto, el camino hasta que esto sea mainstream tiene fricción real: la fragmentación de políticas CSP entre hosts, la falta de un estándar de autenticación nativo dentro de MCP Apps (que el roadmap 2026 promete resolver), y el hecho de que construir una MCP App que funcione bien en Claude Desktop y ChatGPT hoy requiere ajustes específicos por host. Nager lo documenta sin embellecer: la compatibilidad cross-client fue la parte difícil.

Cómo crear tu propia aplicación MCP

Si querés experimentar, el punto de entrada más directo es el repositorio oficial en github.com/modelcontextprotocol/ext-apps. Los SDKs disponibles en 2026 cubren Python, TypeScript, C#, Java y Rust. El flujo básico para una MCP App con UI:

• Definí los tools de tu servidor MCP (mínimo uno que devuelva el HTML de la UI).
• El HTML que devolvés puede usar cualquier framework JS estándar; el host lo renderiza en un iframe.
• Para sesiones persistentes, implementá un sistema de tokens firmados (como hace el proyecto DOOM).
• Registrá el servidor en Claude Desktop editando el archivo de configuración claude_desktop_config.json, o en ChatGPT desde la sección de conectores.
• Probá primero en Claude Desktop, que hoy tiene el soporte más maduro para UI inline.

Anthropic tiene un curso introductorio de MCP. Microsoft publicó un currículo “MCP for Beginners” en GitHub. Si vas a deployar el server (como hizo Nager con Netlify), cualquier proveedor que soporte Node.js o Python alcanza. Para proyectos propios en Argentina, donweb.com tiene planes de hosting que soportan ambos stacks sin configuración compleja.

Errores comunes al trabajar con MCP Apps

Asumir que todos los hosts tienen las mismas políticas de CSP. No las tienen. Claude Desktop, ChatGPT y VS Code Insiders manejan los iframes con reglas distintas. Si tu app funciona en uno y no en otro, el problema casi siempre está en las directivas de Content-Security-Policy que tu servidor devuelve en los headers. Testeá en cada host por separado.

Confundir MCP tools con MCP Apps. Un tool MCP devuelve datos o ejecuta acciones. Una MCP App devuelve HTML que se renderiza como UI. Son dos mecanismos distintos dentro del mismo protocolo. Tu servidor puede tener ambos (como el proyecto DOOM, que tiene un tool para la sesión inline y otro para la URL de fallback), pero no son intercambiables.

No implementar el fallback a URL. Si tu MCP App solo funciona cuando el host soporta UI inline, dejás afuera a todos los clientes que no lo hacen. El patrón correcto es progressive enhancement: detectá si el host soporta inline y, si no, devolvé una URL funcional. Nager lo hizo bien; muchos ejemplos del repositorio oficial se saltean este paso.

Ignorar el estado de la sesión entre clientes. Si el usuario empieza en Claude Desktop y después abre la URL en el browser, ¿la sesión continúa? Si no implementás un mecanismo de tokens firmados, no. Para apps simples no importa; para apps con estado (juegos, dashboards, flujos multi-paso) es crítico desde el principio.

Preguntas Frecuentes

¿Qué es el Model Context Protocol y cómo funciona?

El Model Context Protocol (MCP) es un estándar abierto creado por Anthropic en noviembre de 2024 que define cómo los modelos de lenguaje se conectan con herramientas y recursos externos usando JSON-RPC 2.0. El host (cliente IA) se comunica con un MCP server que expone tools (acciones) y resources (datos). Desde marzo de 2026, la especificación está bajo la Linux Foundation.

¿Cómo se ejecuta DOOM dentro de ChatGPT y Claude?

El MCP server de Chris Nager usa Doom.js para ejecutar el engine de DOOM en el browser y sirve el HTML/JS de la app al host IA mediante MCP Apps. Si el host soporta UI inline (Claude Desktop, ChatGPT), el juego aparece directamente en el chat dentro de un iframe seguro. Si no, el servidor devuelve una URL donde el juego carga normalmente en el browser.

¿Cuál es la diferencia entre MCP apps y extensiones tradicionales?

Las extensiones tradicionales son específicas de cada plataforma (una extensión de Chrome no funciona en Firefox, una extensión de VS Code no funciona en otro editor). Un MCP server es agnóstico al host: el mismo servidor puede conectarse a Claude, ChatGPT, VS Code Insiders o cualquier otro cliente que implemente el protocolo. Las MCP Apps agregan la capacidad de renderizar UI dentro de esos hosts sin desarrollar nada específico por plataforma, salvo ajustes de CSP.

¿Qué otros ejemplos de aplicaciones MCP existen?

El repositorio oficial en github.com/modelcontextprotocol/ext-apps incluye mapas 3D interactivos (CesiumJS, Three.js), dashboards de métricas en tiempo real, visualizadores de PDF con navegación, generadores de QR codes, monitores de sistema y partituras musicales interactivas. Empresas como PayPal, Elastic y Microsoft ya tienen integraciones MCP en producción, aunque en su mayoría usan el modelo de tools y resources, no MCP Apps con UI.

¿Cómo creo mi propia aplicación MCP con interfaz gráfica?

Necesitás un MCP server (Python, TypeScript, Java, C# o Rust) que exponga al menos un tool que devuelva HTML/JS como respuesta. Ese HTML se renderiza en un iframe dentro del host IA. El server se registra en Claude Desktop editando claude_desktop_config.json, o en ChatGPT desde la sección de conectores. Para el deploy del server, cualquier proveedor que soporte el runtime que uses alcanza. El repositorio de ejemplos oficial en GitHub tiene plantillas para arrancar.

Conclusión

DOOM en MCP es trivial como juego. Como demostración de capacidades, no lo es tanto. Lo que Nager construyó prueba que el protocolo puede sostener aplicaciones interactivas complejas, con estado, con input en tiempo real, dentro de interfaces de chat. Eso cambia la escala de lo que se puede construir encima de MCP.

Las apps MCP con interfaces interactivas están en adopción temprana y tienen fricciones reales (fragmentación de CSP por host, autenticación todavía en desarrollo). Pero el roadmap de 2026 apunta directamente a esos problemas. Si desarrollás herramientas para equipos que ya viven en Claude o ChatGPT, este es el momento de explorar qué UI podés embeber ahí en vez de pedirle al usuario que abra otro tab.

El experimento de DOOM no es una curiosidad tecnológica. Es el tipo de prueba de concepto extrema que define los límites de una plataforma. Y los límites de MCP Apps, hoy por hoy, son más amplios de lo que la mayoría imagina.

Fuentes

• Chris Nager — DOOM runs in ChatGPT and Claude (proyecto original)
• Model Context Protocol Blog — Roadmap 2026
• Especificación oficial MCP 2025-11-25
• Repositorio oficial MCP Apps en GitHub
• Dev.to — DOOM corre dentro de ChatGPT y Claude gracias a MCP Apps