MCP | ChatGPT und Codex erweitern | ChatGPT-Dokumentation

Das Model Context Protocol (MCP) verbindet Modelle mit Tools und Kontext. Verwenden Sie es, um ChatGPT oder Codex Zugriff auf Dokumentation von Drittanbietern zu geben oder die Interaktion mit Entwicklungstools wie Ihrem Browser oder Figma zu ermöglichen.

ChatGPT im Web kann von Plugins bereitgestellte Remote-Tools mit MCP-Unterstützung verwenden. Nachdem ein Plugin installiert wurde, können Chat und Work die darin enthaltenen Connectors und Remote-MCP-Tools verwenden. Öffnen Sie die Registerkarte Plugins, um verfügbare Tools zu durchsuchen und zu verwalten. Lokale Codex- Clients können sich außerdem direkt mit MCP-Servern verbinden und ihre Konfiguration gemeinsam nutzen.

Die ChatGPT-Desktop-App, Codex CLI und die IDE-Erweiterung unterstützen MCP-Server und verwenden für denselben Codex-Host eine gemeinsame MCP-Konfiguration.

Die unten aufgeführten unterstützten Serverfunktionen gelten für MCP-Server, die auf einem Codex- Host konfiguriert sind. Von Plugins bereitgestellte Tools können andere Funktionen besitzen.

Unterstützte MCP-Funktionen

STDIO-Server: Server, die als lokaler Prozess ausgeführt werden (durch einen Befehl gestartet).
- Umgebungsvariablen
Streambare HTTP-Server: Server, auf die Sie über eine Adresse zugreifen.
- Bearer-Token-Authentifizierung
- OAuth-Authentifizierung einschließlich Client ID Metadata Documents (CIMD) und Dynamic Client Registration (DCR)
- ChatGPT-Sitzungsauthentifizierung für vertrauenswürdige Erstanbieter-Server
Serveranweisungen: Codex liest das bei der Initialisierung zurückgegebene MCP-Feld instructions und verwendet es zusammen mit den Tools des Servers als serverweite Anleitung.

Wenn Sie einen MCP-Server für Codex entwickeln oder verwalten, verwenden Sie instructions für serverübergreifende Tool-Workflows, Einschränkungen und Ratenbegrenzungen. Formulieren Sie die ersten 512 Zeichen so, dass sie für sich allein verständlich sind. Dadurch stehen Codex die wichtigsten Hinweise zur Verfügung, wenn es über die Verwendung des Servers entscheidet.

Codex mit einem MCP-Server verbinden

Codex speichert die MCP-Konfiguration zusammen mit anderen Codex-Konfigurationseinstellungen in config.toml. Standardmäßig ist dies ~/.codex/config.toml, Sie können MCP-Server jedoch auch mit .codex/config.toml auf ein Projekt beschränken (nur bei vertrauenswürdigen Projekten).

Die ChatGPT-Desktop-App, Codex CLI und die IDE-Erweiterung verwenden diese Konfiguration gemeinsam. Nachdem Sie Ihre MCP-Server konfiguriert haben, können Sie zwischen diesen Clients wechseln, ohne die Einrichtung erneut durchzuführen.

In der ChatGPT-Desktop-App konfigurieren

Öffnen Sie Settings und wählen Sie anschließend MCP servers aus.
Wählen Sie Add server aus.
Geben Sie einen Namen ein, wählen Sie STDIO oder Streamable HTTP aus und geben Sie den Befehl oder die URL des Servers an.
Speichern Sie den Server und wählen Sie anschließend Restart aus.

Die Serverliste zeigt, welche Server aktiviert sind und für welche OAuth erforderlich ist. Wählen Sie Authenticate aus, wenn für einen OAuth-Server eine Anmeldung erforderlich ist. Geben Sie im Eingabefeld /mcp ein, um die verbundenen Server anzuzeigen.

Mit der CLI konfigurieren

Einen MCP-Server hinzufügen

codex mcp add <server-name> --env VAR1=VALUE1 --env VAR2=VALUE2 -- <stdio server-command>

Um beispielsweise Context7 (einen kostenlosen MCP-Server für Entwicklerdokumentation) hinzuzufügen, können Sie den folgenden Befehl ausführen:

codex mcp add context7 -- npx -y @upstash/context7-mcp

Weitere CLI-Befehle

Führen Sie codex mcp list aus, um die konfigurierten Server anzuzeigen. Um alle verfügbaren MCP- Befehle anzuzeigen, führen Sie codex mcp --help aus. Führen Sie für einen Server, der OAuth unterstützt, codex mcp login <server-name> aus.

