⏱️ Lectura: 11 min
Hay una vieja regla en la cultura geek: si una plataforma puede ejecutar código, alguien intentará correr DOOM en ella. Lo hemos visto en calculadoras, refrigeradores, lectores de tarjetas de crédito, podadoras de césped y hasta en pruebas de embarazo. La última frontera, sin embargo, no es un dispositivo físico: es un cliente de inteligencia artificial. El experimento de DOOM en MCP que publicó Chris Nager en abril de 2026 demostró que el shooter de id Software de 1993 puede ejecutarse inline dentro de ChatGPT y Claude usando el protocolo Model Context Protocol (MCP) de Anthropic.
📑 En este artículo
- Qué es MCP y por qué este experimento importa
- Cómo funciona DOOM en MCP por dentro
- El problema real: iframes, CSP y MCP apps
- WAD paths, blobs y otros dolores
- El stack de despliegue: Netlify y un dominio propio
- Lo que este experimento revela sobre los agentes IA
- Por qué la simplificación final fue la mejor decisión
- Preguntas frecuentes
- Referencias
El truco no es solo una broma técnica. Es una de las primeras demostraciones públicas de lo que las MCP apps —aplicaciones de UI interactiva que se renderizan dentro de los hosts de MCP— pueden lograr cuando se las empuja más allá de su uso típico de “búscame algo en mis archivos”. Y para los desarrolladores en LATAM que están empezando a construir agentes con Claude, ChatGPT o herramientas como Cursor, este experimento ilumina varias decisiones de arquitectura que importan en serio.
Qué es MCP y por qué este experimento importa
El Model Context Protocol es un estándar abierto que Anthropic lanzó en noviembre de 2024 para que los modelos de lenguaje puedan conectarse de forma uniforme con herramientas, datos y aplicaciones externas. La analogía oficial es “USB-C para LLMs”: en lugar de que cada cliente (Claude Desktop, Cursor, Zed, ChatGPT) implemente integraciones a medida, todos hablan el mismo protocolo y los servidores MCP se vuelven plug-and-play.
Hasta hace poco, los servidores MCP devolvían principalmente texto, imágenes o llamadas a herramientas. Las MCP apps son una capa más reciente: vistas de UI interactiva que el host puede renderizar en un iframe controlado, dejando que el servidor MCP “pinte” su propia interfaz dentro del cliente del usuario. Es ahí donde se vuelve interesante el experimento de DOOM en MCP: si un servidor puede renderizar HTML, JavaScript y un canvas inline, entonces puede renderizar literalmente un juego.
💭 Clave: MCP empezó como una forma de exponer herramientas de texto a un modelo. Las MCP apps lo extienden a UI completa. DOOM corriendo dentro de Claude no es el objetivo; es la prueba de que el techo es mucho más alto de lo que parecía.
Cómo funciona DOOM en MCP por dentro
La arquitectura final que describe Chris Nager es deliberadamente austera. Después de iterar varias versiones complejas con persistencia de sesiones, capturas de pantalla y adaptadores de guardado, terminó cortando casi todo. La versión publicada se reduce a tres piezas:
- Una herramienta MCP llamada
create_doom_sessionque arranca una sesión inline en clientes que soportan MCP apps. - Otra herramienta MCP llamada
get_doom_launch_urlque devuelve una URL plana, como fallback para clientes que no pueden renderizar UI inline. - Una ruta de navegador en
/doom/playque ejecuta el juego con un token firmado pasado en la URL.
El motor de DOOM corre con cloudflare/doom-wasm, que compila el engine original a WebAssembly. Como contenido por defecto se usa Freedoom Phase 1, una alternativa libre a los WAD originales de id Software, lo que mantiene el proyecto redistribuible sin problemas de licencia.
El detalle más elegante es el token firmado: la URL de lanzamiento contiene un token criptográfico que basta para arrancar el juego, sin que el navegador tenga que hacer round-trips al servidor para mantener estado. Esto importa porque desacopla el servidor MCP del runtime de DOOM. El servidor solo emite el token; el navegador (sea el del usuario, sea un iframe dentro de Claude) ejecuta el juego sin más diálogo con el backend.
El problema real: iframes, CSP y MCP apps
La parte difícil del proyecto no fue compilar DOOM a WebAssembly —ese terreno está más que pisado—. Fue hacer que el mismo código corriera limpiamente en clientes con políticas de seguridad muy distintas. Cada host MCP (Claude Desktop, Claude web, ChatGPT, Codex, etc.) impone reglas diferentes sobre iframes anidados, Content Security Policy y frame-src.
La primera versión de Nager intentaba algo razonable en papel: la MCP app abría un iframe que a su vez embebía la página /doom/play. Funcionó en algunos hosts y reventó en otros, no por culpa del juego sino por las restricciones que ponía el host al contenido enmarcado. La solución fue dejar de tratar la MCP app como un contenedor que envuelve otra página y empezar a tratarla como la página misma: el canvas de DOOM se monta directo dentro del iframe que ya renderiza el host.
flowchart LR
U["Usuario en Claude/ChatGPT"] --> H["Host MCP"]
H -->|llama tool| S["Servidor MCP"]
S -->|firma token| T["Token JWT"]
T --> A["MCP App iframe"]
A -->|carga WAD| W["DOOM WASM"]
W --> C["Canvas inline"]Eso eliminó toda una clase de bugs: nada de iframes anidados, nada de fallos de frame-src, nada de suposiciones extra de navegación. Es la lección clásica de “cuando tu solución es frágil porque tiene una capa de más, quita la capa”.
💡 Tip: Si estás construyendo una MCP app, no asumas que podés embeber tu propia página dentro del iframe del host. Trabajá con el host como si fuera tu navegador y montá el contenido directamente.
WAD paths, blobs y otros dolores
Una de las partes menos glamorosas del proyecto fue resolver de dónde carga el motor sus archivos WAD (los paquetes de assets de DOOM) y archivos de configuración. La app funcionaba en un entorno y luego intentaba cargar el WAD desde el origen equivocado en otro. La causa: el host MCP a veces servía la app desde una URL diferente a la que el código asumía como base.
Nager terminó eliminando el camino de blob preload (donde los assets se cargaban como blobs de JavaScript) y escribió los WAD y config directamente en el sistema de archivos virtual de Emscripten. Menos piezas en movimiento, menos puntos de falla. Un patrón útil cuando trabajás con WebAssembly: cuanto más explícito sea el control de archivos, más predecible el comportamiento entre hosts.
El stack de despliegue: Netlify y un dominio propio
Todo el proyecto vive bajo chrisnager.com/doom/*. La ruta /doom/play sirve el shell del navegador y /doom/mcp expone el servidor MCP. La elección de Netlify implicó adaptar la estructura para que las funciones serverless del servidor MCP convivieran con los assets estáticos del juego sin romper paths.
Para desarrolladores en LATAM que quieran replicar este patrón, el costo es accesible: el plan gratuito de Netlify alcanza para experimentos de este tipo, y el motor de DOOM compilado a WASM pesa unos pocos megabytes. Si quisieras montar algo similar, una versión simplificada se vería así:
# Estructura mínima del proyecto
# Windows / macOS / Linux — funciona igual con Node 20+
npm create vite@latest mi-mcp-doom
cd mi-mcp-doom
npm install @modelcontextprotocol/sdk
npm install
# servidor MCP mínimo en src/server.ts
# (expone create_doom_session y get_doom_launch_url)
netlify deploy --prod
Lo que este experimento revela sobre los agentes IA
DOOM en MCP es un meme funcional, pero también es un mensaje claro: los hosts de MCP están dejando de ser ventanas de chat y se están convirtiendo en navegadores embebidos con permisos. Cuando un servidor puede pintar UI interactiva dentro de Claude, las posibilidades dejan de limitarse al texto: dashboards, formularios, editores de código, simuladores, herramientas de visualización 3D y, sí, juegos.
Para equipos en LATAM que están explorando agentes verticales —legaltech, fintech, agro, salud, educación—, la implicación práctica es que la UI ya no tiene que vivir en una app aparte. Un servidor MCP puede entregar la herramienta y la interfaz al mismo cliente, sin que el usuario tenga que abandonar el chat con el agente. Eso simplifica enormemente el modelo mental de despliegue.
⚠️ Ojo: Esto también amplía la superficie de ataque. Una MCP app maliciosa puede renderizar UI engañosa dentro de un cliente confiable. Antes de instalar servidores MCP de terceros, revisá el código y limitá los permisos que el host concede a apps inline.
Por qué la simplificación final fue la mejor decisión
En versiones intermedias el proyecto tenía save/load, reportes de estado, capturas de pantalla, persistencia de sesiones y un flujo de bootstrap verificado en servidor. Nager cortó casi todo. La forma final son tres piezas: una tool inline, una tool fallback, una ruta de navegador.
La moraleja vale para cualquier proyecto con MCP: la complejidad innecesaria se paga en bugs cruzados entre hosts. Cada feature extra multiplica las combinaciones posibles entre versiones de cliente, políticas de iframe y bugs específicos de Codex, Claude o ChatGPT. Mantener la superficie pequeña hace que el proyecto sea estable, divertido y, sobre todo, mantenible.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué es exactamente una MCP app?
Una MCP app es una aplicación de UI interactiva que un servidor MCP expone para que el host (Claude Desktop, ChatGPT, etc.) la renderice inline dentro del chat. A diferencia de las herramientas tradicionales que devuelven texto, las MCP apps permiten que el servidor entregue HTML, JavaScript y canvas que se ejecutan dentro del cliente.
¿Funciona DOOM en MCP en cualquier cliente?
No. Funciona inline solo en hosts que soportan MCP apps con UI interactiva, como Claude Desktop, Claude web y versiones recientes de ChatGPT con MCP habilitado. En clientes que no soportan UI inline, la herramienta get_doom_launch_url devuelve una URL para abrir el juego en un navegador externo.
¿Es legal redistribuir DOOM de esta forma?
El experimento usa Freedoom Phase 1, un conjunto de assets libres compatibles con el motor de DOOM. Los WAD originales de id Software son propiedad de Bethesda/Microsoft y no se redistribuyen. El motor en sí está disponible bajo GPL desde 1997, lo que permite portarlo a WebAssembly y otros entornos.
¿Puedo construir mi propia MCP app sin saber WASM?
Sí. Una MCP app puede ser cualquier página HTML/JS estática. WebAssembly se usa solo cuando necesitás portar código nativo (como un motor de juego o una librería en C). Para dashboards, formularios o herramientas de productividad, basta con HTML, CSS y JavaScript moderno.
¿Qué riesgos de seguridad introducen las MCP apps?
Como cualquier código que se ejecuta dentro de un cliente confiable, una MCP app maliciosa puede mostrar UI engañosa, capturar input del usuario o hacer phishing dentro del propio chat. Anthropic y otros hosts aplican CSP estricta y aislamiento por iframe, pero la responsabilidad última de auditar servidores MCP de terceros recae en el usuario.
¿Para qué sirve esto más allá del meme?
El experimento valida que MCP apps pueden entregar interfaces gráficas completas dentro de un cliente de IA. Aplicaciones reales: editores de código embebidos, dashboards de datos en vivo, herramientas de diseño, simuladores educativos y consolas de administración para agentes que operan sobre infraestructura.
Referencias
- Chris Nager — DOOM runs in ChatGPT and Claude — post original con detalles técnicos del experimento.
- Cloudflare doom-wasm — port a WebAssembly del motor de DOOM usado en el proyecto.
- Freedoom — assets libres compatibles con el motor de DOOM, base del contenido por defecto.
- Model Context Protocol — documentación oficial del protocolo abierto creado por Anthropic.
- chrisnager.com/doom/play — demo en vivo del experimento accesible desde cualquier navegador.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios