ChatGPT Won't Load Your MCP Connectors? Not Your Server

In short

Since August 20, 2026, our custom MCP connector (self-hosted, mcp.arleo.eu, OAuth 2.1 + PKCE + MCP-spec compliant) stopped working in ChatGPT, without a single line of code or configuration changing on the server side. The connector had worked without issue up until the day before.

Symptom on the ChatGPT side: a banner reading “connected, but not all requested permissions were granted,” followed by “No app actions are available right now” — zero tools loaded, on every attempt.

After an exhaustive investigation (server logs, a direct capture of the initialize response, A/B tests across four different versions of our code, a counter-test with a third-party client emulating ChatGPT, a Cloudflare check, contacting OpenAI support), the cause is not a defect in our server. Everything points to a recent OpenAI restriction limiting full MCP support to the ChatGPT Business, Enterprise, and Edu tiers — effectively removing this access from Plus accounts, with no clearly announced change and no explicit error message. See also the full audit run by Claude.ai (Pro account) on this same server, which hit no problem at all.

Technical summary

OAuth /authorize        : success
OAuth /token             : success
Bearer token             : accepted
MCP initialize           : HTTP 200, full response
Mcp-Session-Id            : returned
notifications/initialized : never received (real ChatGPT)
tools/list                 : never received (real ChatGPT)
ChatGPT UI                 : "No app actions are available right now"

Reproduced with:
- v1.8.8, v1.9.0, v1.9.1, and v1.9.2 (4 server versions actually redeployed)
- read, write, and admin scopes tested separately
- read-only via ?profile=reader
- a pre-registered static OAuth client and a fresh Dynamic Client Registration client
- an old secret and newly generated secrets

Counter-test: a third-party client (MCPJam) configured to emulate the
"ChatGPT" profile completes the entire flow — 17 steps, tools/list
succeeds, 32 tools listed. The protocol handles a real client playing
"ChatGPT" just fine; it's ChatGPT itself, in practice, that fails to get
there. Claude.ai (Pro) hit no problem on its side on this same server.

What we observed server-side

On every connection attempt, the sequence is always identical and always “successful” up to a certain point:

POST /register        → success (Dynamic Client Registration)
GET  /authorize        → success, redirect with code
POST /token             → success, token issued (PKCE S256 verified)
POST /mcp initialize    → full HTTP 200, MCP session created
                        → then nothing.

No tools/list request is ever sent by ChatGPT after initialize — nor is notifications/initialized. The client silently abandons the MCP negotiation after receiving a valid, complete server response, every single time, without exception.

The initialize response captured live

To eliminate any doubt about our response’s compliance, we manually replayed the first half of the handshake (DCR + PKCE + initialize) with a disposable test client, outside of ChatGPT, to capture exactly what the server returns:

HTTP/2 200
content-type: text/event-stream
mcp-session-id: <session-id>

{
  "jsonrpc": "2.0",
  "id": 0,
  "result": {
    "capabilities": {
      "logging": {},
      "prompts": { "listChanged": true },
      "resources": { "listChanged": true, "subscribe": true },
      "tools": { "listChanged": true }
    },
    "protocolVersion": "2025-06-18",
    "serverInfo": {
      "name": "mcp-hugo-server-go",
      "version": "v1.9.2"
    }
  }
}

A complete response, protocol 2025-06-18 correctly announced, Mcp-Session-Id present. Nothing in this response justifies a client stopping there — which puts the problem squarely on a decision made on ChatGPT’s side after receiving this response, not on a transport-compliance defect.

Real log example — fresh DCR client, default scope

To rule out any caching effect tied to an already-known client_id, we let ChatGPT register itself via Dynamic Client Registration (/register), without giving it a pre-existing identifier. Our DCR policy automatically caps these clients to read for safety, even if the client requests wider access — server logs, UTC timestamps, server-generated client_id (no secret, just a public identifier):