Terminal-Benutzeroberfläche (TUI)

Verwenden Sie in der codex TUI den Befehl /mcp, um Ihre aktiven MCP-Server anzuzeigen.

Mit config.toml konfigurieren

Für eine detailliertere Steuerung bearbeiten Sie ~/.codex/config.toml oder eine projektbezogene .codex/config.toml. In der Konfigurationsreferenz finden Sie eine durchsuchbare Liste aller unterstützten MCP-Optionen.

Konfigurieren Sie jeden MCP-Server mit einer [mcp_servers.<server-name>]-Tabelle in der Konfigurationsdatei.

STDIO-Server

command (erforderlich): Der Befehl, der den Server startet.
args (optional): Argumente, die an den Server übergeben werden.
env (optional): Umgebungsvariablen, die für den Server festgelegt werden.
env_vars (optional): Umgebungsvariablen, die zugelassen und weitergeleitet werden.
cwd (optional): Arbeitsverzeichnis, aus dem der Server gestartet wird.
experimental_environment (optional): Legen Sie remote fest, um den STDIO- Server über eine Remote-Ausführungsumgebung zu starten, sofern eine verfügbar ist.

env_vars kann einfache Variablennamen oder Objekte mit einer Quelle enthalten:

env_vars = ["LOCAL_TOKEN", { name = "REMOTE_TOKEN", source = "remote" }]

Zeichenfolgeneinträge und source = "local" werden aus der lokalen Umgebung von Codex gelesen. source = "remote" wird aus der Remote-Ausführungsumgebung gelesen und erfordert Remote-MCP-STDIO.

Streamable-HTTP-Server

url (erforderlich): Die Serveradresse.
auth (optional): Authentifizierung, die nach konfigurierten Bearer-Tokens und Autorisierungs-Headern versucht werden soll. Verwenden Sie oauth (die Standardeinstellung) für gespeicherte MCP-OAuth- Anmeldedaten. Verwenden Sie chatgpt, um die aktuelle ChatGPT-Sitzung für den vertrauenswürdigen Erstanbieter-Ursprung von ChatGPT zu verwenden, wobei gespeichertes OAuth als Fallback dient.
bearer_token_env_var (optional): Name der Umgebungsvariable für ein Bearer-Token, das in Authorization gesendet werden soll.
http_headers (optional): Zuordnung von Header-Namen zu statischen Werten.
env_http_headers (optional): Zuordnung von Header-Namen zu Namen von Umgebungsvariablen (Werte werden aus der Umgebung abgerufen).
http_headers_helper (optional): Lokaler Befehl, der ein JSON-Objekt mit Header-Namen und Zeichenfolgenwerten ausgibt, beispielsweise {"X-Auth": "temporary-token"}. Wird für HTTP-MCP-Verbindungen unterstützt, die aus der lokalen Umgebung hergestellt werden; nicht für STDIO-Server oder Verbindungen, die über eine Remote-Ausführungsumgebung hergestellt werden.

Codex speichert Hilfs-Header für die Verbindung im Cache. Nachdem ein POST mit demselben Ursprung 401 oder 403 zurückgibt, aktualisiert Codex die Header einmal und versucht es nur dann erneut, wenn die Hilfsfunktion geänderte Werte zurückgibt. Explizite Bearer-Tokens und OAuth-Anmeldedaten haben Vorrang vor einem von der Hilfsfunktion bereitgestellten Authorization-Header. Eine OAuth-Antwort mit 403, die einen unzureichenden Berechtigungsumfang meldet, löst keine Aktualisierung durch die Hilfsfunktion aus.

Wenn keine Anmeldedatenquelle aufgelöst werden kann, kann Codex ohne Authentifizierung eine Verbindung zum Server herstellen. Führen Sie codex mcp login <server-name> separat aus, um eine MCP- OAuth-Anmeldung zu starten.

Weitere Konfigurationsoptionen

