How Does ChatGPT Use MCP?
You connected an MCP server to Claude Desktop, it worked, and you assumed ChatGPT would be the same. Then you tried...
You connected an MCP server to Claude Desktop, it worked, and you assumed ChatGPT would be the same. Then you tried it and hit a wall — the local server Claude ran fine wasn't reachable, or ChatGPT threw an error your other tools never did. Same protocol, different behavior.
The confusion is fair. "ChatGPT supports MCP" is true, but it hides the part that actually matters: how it supports it differs from every desktop AI client you've used, and that difference is architectural, not cosmetic.
What is MCP, and how does ChatGPT use it?
MCP — the Model Context Protocol — is an open standard that lets AI tools connect to outside data and services through a common interface, and ChatGPT uses it by connecting to MCP servers as a client. You add a server as a connector, ChatGPT reads its available tools, and the model can call them mid-conversation.
The protocol started at Anthropic and has since become genuinely cross-platform. It's no longer a niche: Anthropic reported more than 10,000 active public MCP servers when it donated MCP to the Linux Foundation in December 2025, and an independent census by Nerq indexed roughly 17,468 servers in early 2026. That adoption is the whole point of a standard — a server you build once can, in principle, work across multiple assistants.
On ChatGPT specifically, custom MCP connectors became generally available through Developer Mode on September 9, 2025, on paid accounts. That's the mechanism: point ChatGPT at a remote server, authenticate, and its tools become available in chat.
→ For the connection mechanics across tools: How to Connect an LLM with MCP
Is ChatGPT a full MCP client or a limited one?
It's a full MCP client on tools — the "limited" framing you'll see repeated online is out of date. OpenAI's own documentation states that Developer Mode provides full MCP client support for all tools, both read and write. So the idea that ChatGPT can only read through MCP, or only call a fixed pair of tools, is wrong for standard connectors.
There's a plan-tier nuance worth knowing: full write support has been rolling out in beta to ChatGPT Business, Enterprise, and Edu plans, so exactly what's available depends on your account. But the capability ceiling isn't the limitation people think it is.
The constraint that actually shapes how you work with ChatGPT lives somewhere else entirely — in how it connects, not what it can do once connected.
Why does ChatGPT only support remote MCP servers?
Because ChatGPT runs in OpenAI's cloud, not on your machine — so it can only reach servers exposed over the network as remote HTTPS endpoints, using SSE or streaming HTTP transports. It does not run local stdio servers, the kind that launch as a process on your own computer.
This is the single biggest difference from desktop AI clients. Claude Desktop, Cursor, and Claude Code can spawn a local server directly — you point them at a command, they run it, done. ChatGPT can't see your machine. A server that works instantly in Claude Desktop needs to be either hosted somewhere with a public HTTPS endpoint or exposed through a tunnel before ChatGPT can touch it.
Neither approach is "better." They're different shapes for different runtimes:
- Local stdio (Claude Desktop, Cursor): fast to set up for personal use, runs on your hardware, nothing to host.
- Remote HTTPS (ChatGPT): reachable from anywhere, needs a hosted endpoint and proper authentication — typically OAuth 2.0, dynamic client registration, or a static bearer token.
If you've only ever run local servers, the mental model to update is simple: for ChatGPT, the server has to live at a URL, not a file path.
What's different about ChatGPT's Deep Research connectors?
Deep Research and company-knowledge connectors add a stricter contract than a general Developer Mode connector: the server must implement two standardized read-only tools named search and fetch. Miss them, and ChatGPT can't use the server for research — it surfaces a "search action not found" error that sends people down a debugging rabbit hole.
This is where the "ChatGPT MCP only does search and fetch" myth comes from. It's half-true, but scoped: that requirement applies to the Deep Research surface, not to Developer Mode connectors generally. A regular connector can expose whatever tools you define. A Deep Research connector has to speak that specific two-tool dialect.
The practical takeaway: check which ChatGPT surface you're targeting before you build. A general connector and a Deep Research connector have different minimum requirements, and conflating them is the most common reason a working server appears broken.
What does this mean if you use ChatGPT alongside other AI tools?
It means the same underlying context has to be delivered two different ways, because your tools don't share a transport. A local stdio server hands context to Cursor and Claude Desktop on your machine; a remote HTTPS server hands the same context to ChatGPT over the network. Two paths, one thing you actually want them to know.
That's manageable when what you're connecting is a single data source. It gets awkward when what you're connecting is you — your role, your projects, how you work — because now that has to be consistent across every tool, regardless of how each one connects. Rebuild it per tool and it drifts. The cleaner model is one canonical source of context, served over whichever transport a given tool speaks, so ChatGPT and your desktop tools read the same profile instead of three divergent copies.
This is also where connectors and a context layer part ways. A connector gives a tool access to a raw source to search. A context layer delivers a structured picture of who you are — a different job, and one that benefits from being transport-agnostic by design.
→ On that distinction: Connectors vs MCP vs a Context Layer: What's the Difference?
The short version
ChatGPT is a full MCP client — read and write, subject to plan tier — that connects only to remote HTTPS servers, with a stricter search/fetch contract reserved for Deep Research. If you internalize the transport difference, most of the "why doesn't this work like Claude?" friction disappears. The protocol is shared. The plumbing isn't.
For the layer underneath all of this — the context you want every tool to load, whatever transport it speaks — start here: What Is Personal Context for AI?
