# ChatGPT MCP: Connect Any MCP Server to ChatGPT (2026)

> A practical 2026 guide for developers who already built an MCP server for Claude and want the same server answering inside ChatGPT. Covers what changed when MCP went cross-client, the real differences between Claude, ChatGPT and Cursor, the step-by-step connect flow via Developer Mode, and the OAuth and write-confirmation gotchas that trip people up.

*Source: https://www.infowok.com/chatgpt-mcp-connect-server-2026/ · Sukhveer Kaur · Published October 14, 2026*

---

Most developers treat MCP as a Claude feature. It never was. ChatGPT, Cursor and Gemini all speak MCP (Model Context Protocol — an open standard for connecting AI agents to tools and data). If you built an MCP server for Claude, you need no second integration: ChatGPT MCP support lets you point ChatGPT at the same server.

This guide is for exactly that reader: your Claude server works, and now you want it answering inside ChatGPT. By the end you will know:

- what changed when MCP went cross-client, and why it matters;
- the real differences between how Claude, ChatGPT and Cursor treat your server;
- the exact steps to connect it to ChatGPT;
- the OAuth and write-confirmation gotchas that catch people on the first try.

<KeyTakeaways>

- The MCP server you built for Claude works in ChatGPT unchanged. Only the client-side connector layer differs.
- ChatGPT connects to remote servers only, so a local stdio server has to be exposed over HTTP first.
- Every write needs a manual Confirm in every chat, and nothing on the server side can pre-approve it.
- Deep research connectors use only read-only `search` and `fetch`. Developer Mode exposes the full tool set.
- Keep OAuth scopes per client and as narrow as each one needs.

</KeyTakeaways>

## MCP went cross-client — what actually changed

MCP won the protocol race. The practical result: one server now serves many clients. A year ago, giving three AI apps access to your GitHub or your database meant three separate integrations. Today it can mean one MCP server and three connectors pointing at it.

Claude, ChatGPT, Cursor, Gemini, GitHub Copilot and VS Code have all adopted MCP, and the public server ecosystem now runs into the thousands. OpenAI documents adding a custom MCP server directly inside ChatGPT, so this is a supported path, not a hack.

