El equipo de Gadget comparte su informe de experiencia tras varios días de desarrollo intensivo con el nuevo ChatGPT Apps SDK de OpenAI. El artículo detalla los tres componentes esenciales de una aplicación ChatGPT: un MCP server conforme al Model Context Protocol, una extensión que permite mostrar interfaces de usuario dentro de las conversaciones y, opcionalmente, un servidor OAuth 2.1 con OIDC para la autenticación.
Para la construcción de MCP servers, el artículo recomienda usar el transporte Streamable HTTP en lugar de la versión SSE presentada en los ejemplos oficiales de OpenAI. Los ejemplos proporcionados utilizan un mapa de sesiones en memoria que no es adecuado para plataformas serverless. Se recomienda MCP Inspector para la depuración inicial, dado que los mensajes de error de ChatGPT son poco informativos.
Implementar la autenticación OAuth 2.1 representa un cambio de paradigma: a diferencia de la práctica habitual de redirigir a un proveedor externo como Google, aquí la propia aplicación debe actuar como el proveedor OAuth para OpenAI. Esto exige implementar los endpoints de descubrimiento OIDC que permiten a ChatGPT obtener tokens.
La funcionalidad más innovadora es la capacidad de servir widgets de interfaz interactivos a los usuarios. Estos widgets son en realidad iframes en sandbox que cargan un documento HTML estático, almacenado en caché en el momento de la instalación de la aplicación. Esta restricción obliga a desarrollar aplicaciones de una sola página (single-page applications) del lado del cliente, sin renderizado dinámico en el servidor. El equipo recomienda Vite para la compilación TypeScript, el bundling, el hot-module-reloading y el soporte de Tailwind. Hay disponible un plugin de Vite dedicado en GitHub.
Para la comunicación con el backend desde un widget existen dos enfoques. El objeto window.openai, inyectado por OpenAI, permite invocar herramientas MCP con la autenticación gestionada automáticamente y visibilidad para el LLM sobre las interacciones. La alternativa mediante fetch directo exige gestionar la autenticación manualmente y pierde la conciencia contextual del LLM.
CORS constituye un desafío mayor, con tres configuraciones distintas que gestionar: las rutas MCP, las rutas OAuth 2.1 y los activos del frontend. Para las dos primeras, se recomienda una cabecera permisiva Access-Control-Allowed-Origin: *, ya que la autenticación ya asegura las llamadas. Para los activos de los widgets, debe autorizarse el origen https://web-sandbox.oaiusercontent.com utilizado por OpenAI.
El artículo concluye que el ecosistema aún es muy joven pero prometedor, con plantillas listas para usar disponibles en Gadget para acelerar el inicio.