MCP setup · OpenAI
MCP connectors in ChatGPT Enterprise: what to know before you enable one
ChatGPT is a hosted connector surface — there is no file on a laptop to edit or audit. That shapes the governance story more than any individual setting does, and it is what this page is about. Where we could not verify a current admin click-path from publicly reachable documentation, we say so instead of guessing.
How this surface handles MCP
The structural fact worth building policy on is that ChatGPT connectors are administered rather than configured. Unlike Claude Code, Cursor, Codex or Gemini CLI — where any engineer can add a server to a file in their home directory and nobody else ever sees it — a hosted connector model concentrates the decision in a workspace administration surface. The consequence is that this surface's connector set is, in principle, enumerable by an administrator, which is more than can be said for the file-based ones.
MCP is the mechanism underneath. OpenAI documents MCP as the way custom connectors and tools are built and exposed, both in the API and across ChatGPT surfaces, which means a remote MCP server your team already runs is the same object here as it is elsewhere — a different front door onto identical capability.
That last point is the one most governance documents miss. Because the same server can be reachable from a hosted connector, from a terminal agent's config file, and from an editor's workspace file, reviewing it once per surface produces three reviews of varying quality and no shared record. The server is the unit worth reviewing; the surface is where it shows up.
On the specifics of the current admin interface, we are being deliberately incomplete. OpenAI's help centre is not reachable to automated verification, and publishing a settings path we could not confirm would be worse than publishing nothing — a reader who follows a stale click-path and fails does not come back. Confirm the current workspace controls with OpenAI's own documentation or your account team, and treat the analysis on this page as the part that does not go stale.
Adding a server
- Start from the workspace administration surface
Connectors in ChatGPT are administered at the workspace level rather than declared in a file. Begin with your workspace settings and OpenAI's current documentation for the exact path, which changes more often than the underlying model does.
- Treat the server as the review unit
Whatever the click-path, the object being approved is a remote MCP server with a tool set and a credential. Review it the way you would review it for any other surface, because it is the same server.
- Decide the identity model before enabling
Whether the connector authenticates per user or through a shared credential determines whether source-system permissions still mean anything downstream. This is a policy decision, not a setup step, and it is easier to make before rollout than after.
- Record the approval somewhere outside the vendor console
A connector approved in one vendor's admin page is invisible to every other governance process you run. A single register of approved servers, spanning surfaces, is what turns four consoles into one answer.
Confirming it actually connected
- Confirm with OpenAI's current documentation which controls your plan actually exposes before writing them into a policy document — this layer moves quickly across every vendor.
- Test the connector as an ordinary member rather than as an administrator. Admin-side success is not evidence that a member's authorisation flow works.
- Check whether the same MCP server is already connected to other surfaces in your company. If it is, reconcile the reviews rather than adding a fourth independent one.
Review this before you connect anything
the part the vendor docs will not tell you
A connected MCP server can read what its credential can read and do what its tools can do, and its tool descriptions reach the model as instructions. None of that is visible from a configuration file that parses correctly.
- The same server is probably connected elsewhere
A remote MCP server reachable from ChatGPT is reachable from a terminal agent and an editor too. One review, recorded once, beats three partial ones — and is the only way the answer stays consistent.
- Read the tool descriptions, whatever the surface
Tool descriptions reach the model as instructions on every surface that connects the server. A poisoned description approved at workspace level reaches everyone in the workspace.
- Establish the credential's blast radius
Shared service credentials collapse source-system permissions into one identity. Per-user authorisation preserves them. This decision outlives any particular admin interface.
- Schedule a re-review, because there is nothing to pin
A remote server can change its tools and descriptions with no change to its URL. Hosted connectors have no lockfile, so a recurring review is doing the job a pinned version would do on a file-based surface.
Organisational controls
- Administration is centralised by construction
A hosted connector model means the decision sits with a workspace administrator rather than with each user's local file. That is the structural control, and it holds regardless of how the specific settings screens are laid out this quarter.
- Verify current controls with the vendor
We do not publish a settings click-path or plan-tier matrix for ChatGPT, because OpenAI's help centre is not reachable to automated verification and an unconfirmed path is worse than an absent one. Ask your account team or read OpenAI's own current documentation.
- The register is yours to keep
No vendor console will list the connectors approved in the other three. A cross-surface register of approved servers, with owner, credential scope and review date, is the control you own outright.
What this cannot tell you
The per-machine drift problem is genuinely smaller here — there is no laptop-local file to diverge. What replaces it is silo drift: the connector approved in this console does not appear in Anthropic's, GitHub's or Cursor's, and none of them can tell you that all four are the same server, running the same tools, holding four differently scoped credentials.
Frequently asked
- Does ChatGPT have an MCP config file?
- No. Connectors are administered through the product rather than declared in a file on a machine, which is the opposite model from Claude Code, Cursor, Codex and Gemini CLI. It centralises the decision and removes the per-laptop audit problem for this surface.
- Why does this page not list the exact admin settings path?
- Because we could not verify one from publicly reachable documentation — OpenAI's help centre blocks automated fetches — and publishing an unconfirmed click-path is worse than publishing none. The structural analysis here does not go stale; a settings screenshot would.
- Is MCP how ChatGPT connectors work?
- OpenAI documents MCP as the mechanism for building custom connectors and tools across its surfaces, so a remote MCP server your team runs is the same object here as in any other client. That is exactly why the server, not the surface, is the right unit to review.
- We govern connectors in the ChatGPT admin console. Is that enough?
- For this surface, it is a real control and better than most. It says nothing about the same server connected to Claude Code or Cursor on the same engineers' laptops, at a different scope with a different credential — and that is where the cross-surface gap lives.
Sources
Every path, key, table and flag on this page was read from OpenAI's own documentation on 2026-07-26. Where a control varies by plan or is changing quickly, this page describes the mechanism rather than asserting a current state.