Quick answer: ChatGPT supports remote MCP servers through custom connectors. Turn on developer mode under Settings, then Connectors, then Advanced, add your server URL, and ChatGPT can call its tools in a normal conversation. If you are building on the API instead, pass the server to the Responses API as a tool of type mcp. Local stdio servers, the kind Claude Desktop launches as a subprocess, do not work in ChatGPT at all.
MCP started as an Anthropic protocol, and for a while the ecosystem guides only covered Claude and Cursor. That changed when OpenAI adopted MCP across the Agents SDK, the Responses API, and ChatGPT itself. The support is real, but it comes with sharp edges that the announcement posts glossed over. Here is how each path works and where each one bites.
The three ways into the OpenAI ecosystem
There are three separate doors, and they behave differently:
| Path | Where it runs | Server type | Best for |
|---|---|---|---|
| ChatGPT connectors + developer mode | chatgpt.com | Remote only (Streamable HTTP or SSE) | Chatting with tools yourself |
Responses API mcp tool |
Your code, OpenAI-hosted execution | Remote only | Production apps and backends |
| Agents SDK | Your code, your machine | Remote or local stdio | Custom agents you fully control |
If you remember one thing, make it this: ChatGPT the product only speaks to remote servers over HTTP. The huge pile of local MCP servers on npm that run via npx will not plug into ChatGPT directly. Someone has to host them, or you use the Agents SDK, which can spawn local processes because it runs on your machine.
Connecting a server to ChatGPT with developer mode
Developer mode is the switch that lets ChatGPT use arbitrary MCP tools in regular chats, including write actions, instead of limiting connectors to search-style retrieval.
- Open ChatGPT Settings, then Connectors, then Advanced, and toggle Developer mode. You need a paid plan; on Business and Enterprise workspaces an admin has to allow custom connectors first.
- Back on the Connectors screen, click Create and fill in a name and the server URL, something like
https://your-server.example.com/mcp. - Pick authentication: OAuth or No authentication. This is the first sharp edge, and we will come back to it.
- Start a new chat, open the plus menu, enable your connector under developer mode, and ask a question that needs it.
ChatGPT lists the server's tools, decides when to call them, and asks for confirmation before anything that writes. The confirmation prompts are mildly annoying and entirely correct: a remote tool with write access is a real security surface, and prompt injection through fetched web content is not a hypothetical.
The sharp edges nobody mentions
No API key header field. The connector UI supports OAuth or nothing. There is no box for an x-api-key header, so a server that authenticates with a static key in a header cannot be added through the ChatGPT UI with your key attached. Your options are a server that implements OAuth, a server that is open, or the Responses API, which does accept custom headers. Claude Desktop and Claude Code take header auth in their config, which is why the same server can be a one-liner there and a dead end in the ChatGPT settings screen.
Deep research wants two specific tools. If you want a connector to work as a deep research source, the server must expose tools named search and fetch with the shapes OpenAI documents: search returns a list of result IDs, fetch takes an ID and returns the document. A server with differently named tools will connect fine in developer mode but will not show up as a research source.
Remote means publicly reachable. While developing, you cannot point ChatGPT at localhost. Tunnel it with something like ngrok or deploy to a real host first.
If you are new to the protocol itself, the primer in What Is the Model Context Protocol and Why It Matters covers the client and server model in more depth.
Using MCP servers through the Responses API
For anything you are building rather than chatting with, skip the connector UI entirely. The Responses API takes an MCP server as a tool definition, and OpenAI's infrastructure calls it during the model run:
from openai import OpenAI
client = OpenAI()
resp = client.responses.create(
model="gpt-5",
tools=[{
"type": "mcp",
"server_label": "linksc",
"server_url": "https://mcp.link.sc/",
"headers": {"x-api-key": "lsc_your_api_key"},
"require_approval": "never",
}],
input="Search for the latest PostgreSQL release and summarize what changed.",
)
print(resp.output_text)
Note the headers field. This is where key-based auth works in the OpenAI ecosystem. The example points at the hosted link.sc MCP server, which exposes search (Google results as markdown) and fetch (any URL as clean markdown) behind one key, the same tools I walked through for Claude in Connect Claude to the Web with the link.sc MCP Server.
require_approval: "never" trades safety for speed. Leave approvals on until you trust the server, because every tool result flows straight into the model's context.
The Agents SDK is the third door. HostedMCPTool wraps the same Responses API mechanism, and MCPServerStdio lets an agent launch local servers as subprocesses, which is the only OpenAI path that runs the npm-style local servers unchanged.
ChatGPT versus Claude for MCP, honestly
I use both, and the difference is philosophy. Claude treats MCP as a first-class citizen: local stdio servers, remote servers, header auth in config files. ChatGPT treats MCP as a connector format for remote services, with the flexible parts pushed to the API.
| ChatGPT | Claude Desktop / Code | |
|---|---|---|
| Local stdio servers | No | Yes |
| Remote HTTP servers | Yes | Yes |
| API key header auth in the app | No, OAuth or open only | Yes, via config |
| Write tools in chat | Developer mode only | Yes, with permission prompts |
Neither approach is wrong. ChatGPT's constraint pushes the ecosystem toward hosted servers, which is where it was heading anyway; nobody wants to babysit twelve local processes. But today it means the smoothest ChatGPT experience comes from servers that either implement OAuth or ride along in your own code through the API.
What I would actually do
To experiment in chat, enable developer mode and connect an open or OAuth server. To give an OpenAI-powered app live web access, use the Responses API with an MCP server and headers, or call a fetch and search API directly over HTTP and keep full control of retries and caching. The link.sc docs cover both shapes with the same key, so switching between them is a config change, not a migration.
The protocol finally spans both major ecosystems. The clients just disagree about where your credentials go.
Give ChatGPT and your OpenAI agents live web search and fetch through one MCP server. Get a key at link.sc/register, 500 free credits a month.