ChatGPT MCP: Connect Tools to ChatGPT in 2026
ChatGPT can now use remote MCP servers as custom apps, but plan access, transport, authentication, and product-mode limits determine whether the setup works.
ChatGPT MCP lets eligible users connect a remote MCP server as a custom app, expose its tools to ChatGPT, and approve actions from a conversation. In 2026, the setup is real but not universal: full read/write support is a Business, Enterprise, and Edu beta, while Pro connections remain limited to read and fetch.
Table of contents
- The short answer
- How ChatGPT MCP works today
- How to add an MCP server to ChatGPT
- ChatGPT vs other MCP clients
- The catch most guides skip
- What to connect first
- What actually breaks
- Our verdict
The short answer
ChatGPT is an MCP client, but it connects through the Apps interface rather than a local JSON file. You provide a remote endpoint, choose authentication, scan the tools, and select the app in a new chat.
Full MCP, including write actions, is rolling out in beta to ChatGPT Business, Enterprise, and Edu on the web. Pro users get read/fetch connections in developer mode, while custom apps are unavailable on mobile. Those boundaries make many older “ChatGPT MCP server” tutorials misleading. Check OpenAI’s current developer-mode guide before deploying.
How ChatGPT MCP works today
ChatGPT acts as the MCP host, connects to a remote server, discovers its tools, and can call a relevant tool during conversation. The server handles authentication, authorization, validation, execution, and returned data.
MCP messages use JSON-RPC. Remote servers normally use Streamable HTTP: one endpoint accepts HTTP requests and may stream responses with Server-Sent Events. Local clients can launch a server over stdio, but ChatGPT does not directly spawn that process. The MCP architecture documentation explains the host-client-server split, while the transport specification defines both transports.
A package that only gives you an npx or Python command is not automatically a URL ChatGPT can scan. For ChatGPT, we prefer a vendor-hosted remote server with documented authentication. Operate your own remote layer only when necessary. Start discovery with our best MCP servers, then verify each candidate against its owner’s documentation.
How to add an MCP server to ChatGPT
The setup is a seven-step web workflow with no mcpServers JSON block. A guide telling you to paste a command into ChatGPT settings is describing another client or an outdated workaround.
-
Confirm plan and role. Full MCP requires Business, Enterprise, or Edu. Business limits deployment to admins or owners; Enterprise and Edu can authorize developers. Pro is read/fetch only.
-
Get the real endpoint. Use the remote endpoint published by its owner. For a developer machine, private network, or on-premises server, OpenAI directs users to Secure MCP Tunnel.
-
Enable developer mode. Admins enable it under
Workspace Settings → Permissions & Roles → Connected Data. An eligible user then usesSettings → Apps → Advanced Settings; the flow is also available fromWorkspace settings → Apps → Create. -
Create the app. Go to
Workspace settings → Apps → Createas an admin/owner, orSettings → Apps → Createas an authorized user. Enter the endpoint, requested metadata, and the authentication mechanism the server supports. Never guess an OAuth client, header, or URL. -
Scan and authenticate. Click
Scan Tools, then complete OAuth if prompted. The identity provider must issue refresh tokens where required; otherwise users may need to sign in again after tokens expire. -
Test the draft. Click
Create, open a new chat, and select the app from the tools menu. Try a narrow read request before a reversible write. -
Publish after review. Admins and owners use
Workspace Settings → Apps → Drafts → Publish. Business apps must currently be recreated and republished when tools or metadata change; Enterprise/Edu admins have finer action controls. These paths come from OpenAI’s deployment instructions. See how to add an MCP server for a client-agnostic checklist.
ChatGPT vs other MCP clients
ChatGPT suits centrally governed remote tools; it is a poor choice for quick local experiments. Claude Desktop, Cursor, and Windsurf offer a shorter path to local stdio servers.
| Client | Local stdio | Remote HTTP | Main configuration | Best fit | Material limit |
|---|---|---|---|---|---|
| ChatGPT | No direct connection | Yes | Apps UI | Governed shared apps | Full writes are plan-gated; web only |
| Claude Desktop | Yes | Yes | Extensions/connectors UI | Local resources and remote services | Local extensions need Desktop/Claude Code |
| Cursor | Yes | Yes | .cursor/mcp.json or ~/.cursor/mcp.json | Project-scoped coding tools | Too many tools can distract the agent |
| Windsurf | Yes | Yes | Marketplace or ~/.codeium/windsurf/mcp_config.json | Coding with visual management | Maximum 100 enabled MCP tools |
Cursor supports stdio, SSE, and Streamable HTTP, with approval on by default; its MCP documentation confirms both config paths. Windsurf supports the same transports and documents its 100-tool ceiling in the Cascade MCP guide. For code and terminal work, we would choose Cursor MCP. For local desktop files or tools, Claude Desktop MCP fits better.
The catch most guides skip
“Supports MCP” does not mean “supports every MCP server in every ChatGPT mode.” Transport, plan, product surface, admin policy, authentication, and action type are separate gates.
A local stdio server is the common failure: a localhost URL or desktop command will not work directly. Use Secure MCP Tunnel for private or local deployments, or host a proper Streamable HTTP service. We would avoid improvised public tunnels for production data; the trade-off is deployment work for a smaller exposure surface. The protocol recommends authentication and Origin validation for Streamable HTTP.
OpenAI also says agent mode will not use custom apps. Deep research can use them only for read/fetch, not writes. Ordinary chats can use enabled apps, while write actions may require confirmation or be blocked. Confirmations do not make an untrusted server safe: OpenAI warns about prompt injection and makes the workspace responsible for vetting apps. Treat OpenAI’s security and availability notes as requirements.
What to connect first
Start with one bounded, vendor-owned integration that saves repeated lookup work. We would not begin with email, a production database, or dozens of write actions.
1. GitHub for repository and issue context
GitHub is our first pick for engineering teams because its official server covers repositories, files, issues, pull requests, and workflows. Begin read-only with narrow repository scope; add writes after observing real calls. GitHub documents hosted and local variants plus read-only mode in the official GitHub MCP server repository.
2. Sentry for production-error investigation
Sentry is second because the task boundary is clear: investigate an error, inspect events, and connect findings to code. Its server is maintained in Sentry’s GitHub organization and offers a hosted service. Verify the current endpoint and authentication in the official Sentry MCP repository.
3. Notion for internal knowledge
Notion is the best non-code start when policies, runbooks, and project context live there. Connect only approved pages and test retrieval before allowing edits; broad workspaces amplify stale information. Notion documents its vendor-operated connection in the Notion MCP help center.
What actually breaks
Most failures are configuration mismatches, not model failures. Check connection, authentication, then tool exposure.
- Tool scan fails: confirm the MCP endpoint is reachable and speaks a supported remote transport.
- OAuth expires: verify that the identity provider issues the refresh tokens OpenAI requires.
- Tools look stale: refresh actions where permitted; Business may require recreation and republication.
- The app is not called: start a new chat, select it in the tools menu, and request one outcome.
- It works in Cursor, not ChatGPT: suspect the
stdioversus remote-HTTP gap.
Our verdict
ChatGPT MCP is worth using for a small set of remote, accountable services shared across a workspace. Its admin review, publishing, and confirmations suit business workflows, but plan gates and remote-only architecture make it a poor universal test bench.
We would deploy one read-heavy official server, measure use, and add write actions individually. We would avoid aggregators full of unknown community tools and broad production credentials. ChatGPT’s advantage is governed access inside familiar chat; the price is more infrastructure and less local flexibility than developer-first clients.