Ein ChatGPT-MCP-Server ist nicht fertig, nur weil /mcp antwortet. ChatGPT muss den Server erreichen, die richtigen Tools erkennen, Nutzer authentifizieren und die Tools passend auswählen können. Für die meisten Teams ist Managed Hosting der sinnvollste Standard. Private Infrastruktur gehört hinter den Secure MCP Tunnel.
Lege die Betriebsgrenze fest, bevor du Code schreibst
Die gewählte Betriebsgrenze bestimmt Transportweg, Authentifizierungsaufwand, operativen Betrieb und die Frage, ob sich der Server veröffentlichen lässt. ChatGPT ist ein entfernter MCP-Client und startet nicht direkt einen lokalen stdio-Prozess, wie es manche Desktop-Clients tun (OpenAI Help Center).
| Betriebsmodell | ChatGPT-Verbindung | Geeignet für | Hauptnachteil |
|---|---|---|---|
| Öffentliches Managed Hosting | Stabiler HTTPS-Endpunkt über Streamable HTTP | Die meisten Anwendungen für Teams und Kunden | Plattformgrenzen und Abhängigkeit vom Anbieter |
| Öffentlicher Self-Managed-Endpunkt | Stabiler HTTPS-Endpunkt auf Container, VM oder Cluster | Bestehende Plattformteams mit Compliance- oder Netzwerkanforderungen | Du verantwortest TLS, Skalierung, Patches, Rollbacks und Monitoring |
| Secure MCP Tunnel | Ein von OpenAI gehosteter Endpunkt leitet an einen privaten stdio- oder HTTP-Server weiter | On-Premises-Systeme, private Netzwerke und Entwicklung | Ein gesunder tunnel-client wird Teil der Verfügbarkeit |
Nutze standardmäßig Managed Hosting, wenn der MCP-Server zustandslos ist, der Datenverkehr sporadisch anfällt und das Team nicht bereits eine zuverlässige Plattform für öffentliche Anwendungen betreibt. Das Route-Handler-Muster von Vercel und das zustandslose Worker-Muster von Cloudflare liefern beide den stabilen HTTPS-Endpunkt, den ChatGPT erwartet. Prüfe vor der Entscheidung aber die jeweiligen Grenzen für Laufzeit, Streaming und Zustand (Vercel, Cloudflare).
Betreibe den öffentlichen Endpunkt selbst, wenn der Server neben bestehenden Datenbanken laufen, eine etablierte Identitätsinfrastruktur nutzen, Anforderungen an den Datenstandort erfüllen oder Aufgaben ausführen muss, die nicht in ein Serverless-Laufzeitmodell passen. Diese Entscheidung ist nur dann sinnvoll, wenn Secret-Management, Deployment-Rollbacks, Alarmierung und eine zuständige Bereitschaft bereits vorhanden sind.
Setze auf Secure MCP Tunnel, wenn ein öffentlicher Eingang der falsche Sicherheitsgrenzpunkt wäre. Der Tunnel-Client von OpenAI baut ausgehende HTTPS-Verbindungen zu api.openai.com:443 auf und leitet Anfragen an einen privaten HTTP- oder stdio-Server weiter. Ein eingehender Internet-Listener ist nicht erforderlich. In der Deployment-Dokumentation weist OpenAI außerdem darauf hin, dass Secure MCP Tunnel die Anforderungen für eine öffentliche Einreichung mit einem stabilen, öffentlich erreichbaren HTTPS-Endpunkt nicht erfüllt (OpenAI-Tunnel-Dokumentation, OpenAI-Anleitung zum Erstellen).
Von lokalen Tools zum produktiven ChatGPT-MCP-Server
Ein zuverlässiges Deployment für ChatGPT-MCP-Server trennt die Prüfungen für Tool-Verhalten, Protokollverhalten, Erreichbarkeit in Produktion und Modell-Routing. Dass eine Prüfung bestanden ist, sagt noch nichts über die nächste aus.
1. Fokussierte Tools mit stabilen Verträgen definieren
Starte mit genau einem Tool pro klar erkennbarem Nutzerwunsch. In der Build-Anleitung von OpenAI werden beispielsweise separate Tools wie list_projects, get_project und update_project verwendet – statt eines einzelnen Tools mit fachfremden Modi (OpenAI-Entwicklerdokumentation). Jedes Tool braucht einen aktionsorientierten Namen, eine präzise Beschreibung, ein explizites Eingabeschema, eine brauchbare Ausgabe und korrekte Sicherheitsannotationen.
Setze readOnlyHint: true nur dann, wenn ein Tool den Zustand nicht verändern kann. Verwende destructiveHint: true für Auswirkungen, die irreversibel oder nur schwer rückgängig zu machen sind, und openWorldHint: true, wenn ein Tool auf offene externe Entitäten zugreift. OpenAI beschreibt diese Annotationen als Metadaten für das Modell, die Tool-Verhalten und Sicherheitsbehandlung beeinflussen. Die Autorisierung muss trotzdem bei jeder geschützten Anfrage auf dem Server durchgesetzt werden (OpenAI-Entwicklerdokumentation).
Gib stabile Datensatz-IDs in structuredContent zurück, wenn ein späterer Aufruf denselben Datensatz aktualisieren können soll. Halte Tokens, Secrets und unnötige personenbezogene Daten aus content, structuredContent und _meta heraus. OpenAI weist ausdrücklich darauf hin, dass _meta zwar vor dem Modell verborgen, aber kein sicherer Speicher ist.
2. Streamable HTTP lokal bereitstellen
Die normale entfernte Verbindung von ChatGPT verwendet Streamable HTTP, üblicherweise unter /mcp. Der Pfad ist Konvention, aber keine Pflicht. Die vollständige bereitgestellte URL muss in ChatGPT eingetragen werden (OpenAI-Verbindungsanleitung).
Starte den Server lokal und öffne den MCP Inspector:
npx @modelcontextprotocol/inspector@latest
Verbinde den Inspector mit einer URL wie http://localhost:3000/mcp. Prüfe die Initialisierung und liste die Tools auf. Rufe anschließend jedes Tool mit einer gültigen Anfrage, einem ungültigen Schema, einer fehlenden ID und einem Fall ohne Ergebnisse auf. Bei geschützten Tools muss außerdem sichergestellt sein, dass fehlende oder unzureichende Zugangsdaten strikt abgewiesen werden.
3. Zugriffskontrolle vor dem öffentlichen Bereitstellen einbauen
Ein öffentlich erreichbarer Health Check rechtfertigt keine öffentlich zugängliche Tool-Oberfläche. Wenn die Tools ausschließlich bewusst öffentliche, schreibgeschützte Daten liefern, kann ein unauthentifizierter Endpunkt vertretbar sein. Private, nutzerbezogene Daten und Aktionen erfordern dagegen bei jeder Anfrage Authentifizierung und Autorisierung (OpenAI-Anleitung zum Erstellen).
Bei OAuth-geschütztem MCP fungiert der Server als Resource Server. Eine unauthentifizierte Anfrage liefert 401 und verweist den Client auf die Metadaten der geschützten Ressource, normalerweise unter /.well-known/oauth-protected-resource. Der Autorisierungsablauf sollte PKCE, eng begrenzte Scopes, eine strikte Prüfung von Aussteller und Audience sowie Unterstützung für Refresh Tokens verwenden, wenn dauerhafte Verbindungen das erfordern (OpenAI Help Center).
Leite das MCP-Access-Token nicht allein deshalb an einen nachgelagerten Dienst weiter, weil beide Services Bearer Tokens akzeptieren. Das Token muss für die empfangende Ressource bestimmt sein. Für nachgelagerte Aufrufe brauchst du Service-Credentials oder ein geeignetes Token-Exchange-Verfahren (Leitfaden zur MCP-Deployment-Sicherheit).
4. Einen unveränderlichen Kandidaten deployen
Deploye denselben Build, der den Inspector bestanden hat, zunächst auf eine Preview- oder Staging-Umgebung und befördere genau dieses Artefakt anschließend in die Produktion. Der Produktionsendpunkt muss HTTPS verwenden, den vollständigen MCP-Pfad beibehalten, seine Abhängigkeiten erreichen können und Secrets im Secret Store der Hosting-Plattform ablegen.
Für einen kompakten Referenzpfad mit Vercel installierst du mcp-handler, @modelcontextprotocol/server und zod. Hänge den zurückgegebenen Web-Handler unter app/api/mcp/route.ts ein, exportiere ihn für GET und POST und deploye mit:
npx vercel deploy --prod
Die ChatGPT-Verbindungs-URL hat dann die Form https://your-project.vercel.app/api/mcp. Vercel dokumentiert mit Fluid Compute eine standardmäßige Funktionsdauer von 300 Sekunden sowie höhere Grenzwerte in geeigneten kostenpflichtigen Konfigurationen. Verschiebe Aufgaben, die länger als eine Anfrage dauern, deshalb in einen fortsetzbaren Job, statt einen inaktiven Stream offen zu halten (Vercel-Deployment-Anleitung). Halte die Route zustandslos, sofern die gewählte Laufzeit kein bewusst konzipiertes Verfahren für gemeinsam genutzten Zustand bereitstellt.
Baue vor der Verbindung mit ChatGPT vier operative Kontrollen ein:
- Lege für teure Tools Anfrage-Timeouts und Rate Limits fest.
- Protokolliere Initialisierungs- und Tool-Fehler, aber niemals Tokens oder sensible Ergebnisse.
- Erfasse bei jedem Aufruf eine Release-ID, damit sich ein Vorfall dem deployten Code zuordnen lässt.
- Halte einen getesteten Rollback-Weg für Regressionen bei Tool-Schema oder Autorisierung bereit.
Führe den MCP Inspector gegen die Produktions-URL aus, nicht nur gegen localhost. Prüfe Erkennung, Schemas, Annotationen, Authentifizierung, gültige Aufrufe und Fehler erneut. Ein Load Balancer, Proxy, eine CORS-Regel oder eine Weiterleitung des Identitätsanbieters kann scheitern, obwohl die Anwendung lokal funktioniert hat.
Zugriffskontrolle in drei Ebenen planen
Der MCP-Zugriff von ChatGPT wird in drei unabhängigen Ebenen durchgesetzt. OAuth aktiviert lediglich die Identitätsebene.
| Ebene | Durchsetzungsort | Erforderliche Entscheidung |
|---|---|---|
| Workspace-Zugriff | ChatGPT-Administrationskontrollen | Wer darf die App erstellen, veröffentlichen, aktivieren oder verwenden? |
| Nutzeridentität | OAuth-Autorisierungsserver und MCP-Resource-Server | Welches Konto ruft auf, und ist das Token für diesen Server gültig? |
| Autorisierung von Ressource und Aktion | MCP-Tool-Handler und Backend | Darf dieser Nutzer diese Aktion für diesen Mandanten, Datensatz oder diese Umgebung ausführen? |
In ChatGPT Business steuern Admins oder Eigentümer den Entwicklermodus und die Veröffentlichung. Enterprise- und Edu-Workspaces ergänzen RBAC für Entwicklerzugriff, App-Zugriff und Aktionen (OpenAI Help Center). Diese Kontrollen regeln die Nutzung der App in ChatGPT. Sie beweisen jedoch nicht, dass ein Aufrufer den Datensatz A eines Kunden im Backend bearbeiten darf.
Der MCP-Handler muss die Identität aus validierten Zugangsdaten ableiten und bei jedem Aufruf die Berechtigungen für Mandant und Objekt prüfen. Akzeptiere niemals eine vom Modell erzeugte Nutzer-ID, Organisations-ID oder Rolle als Identitätsnachweis. Behandle sämtliche Tool-Argumente als nicht vertrauenswürdige Eingaben.
Trenne Leseberechtigungen von Schreibberechtigungen. Eine praktikable Richtlinie könnte projects:read großzügig erlauben, projects:write auf Bearbeiter beschränken und vor destruktiven Vorgängen eine frische serverseitige Prüfung verlangen. ChatGPT kann bei folgenreichen Aktionen eine Bestätigung anfordern. Diese Bestätigung ist jedoch eine UX-Sicherheitsmaßnahme und keine Autorisierungskontrolle.
Auch Prompt Injection ist ein Thema der Zugriffskontrolle. Tool-Ausgaben und abgerufene Dokumente können schädliche Anweisungen enthalten. Schreib-Tools sollten deshalb nur die kleinstmögliche Aktion anbieten und erlaubte Felder serverseitig validieren. Ein universelles Tool wie execute_action vergrößert sowohl die Unsicherheit beim Routing als auch den möglichen Schadensradius.
Die App in ChatGPT verbinden, testen und veröffentlichen
Beim Verbinden des Endpunkts wird eine Entwurfs-App mit einem Metadaten-Snapshot angelegt. Die Veröffentlichung macht eine geprüfte Konfiguration im Workspace verfügbar. Sie ist nicht dasselbe wie ein Deployment des Server-Codes.
- Aktiviere den Entwicklermodus gemäß der geltenden Workspace-Richtlinie von ChatGPT.
- Öffne den Erstellungsprozess für Apps und gib die vollständige HTTPS-MCP-URL ein, einschließlich
/mcp, wenn dies der eingebundene Pfad ist. - Wähle den Authentifizierungsmechanismus und schließe den OAuth-Ablauf ab, falls erforderlich.
- Führe Scan Tools aus. Prüfe jeden erkannten Namen, jedes Schema, jede Annotation und jede Aktion. Erstelle anschließend den Entwurf.
- Teste den Entwurf in einem neuen Chat, bevor du ihn im Workspace veröffentlichst.
Wähle bei einem privaten Server Tunnel als Verbindung aus und selektiere einen zugehörigen Tunnel oder gib dessen tunnel_id ein. Der Betreiber benötigt in der OpenAI Platform Tunnels Read + Use. Der ChatGPT-Entwicklermodus bleibt davon getrennt und erfordert eine eigene Workspace-Berechtigung (OpenAI-Tunnel-Dokumentation).
Metadatenänderungen brauchen einen expliziten Lebenszyklus. Bei einer Verbindung im Entwicklermodus deployest oder startest du den Server neu, öffnest die Verbindung, wählst Refresh, prüfst die geänderten Metadaten und beginnst eine neue Unterhaltung. Laut der aktuellen Business-Dokumentation von OpenAI müssen veröffentlichte Apps neu erstellt und erneut veröffentlicht werden, wenn sich Tools oder Metadaten ändern. Enterprise-/Edu-Admins können Aktionen aktualisieren, Änderungen prüfen und neue Aktionen aktivieren; standardmäßig sind diese deaktiviert (OpenAI Help Center).
Abwärtskompatible Weiterentwicklung bleibt die sicherste Serverstrategie. Ergänze optionale Felder und neue Tools, statt die Bedeutung bestehender Tools stillschweigend zu ändern. Halte alte Schemas verfügbar, bis alle freigegebenen Snapshots und Clients migriert sind.
Das Verhalten testen, das ChatGPT-Nutzer tatsächlich erleben
Protokolltests zeigen, dass ein Server antworten kann. ChatGPT-Tests zeigen, ob das Modell das gewünschte Tool auswählt, passende Argumente liefert, Grenzen respektiert und das Tool bei irrelevanten Anfragen nicht verwendet.
Der Reddit-Nutzer u/EmailNo8428 beschrieb das Problem mit zwei Ebenen so:
„Eigentlich testest du zwei Dinge gleichzeitig: deine Tool-Logik und die Art, wie ein bestimmter Client das Tool aufruft.“ (r/mcp)
Erstelle einen kleinen, versionierten Testsatz mit diesen Fällen:
| Fall | Erwartetes Ergebnis |
|---|---|
| Direkte Anfrage | Die genannte Fähigkeit wird mit gültigen Argumenten ausgewählt |
| Indirekte Anfrage | Das passende Tool wird aus dem Nutzerziel abgeleitet |
| Rückfrage | Die zuvor zurückgegebene stabile ID wird wiederverwendet |
| Negative Anfrage | Kein MCP-Tool wird aufgerufen |
| Fehlende Berechtigung | Es wird ein verständlicher Autorisierungsfehler ohne Datenleck zurückgegeben |
| Schreibanfrage | Das eng zugeschnittene Schreib-Tool wird ausgewählt und eine erforderliche Bestätigung ausgelöst |
| Mehrdeutige Anfrage | Erforderliche Informationen werden erfragt, statt Argumente zu erfinden |
| Leeres Ergebnis | Ein gültiger leerer Zustand wird zurückgegeben, kein Transport- oder Schemafehler |
Erfasse ausgewähltes Tool, Argumente, zurückgegebenes Ergebnis, Fehler und Bestätigungsverhalten. Wiederhole die betroffenen Fälle immer dann, wenn sich Tool-Name, Beschreibung, Schema, Annotation, Authentifizierungsregel oder Ergebnisstruktur ändert. OpenAI empfiehlt in seiner Verbindungsanleitung denselben Zyklus aus Aktualisieren und erneutem Testen.
Ein Server, der den Inspector besteht, in ChatGPT aber schlecht routet, braucht meist schärfere Tool-Grenzen, Beschreibungen oder Schemas. Routet der Server korrekt, liefert aber 401, läuft in ein Timeout oder verliert Zustand, liegt das Problem in Infrastruktur oder Autorisierung. Diese Diagnosen getrennt zu halten, verkürzt die Fehlerbehebung.
FAQ
Kann ChatGPT direkt eine lokale oder per stdio angebundene MCP-Serverinstanz verbinden?
Nein. ChatGPT verbindet sich normalerweise mit einem entfernten MCP-Endpunkt. Der OpenAI Secure MCP Tunnel kann an einen privaten stdio- oder HTTP-Server weiterleiten, ohne einen öffentlichen Eingang zu benötigen. Für die Entwicklung kann außerdem ein temporärer HTTPS-Tunnel verwendet werden, nicht jedoch für die öffentliche Plugin-Einreichung.
Benötigt ein ChatGPT-MCP-Server einen öffentlichen HTTPS-Endpunkt?
Eine normale entfernte Verbindung und die öffentliche Plugin-Einreichung erfordern stabiles HTTPS. Ein privater Server im Entwicklermodus kann den Secure MCP Tunnel verwenden. Der Server bleibt dabei innerhalb der vom Kunden kontrollierten Umgebung.
Sind search und fetch erforderlich?
Nein. Laut OpenAI müssen verbundene Server diese Tools nicht mehr bereitstellen. Implementiere die standardisierten Verträge für search und fetch, wenn die App an Unternehmenswissen oder Retrieval-Oberflächen für Deep Research teilnehmen soll (OpenAI Help Center).
Warum zeigt ChatGPT nach dem Deployment weiterhin alte Tools an?
ChatGPT speichert erkannte Metadaten und behandelt nicht jedes Code-Deployment automatisch als genehmigte Tool-Änderung. Aktualisiere eine Verbindung im Entwicklermodus und starte eine neue Unterhaltung. Veröffentlichte Workspace-Apps folgen dem jeweils geltenden Prüf- und erneuten Veröffentlichungsprozess.