Das Gadget-Team teilt seinen Erfahrungsbericht nach mehreren Tagen intensiver Entwicklungsarbeit mit dem neuen ChatGPT Apps SDK von OpenAI. Der Artikel beschreibt die drei wesentlichen Komponenten einer ChatGPT-Anwendung: einen MCP server, der dem Model Context Protocol entspricht, eine Erweiterung, die die Anzeige von Benutzeroberflächen innerhalb von Konversationen ermöglicht, sowie optional einen OAuth 2.1-Server mit OIDC zur Authentifizierung.
Für den Aufbau von MCP-Servern empfiehlt der Artikel die Verwendung des Streamable-HTTP-Transports anstelle der in den offiziellen Beispielen von OpenAI vorgestellten SSE-Version. Die bereitgestellten Beispiele verwenden eine In-Memory-Session-Map, die für Serverless-Plattformen ungeeignet ist. Der MCP Inspector wird für die anfängliche Fehlersuche empfohlen, da die Fehlermeldungen von ChatGPT wenig aussagekräftig sind.
Die Implementierung der OAuth 2.1-Authentifizierung stellt einen Paradigmenwechsel dar: Anders als bei der üblichen Praxis, zu einem externen Anbieter wie Google umzuleiten, muss die Anwendung hier selbst als OAuth-Provider für OpenAI auftreten. Dies erfordert die Implementierung der OIDC-Discovery-Endpunkte, die es ChatGPT ermöglichen, Tokens zu erhalten.
Die innovativste Funktion ist die Möglichkeit, den Nutzern interaktive UI-Widgets bereitzustellen. Diese Widgets sind faktisch sandboxed iframes, die ein statisches HTML-Dokument laden, das zum Zeitpunkt der Installation der Anwendung zwischengespeichert wird. Diese Einschränkung erfordert die Entwicklung clientseitiger Single-Page-Anwendungen ohne dynamisches serverseitiges Rendering. Das Team empfiehlt Vite für die TypeScript-Kompilierung, das Bundling, Hot-Module-Reloading und die Tailwind-Unterstützung. Ein dedizierter Vite-Plugin ist auf GitHub verfügbar.
Für die Kommunikation mit dem Backend aus einem Widget heraus gibt es zwei Ansätze. Das von OpenAI injizierte Objekt window.openai ermöglicht den Aufruf von MCP-Tools, wobei die Authentifizierung automatisch gehandhabt wird und dem LLM Einblick in die Interaktionen gewährt wird. Die Alternative über direktes fetch erfordert eine manuelle Handhabung der Authentifizierung und verliert das kontextuelle Bewusstsein des LLM.
CORS stellt eine große Herausforderung dar, mit drei unterschiedlichen Konfigurationen, die verwaltet werden müssen: MCP-Routen, OAuth 2.1-Routen und Frontend-Assets. Für die ersten beiden wird ein permissiver Access-Control-Allowed-Origin: *-Header empfohlen, da die Authentifizierung die Aufrufe bereits absichert. Für Widget-Assets muss der von OpenAI verwendete Origin https://web-sandbox.oaiusercontent.com zugelassen werden.
Der Artikel kommt zu dem Schluss, dass das Ökosystem noch sehr jung, aber vielversprechend ist, wobei bei Gadget einsatzbereite Templates verfügbar sind, um den Einstieg zu beschleunigen.