startup_timeout_sec (optional): Zeitlimit (Sekunden) für den Start des Servers. Standard: 10.
tool_timeout_sec (optional): Zeitlimit (Sekunden) für die Ausführung eines Tools durch den Server. Standard: 60.
enabled (optional): Legen Sie false fest, um einen Server zu deaktivieren, ohne ihn zu löschen.
required (optional): Legen Sie true fest, damit der Start fehlschlägt, wenn dieser aktivierte Server nicht initialisiert werden kann.
enabled_tools (optional): Positivliste für Tools.
disabled_tools (optional): Sperrliste für Tools (wird nach enabled_tools angewendet).
default_tools_approval_mode (optional): Standardmäßiges Genehmigungsverhalten für Tools von diesem Server. Unterstützte Werte sind auto, prompt, writes und approve. Im Modus writes wird bei Tools nachgefragt, die nicht als schreibgeschützt gekennzeichnet sind.
tools.<tool>.approval_mode (optional): Überschreibung des Genehmigungsverhaltens für einzelne Tools.
tools.<tool>.output_token_limit (optional): Positives Token-Budget für die Ausgabe eines Tools vor dem standardmäßigen Serialisierungsaufschlag von 20 %. Überschreibt das standardmäßige Budget des Modells für die Kürzung der Ausgabe dieses Tools.

Die Einstellung mcp_optional_startup_grace_ms auf oberster Ebene steuert, wie lange Codex beim Erstellen des anfänglichen Toolkatalogs auf optionale MCP-Server wartet. Der Standardwert beträgt 1000 Millisekunden. Legen Sie den Wert auf 0 fest, um stattdessen für jeden Server dessen startup_timeout_sec abzuwarten. Erforderliche Server verwenden weiterhin ihre Start- zeitlimits.

OAuth-Clientregistrierung und Callbacks

Wenn Ihr Autorisierungsserver einen vorab registrierten OAuth-Client erfordert, geben Sie beim Hinzufügen des MCP-Servers dessen Client-ID an:

codex mcp add example --url https://mcp.example.com --oauth-client-id my-client

Codex zeigt die vollständige Callback-URL an, die Sie bei Ihrem Anbieter registrieren müssen:

OAuth callback URL: http://127.0.0.1/callback

Codex speichert den Callback zusammen mit der Client-ID in config.toml für spätere Anmeldungen:

[mcp_servers.example]
url = "https://mcp.example.com"

[mcp_servers.example.oauth]
client_id = "my-client"
callback_url = "http://127.0.0.1/callback"

Neu hinzugefügte, vorab registrierte Clients verwenden nur dann einen stabilen Callback, wenn der Autorisierungsserver authorization_response_iss_parameter_supported: true angibt und einen Metadatenwert für issuer bereitstellt. Wenn die Unterstützung für den Aussteller nicht angegeben wird, hängt Codex eine serverspezifische Callback-ID an, beispielsweise http://127.0.0.1/callback/XuuuHAzzHOni. Vorhandene Clients ohne gespeicherten Callback verwenden weiterhin ihre Callback-ID-spezifische Weiterleitung.

Bei der Anmeldung hängt die Auswahl des Callbacks von der OAuth-Konfiguration und den Metadaten des Autorisierungsservers ab:

OAuth-Konfiguration	Ausstellerunterstützung	Verwendeter Callback
`callback_url` ohne `client_id`	Unterstützt	Der konfigurierte Callback wird für die Clientregistrierung verwendet.
`callback_url` ohne `client_id`	Nicht unterstützt	Der konfigurierte Callback wird für die Clientregistrierung verwendet, wobei die serverspezifische Callback-ID angehängt wird.
`client_id` und `callback_url`	Unterstützt	Der konfigurierte Callback wird erneut verwendet; die Autorisierungsantwort muss den passenden Wert für `iss` enthalten.
`client_id` und eine `callback_url`, die mit der richtigen Callback-ID endet	Nicht unterstützt	Der konfigurierte Callback wird unverändert erneut verwendet.
`client_id` und eine `callback_url`, der die richtige Callback-ID fehlt	Nicht unterstützt	Der konfigurierte Callback wird ignoriert. Codex verwendet `mcp_oauth_callback_url` oder, falls nicht festgelegt, `http://127.0.0.1/callback` und hängt die Callback-ID an.
`client_id` ohne konfigurierte `callback_url`	Unterstützt oder nicht unterstützt	Codex verwendet den globalen oder standardmäßigen Callback und hängt die serverspezifische Callback-ID an.

Der Fallback ändert die gespeicherte Callback-URL nicht. Codex leitet die Callback-ID aus der URL des MCP-Servers einschließlich ihres Pfads und ihrer Abfragezeichenfolge ab. Dieselben Auswahlregeln gelten für die automatische und die explizite Anmeldung.

Legen Sie mcp_oauth_callback_url fest, wenn Sie einen benutzerdefinierten Callback-Pfad oder eine Remote-Ingress-URL für eine Devbox benötigen. Neu hinzugefügte, vorab registrierte Clients verwenden diese URL unverändert, wenn ihr Anbieter die Identifizierung des Ausstellers unterstützt. Andernfalls verwenden sie die konfigurierte URL mit angehängter serverspezifischer Callback-ID. Registrieren Sie immer den exakten Callback, den codex mcp add anzeigt.