![One MCP server connecting to Claude Desktop, ChatGPT and Cursor, with ChatGPT's new OAuth and confirmation layer highlighted](./chatgpt-mcp-connect-server-2026-concept.svg)

The server in the middle never changes. What changes per client is **the layer on top**: how it authenticates, which tools it loads, and whether it asks before acting. ChatGPT's layer is the newest and has the most surprises, so most of this guide is about that layer, not about rewriting your server.

## Claude vs ChatGPT vs Cursor: the real differences

Before you connect anything, it helps to see where the three clients diverge. Your server exposes the same tools to all of them; the client decides how those tools are discovered, authorized and confirmed.

| | Claude Desktop | ChatGPT | Cursor |
|---|---|---|---|
| How you add a server | Config file or Connectors UI | Developer Mode → custom connector | `mcp.json` in the project |
| Transport | Local stdio + remote | Remote only (streamable HTTP / SSE) | Local stdio + remote |
| Auth for remote | OAuth | OAuth (client metadata documents, dynamic registration) | OAuth / headers |
| Full tool set vs read-only | Full tool set | Full set in Developer Mode; read-only `search`/`fetch` for deep research | Full tool set |
| Write confirmation | Per-tool approval | Manual confirm on every write, every chat | Per-tool approval |
| Plan requirement | Any plan | Developer Mode: Pro/Plus/Business/Enterprise/Edu | Any plan |

The row that matters most is transport. ChatGPT connects to **remote servers only**, with no "run this local command" option like Claude Desktop's stdio config (where the client launches your server as a local process). A local stdio server must be exposed over a URL first; a remote one is ready to go.

## ChatGPT MCP setup: connect your server step by step

Here is the full flow, start to finish. It assumes a remote server that already runs for Claude and a ChatGPT plan that includes Developer Mode (Pro, Plus, Business, Enterprise or Education).

![Five-step flow to connect an MCP server to ChatGPT: enable Developer Mode, create the connector with OAuth, authorize, pick it in a chat, then confirm each tool call](./chatgpt-mcp-connect-server-2026-flow.svg)

### Step 1: Turn on Developer Mode

In ChatGPT, open Settings, go to the Connectors tab (labeled Apps in some builds), open Advanced settings, and toggle Developer Mode on. This is the step most people miss. Without it, there is no "add custom connector" option anywhere in the UI.

### Step 2: Create the connector

In Connectors, click Create. Give it a name (and optionally a description and icon), paste your MCP server URL, set Authentication to OAuth, and tick the box confirming you trust the server.

```text
Name:            My GitHub Tools
MCP server URL:  https://mcp.example.com/sse
Authentication:  OAuth
Trust:           ☑ I trust this application
```

### Step 3: Authorize over OAuth

ChatGPT redirects you to your server's login, the same OAuth flow Claude used. If your server already handles Claude's auth, there is usually nothing new to build. OpenAI's client supports Client ID Metadata Documents and dynamic client registration, so most standards-compliant auth servers register without manual setup.

### Step 4: Use it in a chat

Start a new chat and attach the connector:

1. Click the **+** icon, choose More, then select Developer mode.
2. Pick your connector as a source and send a prompt that needs a tool.
3. ChatGPT proposes the tool call and waits; click **Confirm** to send it to your server.
4. If you later change your server's tools, open the connector and click **Refresh**.

> **The most common snag:** a connector that saves fine, shows "Connected," and lists *zero* tools, with no error. In almost every case the URL points at the server's home page instead of the MCP endpoint itself (the path that usually ends in `/sse`). Fix the path, click Refresh, and the tools appear.

## The gotchas: OAuth, read-only tools, and write confirmations

This is where ChatGPT MCP connections get tricky. **Three gotchas catch almost everyone**, and none of them show up until you are already connected.

### Gotcha 1: every write needs a manual Confirm

ChatGPT confirms every write action, in every conversation, and the confirmation is manual. Nothing your server can do will pre-approve it. For an interactive chat that is a safety feature; for anything you hoped to automate, it is a hard limit to design around.

<Callout type="warning">

A write can still execute even if your server marked the tool read-only. ChatGPT trusts your labels only so far, which is why OpenAI's guidance is to connect only servers you trust. My advice: treat the trust checkbox as a real decision, not a formality.

</Callout>

### Gotcha 2: deep research connectors are read-only

Deep research connectors and Developer Mode connectors are different things. For deep research, your server should expose just two read-only tools, `search` and `fetch`. A result only becomes a linked citation when it carries a real `url`; return results without one and your sources silently stop linking.

<Callout type="key">

Developer Mode exposes your server's full tool set, including writes, and gates each write behind a manual Confirm. Deep research connectors expose only read-only `search` and `fetch`. Pick the mode to match what the server is for (a knowledge source or an action tool) before you wire it up.

</Callout>

### Gotcha 3: scope OAuth per client

Because the same server now faces several clients, keep OAuth scopes tight and per-client where you can. A token minted for a read-only deep research connector should not carry write permissions it will never use. Least privilege stops being theoretical the moment a second client holds a token to your server.

## One server, many clients: keeping it portable

The lesson underneath all of this: write the server once, against the MCP spec, and let each client's connector layer be the only thing that differs. I'd resist the urge to special-case ChatGPT inside your server code. In practice that means three habits:

- Expose it remotely over streamable HTTP or SSE (server-sent events), so every client can reach it, not just the ones that run local processes.
- Use standards-compliant OAuth, so client registration is automatic rather than a bespoke setup per app.
- Keep tool descriptions clean and honest: every client reads the same descriptions, so a vague one hurts you three times over.

Do that, and adding the next client (Gemini, Copilot, whatever ships next quarter) is **a connector form, not a project**.

## The bottom line

"MCP is a Claude thing" was never true, and in 2026 it is plainly false. **The server you built for Claude will answer inside ChatGPT** once ChatGPT MCP setup is done: Developer Mode on, connector added, authorized. The new parts (remote-only transport, read-only tools, per-write confirmation) never touch your server code. Which client are you connecting next?

<NextSteps title="Where to go next">

- [What Is an MCP Server? A Complete Guide for Developers](/what-is-mcp-server-complete-guide-2026/) — the fundamentals, if you are starting from zero.
- [Build an MCP Server in Python](/build-mcp-server-python-production/) — ship the server you will connect here.
- [Claude MCP Setup: Fixing the Errors Everyone Hits](/claude-mcp-setup-fixes-2026/) — if your Claude side is still fighting you.
- **Read next:** [The Best MCP Servers to Connect to Claude](/best-mcp-servers-connect-claude-2026/) — ready-made servers you can point at ChatGPT the same way.

</NextSteps>