{"time":"2026-08-20T18:58:51Z","level":"INFO","msg":"oauth_register","outcome":"success","client_id":"yz0f4gYkQUSXbsjjRs5oogGcllRBoisE","redirect_uri_hosts":["chatgpt.com"],"scope":"read"}
{"time":"2026-08-20T18:58:59Z","level":"INFO","msg":"oauth_authorize","outcome":"success","client_id":"yz0f4gYkQUSXbsjjRs5oogGcllRBoisE","redirect_uri_host":"chatgpt.com","pkce_used":true,"scope_requested":"read write admin","response_type":"code"}
{"time":"2026-08-20T18:59:01Z","level":"INFO","msg":"oauth_token","grant_type":"authorization_code","outcome":"success","client_id":"yz0f4gYkQUSXbsjjRs5oogGcllRBoisE","pkce_used":true,"scope":"read"}
{"time":"2026-08-20T18:59:02Z","level":"INFO","msg":"mcp: session created","scope":"read","rank":0,"remote_addr":"192.168.122.1:52080"}

ChatGPT requests read write admin at /authorize, our DCR policy clamps it to read when the token is issued (expected, documented behavior, not a bug), the MCP session is created successfully — then, as always, no tools/list request follows. The full cycle repeated twice in a row within the same minute, identically.

Real log example — read-only connector, restricted exposure profile

To test the hypothesis of a “read-only” access still available on Plus accounts, we created a dedicated OAuth client with a strict read scope, connected on https://mcp.arleo.eu/mcp?profile=reader — this ?profile= parameter additionally narrows the tool list actually registered on the session to the “read” subset only (a feature independent of OAuth scopes, added in v1.8.9):

{"time":"2026-08-20T18:50:01Z","level":"INFO","msg":"oauth_authorize","outcome":"success","client_id":"chatgpt-read","redirect_uri_host":"chatgpt.com","pkce_used":true,"scope_requested":"read","response_type":"code"}
{"time":"2026-08-20T18:50:03Z","level":"INFO","msg":"oauth_token","grant_type":"authorization_code","outcome":"success","client_id":"chatgpt-read","pkce_used":true,"scope":"read"}
{"time":"2026-08-20T18:50:04Z","level":"INFO","msg":"mcp: session created","scope":"read","rank":0,"profile":"reader","remote_addr":"192.168.122.1:60656"}

Same result: authentication and session succeed, profile:"reader" correctly registered server-side, and still no tools/list. Reproduced a second time 27 seconds later, identically.

Counter-test: a client emulating ChatGPT completes the flow without a hitch

To verify that the MCP + OAuth protocol exposed by our server has nothing abnormal about it, we replayed exactly the same flow with MCPJam, a dedicated MCP debugging client — explicitly selecting its “ChatGPT” client profile (openai-mcp 1.0.0, GPT-5 nano agent), meant to faithfully reproduce the real ChatGPT connector’s behavior.

The tool’s own diagnosis at the end of the flow:

“The OAuth auto-discovery looks good — no adjustments needed. […] Full flow finished: All 17 steps completed successfully with an access token and refresh token. Server now authenticated: Final MCP request returned 200 OK with the token. The flow shows 9 info logs, 0 warnings, and 0 errors — everything proceeded as expected.”

Corresponding server logs, same time window, same DCR policy (clamped to read) as the real ChatGPT attempts above — but this time with the full rest of the protocol:

{"time":"2026-08-20T19:31:44Z","level":"INFO","msg":"oauth_register","outcome":"success","client_id":"cO8t4giwYq-cPwKzIdTm26XKrkhnwKBM","redirect_uri_hosts":["app.mcpjam.com"],"scope":"read"}
{"time":"2026-08-20T19:31:45Z","level":"INFO","msg":"oauth_authorize","outcome":"success","client_id":"cO8t4giwYq-cPwKzIdTm26XKrkhnwKBM","redirect_uri_host":"app.mcpjam.com","pkce_used":true,"scope_requested":"read write admin","response_type":"code"}
{"time":"2026-08-20T19:31:48Z","level":"INFO","msg":"oauth_token","grant_type":"authorization_code","outcome":"success","client_id":"cO8t4giwYq-cPwKzIdTm26XKrkhnwKBM","pkce_used":true,"scope":"read"}
{"time":"2026-08-20T19:31:49Z","level":"INFO","msg":"mcp: session created","scope":"read","rank":0,"profile":"","remote_addr":"192.168.122.1:41268"}