Bei Callbacks vom Typ http://127.0.0.1 ohne Port lässt Codex den Listener-Port in der angezeigten und gespeicherten URL weg und fügt dann während der Autorisierung den aktiven Listener-Port ein. Diese Ersetzung gilt nicht für localhost, IPv6-Hosts, HTTPS-URLs oder Callbacks, die bereits einen Port enthalten. Autorisierungsserver müssen variable Loopback-Ports gemäß RFC 8252, Abschnitt 7.3 akzeptieren.

Legen Sie mcp_oauth_callback_port fest, um einen festen globalen Listener-Port auszuwählen, oder legen Sie mcp_servers.<server-name>.oauth.callback_port fest, um ihn für einen einzelnen Server zu überschreiben. Ein expliziter Port in der Callback-URL konfiguriert den Listener nicht. Verwenden Sie für einen direkten Loopback-Callback http://127.0.0.1 ohne Port oder konfigurieren Sie denselben expliziten Port sowohl für die Callback-URL als auch für den Listener. Ein über einen Proxy geleiteter Callback kann bewusst einen externen URL-Port verwenden, der sich vom lokalen Listener-Port unterscheidet. Lokale Callback-URLs werden an die lokale Schnittstelle gebunden; nicht lokale Callback-URLs werden an 0.0.0.0 gebunden.

Codex validiert jeden zurückgegebenen Wert für iss, bevor der Autorisierungscode ausgetauscht wird. Ein nicht übereinstimmender Wert für iss führt immer zur Ablehnung der Antwort. Wenn die Unterstützung für den Aussteller angegeben wird, führt auch ein fehlender Wert für iss zur Ablehnung. Bei keinem der beiden Fehler wird der Code ausgetauscht oder auf einen anderen Callback zurückgegriffen. Eine fehlerhafte Callback-URL oder eine angegebene Ausstellerunterstützung ohne Aussteller in den Metadaten bleibt ebenfalls ein nicht behebbarer Fehler. Siehe Benutzer authentifizieren.

Wenn der MCP-Server scopes_supported bekannt gibt, bevorzugt Codex bei der OAuth-Anmeldung diese vom Server bekannt gegebenen Bereiche. Andernfalls greift Codex auf die in config.toml konfigurierten Bereiche zurück.

OAuth-Clientregistrierung

Codex unterstützt OAuth Client ID Metadata Documents (CIMD) und Dynamic Client Registration (DCR). Standardmäßig wählt Codex automatisch CIMD aus, wenn der Autorisierungsserver client_id_metadata_document_supported: true bekannt gibt, none in token_endpoint_auth_methods_supported enthält und der Callback eine unterstützte Loopback-URL verwendet. Andernfalls verwendet Codex DCR, sofern verfügbar. Eine konfigurierte OAuth-Client- ID hat immer Vorrang und überspringt die Clientregistrierung.

Für CIMD verwendet Codex ein von ChatGPT gehostetes Metadatendokument speziell für den MCP- Server:

https://chatgpt.com/oauth/codex/<callback_id>/client.json

Codex leitet <callback_id> aus der URL des MCP-Servers ab und fügt die ID in den Loopback-Weiterleitungs-URI ein, zum Beispiel http://127.0.0.1:<port>/callback/<callback_id>. Das Metadatendokument registriert den entsprechenden Loopback-URI ohne Port. Autorisierungsserver müssen den bei der Anmeldung ausgewählten Port akzeptieren und dabei Host und Pfad genau abgleichen, wie von RFC 8252 vorgeschrieben. Benutzerdefinierte Callback-Hosts, -Pfade oder -Abfrageparameter erfordern DCR oder eine konfigurierte OAuth- Client-ID.

Die Unterstützung für ein stabiles, gemeinsam genutztes CIMD-Dokument befindet sich in Entwicklung und ist bald verfügbar:

https://chatgpt.com/oauth/codex/client.json

Codex verwendet das stabile Dokument mit dem gemeinsamen Pfad /callback, wenn der Autorisierungsserver authorization_response_iss_parameter_supported: true angibt, einen gültigen issuer in seinen Metadaten bereitstellt und ein übereinstimmendes iss in Autorisierungsantworten enthält. Server ohne an den Aussteller gebundene Antworten verwenden weiterhin das Callback-spezifische Dokument.

Um eine Registrierungsmethode für eine einzelne CLI-Anmeldung auszuwählen, verwenden Sie --oauth-client-registration:

codex mcp login <server-name> --oauth-client-registration cimd
codex mcp login <server-name> --oauth-client-registration dcr

Der Standardwert ist auto. Die gewählte Registrierung gilt nur für die aktuelle Anmeldung und wird nicht in config.toml gespeichert.

config.toml-Beispiele

[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
env_vars = ["LOCAL_TOKEN"]

[mcp_servers.context7.env]
MY_ENV_VAR = "MY_ENV_VALUE"

# Optional MCP OAuth callback overrides (used by `codex mcp login`)
mcp_oauth_callback_port = 5555
mcp_oauth_callback_url = "https://devbox.example.internal/callback"

[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"
http_headers = { "X-Figma-Region" = "us-east-1" }

[mcp_servers.chrome_devtools]
url = "http://localhost:3000/mcp"
enabled_tools = ["open", "screenshot"]
disabled_tools = ["screenshot"] # applied after enabled_tools
default_tools_approval_mode = "prompt"
startup_timeout_sec = 20
tool_timeout_sec = 45
enabled = true

[mcp_servers.chrome_devtools.tools.open]
approval_mode = "approve"
output_token_limit = 30000

Von Plugins bereitgestellte MCP-Server

Installierte Plugins können MCP-Server in ihrem Plugin-Manifest bündeln. Diese Server werden vom Plugin aus gestartet, sodass die Benutzerkonfiguration ihren Transportbefehl nicht festlegt. In der Benutzerkonfiguration lassen sich der Aktivierungsstatus und die Tool-Richtlinie unter plugins.<plugin>.mcp_servers.<server> weiterhin steuern.

[plugins."sample@test".mcp_servers.sample]
enabled = true
default_tools_approval_mode = "prompt"
enabled_tools = ["read", "search"]

[plugins."sample@test".mcp_servers.sample.tools.search]
approval_mode = "approve"

Von Plugins bereitgestellte HTTP-MCP-Server können OAuth-Einstellungen auch in .mcp.json deklarieren. Plugin-Manifeste verwenden die camelCase-Feldnamen clientId, callbackUrl und callbackPort:

{
  "mcpServers": {
    "sample": {
      "type": "http",
      "url": "https://mcp.example.com/mcp",
      "oauth": {
        "clientId": "my-pre-registered-client",
        "callbackUrl": "http://127.0.0.1/callback/registered"
      }
    }
  }
}

Von Plugins bereitgestellte MCP-Server folgen denselben Regeln zur Callback-Auswahl wie andere MCP-Server. Wenn ein Plugin eine clientId bereitstellt, sein Anbieter keine an den Aussteller gebundenen Callbacks unterstützt und der callbackUrl die serverspezifische Callback-ID fehlt, ignoriert Codex diese URL für die Anmeldung und verwendet mcp_oauth_callback_url oder, falls nicht festgelegt, http://127.0.0.1/callback und hängt die Callback-ID an. Die konfigurierte callbackUrl bleibt unverändert.

Die Einstellung oauth.callbackPort eines Plugins überschreibt die globale Einstellung mcp_oauth_callback_port; wenn keine von beiden festgelegt ist, wählt Codex einen ephemeren Port. Der in callbackUrl eingebettete Port wählt nicht den Listener-Port aus. Konfigurieren Sie für einen direkten Loopback-Callback mit festem Port beide Werte identisch:

{
  "callbackUrl": "http://127.0.0.1:4321/callback/registered",
  "callbackPort": 4321
}

Bei Remote-Ingress oder einem anderen Proxy können sich der Port der Callback-URL und der lokale Listener-Port bewusst unterscheiden, wenn der Proxy an den konfigurierten Listener weiterleitet.

Beispiele für nützliche MCP-Server

Die Liste der MCP-Server wächst kontinuierlich. Hier sind einige häufig verwendete Server:

OpenAI Docs MCP: OpenAI-Entwicklerdokumentation durchsuchen und lesen.
Context7: Eine Verbindung zu aktueller Entwicklerdokumentation herstellen.
Figma Local und Remote: Auf Ihre Figma-Designs zugreifen.
Playwright: Einen Browser mit Playwright steuern und untersuchen.
Chrome Developer Tools: Chrome steuern und untersuchen.
Sentry: Auf Sentry-Protokolle zugreifen.
GitHub: GitHub über die von git unterstützten Funktionen hinaus verwalten (beispielsweise Pull Requests und Issues).

Letzte Suchanfragen

Suchvorschläge

Dokumentationsnavigation

Model Context Protocol