And, unlike ChatGPT, it doesn’t stop there — real POST /mcp calls with real processing time follow over several minutes (tools/list, then tool calls, with GET /mcp SSE channels open in parallel):

POST /mcp   200   32ms
POST /mcp   200   23ms
POST /mcp   202   0ms     (notification)
GET  /mcp   200   313ms   (SSE channel)
POST /mcp   200   41ms
POST /mcp   200   28ms
GET  /mcp   200   161ms
POST /mcp   200   60ms

Client-side result: 32 tools listed and usable (list_pages, search_content, get_site_information, inspect_rendered, plan_page, suggest_links, etc. — the expected read subset for a read scope), with an explicit summary: “The tools appear to be for content management and site inspection […] Would you like to run any of these tools?”

Same server, same minute, same OAuth/DCR policy, a client claiming to play the role of ChatGPT — and the protocol goes all the way through without the slightest warning. So this is neither an MCP-compliance issue nor a server-configuration one: it is the real ChatGPT connector, specifically, that fails to finish what its own third-party emulation finishes without difficulty.

Another contrast, on the same server, the same week: Claude.ai (Pro account) audited 72 tools with real write operations — pages, bilingual bundles, chunked upload, build/publish, Hugo admin management — without finding a single bug. So this is not a question of the server’s general robustness against AI clients either.

What we ruled out, with evidence

Before concluding on an external cause, we methodically eliminated every plausible internal explanation:

• Redirect URI / OAuth allowlist: directly tested the server-side matching function with the exact path returned by ChatGPT (https://chatgpt.com/connector/oauth/<id>) — the registered wildcard matches correctly. Code unchanged for several weeks.
• OAuth response scope (write vs read write): a plausible theory (that ChatGPT compares requested/granted scopes textually in the /token response, rather than trusting our internal admin ⇒ write ⇒ read hierarchy) was tested by deploying to production a fix that does exactly that — the /token response did contain "read write admin" instead of "admin" alone. The symptom persisted identically. Hypothesis invalidated empirically, not just by reasoning.
• Go dependencies: a recent bump of 11 modules (MCP SDK, x/net, x/oauth2, etc.) was among the repository’s most recent changes. The A/B test below, which also redeploys versions predating this bump, implicitly rules it out: versions without this bump fail just as much.
• Tool-catalog discovery cache: verified that a recent fix related to tool-catalog consistency had been merged to our repository 9 hours after the first observed outage, and deployed to production 9 hours after that — chronologically impossible as a cause.
• Cloudflare (WAF / bot management): direct query against the GraphQL Security Events API on our zone — zero block, challenge, or rate-limit events on the MCP connector domain over a rolling 24 hours.
• Per-tool securitySchemes metadata (an extension documented by OpenAI for its Apps SDK): implemented and deployed for testing — no effect, consistent with ChatGPT never reaching the tools/list step where this metadata would be read.
• Full OAuth credential rotation (new client_id/client_secret, including a client dedicated to the full admin scope): same failure, identically.
• Scope narrowed to read-only (read only, exposure profile restricted to read tools): same failure, identically — logs above.
• Compliance of the exposed MCP/OAuth protocol: a third-party client faithfully emulating ChatGPT completes the entire flow without the slightest warning, and Claude.ai audits 72 tools with no anomaly on the same server — see the counter-test above.

The decisive test: A/B across 4 real server versions

To definitively settle the question “is this a regression in our code?”, we rebuilt and redeployed, one after another, under real conditions, four distinct versions of our server — including the one that had served the last successful ChatGPT session, redeployed bit for bit:

Four versions, including v1.9.1 which had genuinely served a successful ChatGPT session a few days earlier, redeployed bit for bit with no modification whatsoever: the same failure, every time. This result rules out any software regression on our side, at any level of the tested code, over more than ten days of history — dependencies included.

What OpenAI says

The official documentation currently contradicts itself across two official pages.

The Help Center article Developer mode and MCP apps in ChatGPT, in its “Availability and requirements” section, currently states (translated from the French-language Help Center):

“Apps, full MCP support, and developer mode are available on the ChatGPT web version for ChatGPT Business and Enterprise/Edu customers.”

No mention of the Plus tier.

The official developer guide, however, currently says the opposite:

“Available to Pro, Plus, Business, Enterprise, and Education accounts. […] ChatGPT developer mode is a beta feature that provides full Model Context Protocol (MCP) client support for all tools, both read and write.”

These two official pages directly contradict each other at the time of writing: one includes Plus with full read/write MCP access, the other excludes it entirely from the list of eligible tiers.

Asked directly through its own support assistant (help.openai.com), OpenAI confirms the restrictive version unambiguously (translated from the French-language support chat):

“‘Full’ MCP support (with write/modify actions) and the associated ‘developer mode’ are not available on Plus accounts: they are rolled out in beta for ChatGPT Business, Enterprise, and Edu. Personal plans have at best limited read access (fetch/read) where offered — ‘full MCP’ remains reserved for Business/Enterprise/Edu plans.”

The same assistant then suggested, as a diagnostic test, temporarily publishing a “read-only” profile (read/fetch scopes only, no write/admin action) to see if the Actions tab populates — exactly the test we had already run, under real conditions, with the strict read scope and ?profile=reader documented above. The result contradicts their own hypothesis: even that strictly read-only profile never reached tools/list with the real ChatGPT client, while the same profile works perfectly with a third-party client — which suggests that the “limited read access” mentioned for personal plans does not apply (or not yet, or no longer) to the real ChatGPT connector, at least not at the time of writing.

Why this looks like a bug even though it isn’t

The real problem here is not technical, it’s a communication issue on OpenAI’s side:

• The displayed error message (“not all requested permissions were granted”) suggests an authorization or configuration problem on the developer’s server side — while the authorization flow completes successfully at every measurable step, initialize included, and a third-party client emulating ChatGPT completes the exact same flow in full.
• No banner, no visible changelog entry, no notification accompanies this eligibility-policy change — a developer without the patience to redo this full investigation will likely, wrongly, conclude their own server is buggy.
• The two official documentation pages directly contradict each other at the time of writing, which doesn’t help with a fast diagnosis.
• Support itself, through its own assistant, suggests a workaround test (a read-only profile) that doesn’t actually work in practice — a sign that even internally, the product’s real behavior isn’t yet fully documented or consistent with the public docs.

How to check if you’re in the same situation

If your custom MCP connector used to work and abruptly stopped loading tools in ChatGPT (with an incomplete-authorization message):

1. Check in your server logs whether initialize returns 200 and whether a session is created.
2. Check whether a tools/list request follows — if not, it is very likely not your server.
3. Replay the same flow with a third-party MCP debugging client (MCPJam or equivalent) emulating the ChatGPT profile — if it completes the flow without issue, responsibility clearly shifts to the real ChatGPT connector.
4. Check your ChatGPT plan: if you’re on Plus, that’s likely the cause; on Pro, only read access would theoretically be available per the Help Center (but the developer guide says the opposite) — check case by case.
5. Test an entirely fresh Dynamic Client Registration OAuth client to rule out a local caching issue — if the failure persists, the account/plan theory gets stronger.
6. Test a strictly read-only scope and profile (?profile=reader) before concluding — if even that fails, it is very likely not a write/admin permissions issue.

What we did on our end

Nothing — that’s exactly the point. After this investigation, no change was kept in production on the server side (the A/B tests and experimental binaries were all rolled back). The server remains on a stable version, with the entire client compatibility matrix (Claude.ai, Le Chat, MCP Inspector, MCPJam, third-party connectors) working and unchanged — see the full Claude.ai audit for the detail.

Official OpenAI sources (contradictory as of 2026-08-20)

• Developer mode and MCP apps in ChatGPT — Help Center — reserves full MCP to Business/Enterprise/Edu, does not include Plus
• Developer mode — developers.openai.com — states Pro/Plus/Business/Enterprise/Education are all eligible for full read/write MCP

If you’re hitting the same symptom and have a Business/Enterprise/Edu account to compare against, or if OpenAI has communicated about this change since this article was written, feel free to share the information.