Custom connector fails with "Couldn't reach the MCP server" — zero inbound traffic at edge (ofid_c58995a431270861)

[sanchit-jk]

Summary

Adding a self-hosted OAuth 2.1 + DCR MCP server as a custom connector fails consistently in both Claude Desktop (v1.3883.0) and claude.ai web. The error shown is:

Couldn't reach the MCP server. You can check the server URL and verify the server is running. If this persists, share this reference with support: ofid_c58995a431270861

Our edge/ingress logs show zero inbound requests from Anthropic on every Connect click — not to /.well-known/oauth-protected-resource, /.well-known/oauth-authorization-server, /oauth/register, /oauth/authorize, nor /mcp. The broker appears to error out inside Anthropic's start step before dispatching any HTTP request to the advertised server. This is the same symptom pattern as #111, #199, and #214.

The same server connects and works end-to-end in Cursor (full DCR + PKCE + auth code + refresh token + tool calls) and in Postman (manual OAuth 2.1 flow), confirming the server and its OAuth layer are fully functional.

Reference IDs (for backend lookup)

• ofid_c58995a431270861 — latest failed Connect attempt (claude.ai web, ~2026-04-24 20:30 UTC, same result on Desktop).
• request_id req_011CaNmqAmgXYeGpumG8bDcZ — related Claude Desktop startup 403 (separate scope entitlement issue, included in case it's relevant).
• Server URL, account UUID, org UUID intentionally omitted from this public issue — happy to share privately with the Anthropic team via support or a DM. The ofid_ above should be enough to look up the failed flow server-side.

Reproduction

1. claude.ai web → Settings → Connectors → Add custom connector.
2. Paste the MCP server URL (self-hosted OAuth 2.1 + DCR + PKCE S256 endpoint). Advanced settings blank.
3. Click Add → connector appears in list.
4. Click Connect.
5. Browser never redirects to the server's /oauth/authorize endpoint. Claude shows the "Couldn't reach the MCP server" toast with the ofid_ reference above.
6. Same steps reproduce identically in Claude Desktop 1.3883.0.

Evidence the server is healthy and spec-compliant

All probes run from the public internet with User-Agent: Claude-User (+https://docs.anthropic.com/claude-code) — the exact UA we believe Anthropic's broker uses. We intentionally tested this to rule out WAF / bot-UA blocking (the resolution in #76 and #64). The server host is redacted as <dev-host> in the samples below.

1. /mcp returns a proper 401 with RFC 9728 WWW-Authenticate

HTTP/2 401
content-type: application/json
www-authenticate: Bearer realm="https://<dev-host>/mcp",
  resource_metadata="https://<dev-host>/.well-known/oauth-protected-resource/mcp",
  error="missing_token"

{"error":"missing_token","error_description":"Authentication required"}

Also passes identically with UAs curl/*, Claude-User, ClaudeBot, and anthropic-ai — no UA-based WAF block.

2. Protected Resource Metadata (RFC 9728)

GET /.well-known/oauth-protected-resource/mcp — 200:

{
  "resource": "https://<dev-host>/mcp",
  "authorization_servers": ["https://<dev-host>"],
  "scopes_supported": ["mcp:read", "mcp:write"],
  "bearer_methods_supported": ["header"]
}

3. Authorization Server Metadata (RFC 8414)

GET /.well-known/oauth-authorization-server — 200:

{
  "issuer": "https://<dev-host>",
  "authorization_endpoint": "https://<dev-host>/oauth/authorize",
  "token_endpoint": "https://<dev-host>/oauth/token",
  "registration_endpoint": "https://<dev-host>/oauth/register",
  "scopes_supported": ["mcp:read", "mcp:write"],
  "response_types_supported": ["code"],
  "grant_types_supported": ["authorization_code", "refresh_token"],
  "token_endpoint_auth_methods_supported": ["none"],
  "code_challenge_methods_supported": ["S256"]
}

4. Dynamic Client Registration works for both claude.ai and claude.com callbacks

POST /oauth/register with redirect_uris: ["https://claude.ai/api/mcp/auth_callback"] returns 201 with a valid client_id, correct echo of redirect_uris, grant_types: ["authorization_code","refresh_token"], response_types: ["code"], token_endpoint_auth_method: "none".

Same request with redirect_uris: ["https://claude.com/api/mcp/auth_callback"] also returns 201 (we accept both per the sunpeak guide note about dual-domain callbacks).

5. Server-side OAuth flow is end-to-end verified in other clients

• Cursor: full DCR → authorize → token → authenticated /mcp → tool calls all work.
• Postman: manual OAuth 2.1 auth-code flow (PKCE, client_credentials_in_body) completes successfully and returns valid JWTs.

What our pod logs show during a failed Connect

With kubectl logs -f on the MCP pod running during a Connect attempt: no inbound requests at all during the attempt window. No /.well-known/*, no /oauth/*, no /mcp. Combined with the WAF tests above, this rules out our edge as the cause — the broker isn't emitting the request.

Hypothesis

Given:

• Our server passes every OAuth 2.1 / MCP spec requirement (PRM, AS metadata, DCR, WWW-Authenticate with resource_metadata, PKCE S256, authorization_code + refresh_token).
• Our server works end-to-end in Cursor and Postman.
• No request ever reaches our edge during a Claude Connect attempt.
• Multiple UAs including Claude-User pass our WAF cleanly.

...the failure is inside the Anthropic-side broker start step — matching the exact pattern of #111 (fix was a server-side allowlist on the Anthropic backend) and #199 / #214.

Environment

• Claude Desktop: 1.3883.0 (CCD 2.1.111), macOS 15 (Darwin 25.x), Apple Silicon.
• claude.ai web: tested on Chrome, reproduces in incognito with fresh cookies.
• Server: FastAPI + FusionAuth-backed OAuth 2.1 behind AWS ALB + AWS WAF (AWSManagedRulesCommonRuleSet). Strictly follows RFC 7591 DCR, RFC 8414, RFC 9728, and the MCP 2025-06-18 spec.
• Tested cleanly after full Claude Desktop + claude.ai cache wipe (filesystem, localStorage, cookies, IDB, Redis-side OAuth state all cleared). Post-wipe behaviour is identical.

Ask

@crondinini-ant — could you look up ofid_c58995a431270861 against the broker-side logs? Based on the identical signature to #111 / #214, we suspect the start step is rejecting our server (possibly on a default-scope or URL-validation step) before dispatching. If so, an allowlist exception for our dev host would unblock us while the root cause is investigated. I can share the hostname + account/org UUIDs privately on request. Thanks!

[claudiovongal-debug]

Same symptom on my self-hosted MCP server. Posting in case additional ofids help correlate server-side.

Setup:

• Public URL: https://claude.marauinvestimentos.com.br/mcp
• Caddy 2.11.2 + Let's Encrypt + IP whitelist 160.79.104.0/21
• Backend: Python 3.12 + FastAPI + MCP SDK 1.27.0, Streamable HTTP, authless
• Plan: Claude Pro Max
• Tested in both Claude Desktop and claude.ai web (Chrome) — same error in both clients

OFIDs registered (zero inbound traffic in Caddy logs for all attempts):

• ofid_da82246ec0f101b5
• ofid_02e4eba05aaf0d04
• ofid_1939cf927633e123
• ofid_7a773faed6a219fa

External probe confirms server is reachable and IP whitelist is correctly enforced:

curl -sI https://claude.marauinvestimentos.com.br/health
HTTP/2 403 (correctly blocks non-Anthropic IPs as expected)

Claude.ai client errors out before dispatching any HTTP request — broker fails inside Anthropic's start step, never reaches my edge.

[KevinHansen73]

Adding another datapoint with the same symptom pattern.

Failure mode: Identical to #227 — Connect button leads directly to "Couldn't connect" / step=start_error with an ofid_* flow ID in the URL. No browser tab opens for OAuth. Tested both with and without OAuth Client ID / Secret in Advanced Settings — same failure either way. Reproduced cleanly after removing and re-adding the connector.

Server side: Self-hosted MCP server behind Cloudflare Tunnel, with a self-hosted OIDC provider on a separate hostname acting as the authorization server. Spec-compliant: returns RFC-9728 WWW-Authenticate: Bearer realm="mcp", resource_metadata="..." on 401, serves valid /.well-known/oauth-protected-resource pointing at the AS, also serves /.well-known/oauth-authorization-server as a defensive fallback for non-spec-compliant clients.

What the orchestrator actually does on Connect (per app-level access logging on the resource server):

1. POST /mcp from python-httpx/0.28.1 (Anthropic source IP) — no auth → 401 with WWW-Authenticate discovery hint ✓
2. GET /.well-known/oauth-protected-resource from same UA — 200, returns authorization_servers: ["<our AS>"] ✓
3. Silence. Orchestrator never fetches the AS's /.well-known/openid-configuration, never attempts /authorize against either the AS or our resource host, never calls /register, never calls /token. The flow simply terminates.
4. ~3 seconds later, a Claude-User UA fires a POST /mcp with no auth → 401. No further OAuth attempts. The connector then sits in a "discovered, never authenticated" state, with subsequent tool calls going out anonymously and 401-ing forever.

Distinct from #217 in one important respect: the orchestrator does successfully fetch our protected-resource metadata. #217 reports the discovery step is skipped entirely. In our case, discovery completes — we see the GET in our access log returning 200 with the AS pointer in the body — but the flow doesn't progress to authorize-initiation. That puts this closer to #227's "broker errors out before dispatching" framing than to #217's "skips discovery entirely" framing.

What works against the same server:

• Claude Code CLI (using the static-bearer fallback path the same server also exposes) — full MCP tool calls succeed end-to-end.
• curl with a manually-obtained JWT from the AS — full server-side validation succeeds, audience and issuer claims correct, signature verified against cached JWKS.

Server-side correctness verified: the protected-resource metadata endpoint returns 200 with valid JSON containing the AS pointer (the orchestrator successfully reads this before stopping), and end-to-end OAuth flows succeed via curl using a JWT minted by the AS. The break is unambiguously in the Anthropic-side broker between "discovery succeeded" and "dispatch authorize."

Happy to share the ofid_* flow ID, hostname, account/org UUIDs, and broader log excerpts privately if it would help correlate against broker-side logs.

[mralbertzwolle]

Same symptom as OP, still affecting our account on May 1, 2026 — broker terminates after exactly one probe per attempt.

Server: https://backend-production-3763.up.railway.app/api/mcp (Railway, HTTP/2)
Client: Claude Desktop Custom Connector
Server UUID (claude.ai-side): 0714c84c-6549-4a8a-a9a8-8c5e0b7728df

Recent flow IDs (all today, UTC):

• ofid_05d9e665d580840a
• ofid_00905119a51c55b5
• ofid_455a219d986da115
• ofid_55110c6e2523665f
• ofid_6d9d5bab04a9b1b8
• ofid_1beda898809cfbba
• ofid_3b826dc1f2fe44aa

Server-side evidence — Railway access logs show exactly one inbound request per ofid attempt, then silence:

11:16:16 POST /api/mcp  → 401  [UA=Claude-User] [src=160.79.106.37]

No follow-up to /.well-known/oauth-protected-resource, /.well-known/oauth-authorization-server, /api/mcp-oauth/register, or /api/mcp-oauth/authorize for any of the seven ofids.

Server is fully spec-compliant — verified by sending byte-for-byte equivalent responses to known-working production MCP servers (Notion, Linear, Sentry, Supabase). Our 401 response is now identical in shape:

HTTP/2 401
content-type: application/json; charset=utf-8
www-authenticate: Bearer realm="OAuth", resource_metadata="https://backend-production-3763.up.railway.app/api/mcp-oauth/.well-known/oauth-protected-resource", error="invalid_token", error_description="Missing or invalid access token"

{"error":"invalid_token","error_description":"Missing or invalid access token"}

vs Notion's (works in claude.ai/Desktop):

HTTP/2 401
content-type: application/json
www-authenticate: Bearer realm="OAuth", resource_metadata="https://mcp.notion.com/.well-known/oauth-protected-resource/mcp", error="invalid_token", error_description="Missing or invalid access token"

{"error":"invalid_token","error_description":"Missing or invalid access token"}

Discovery + DCR + token-exchange all work end-to-end when invoked directly via curl, MCP Inspector, or Claude Code CLI (claude mcp add --transport http https://backend-production-3763.up.railway.app/api/mcp). Only the claude.ai-side broker fails to progress past the single 401 probe.

Server endpoints, all 200/201 + spec-compliant (RFC 6749/6750/7591/8414/9728, PKCE S256):

• GET /api/mcp-oauth/.well-known/oauth-protected-resource
• GET /api/mcp-oauth/.well-known/oauth-authorization-server
• POST /api/mcp-oauth/register — accepts {none, client_secret_post, client_secret_basic}, persists as public client
• GET /api/mcp-oauth/authorize (renders login page)
• POST /api/mcp-oauth/token

Tried since first attempt (no change to symptom):

• realm value (snelstart-mcp → OAuth)
• 401 body shape (custom → RFC 6750: {error, error_description})
• DCR tolerance for non-none token_endpoint_auth_method (per Cannot reach valid MCP server "ofid_975522997a9e2185" #111 guidance)
• WWW-Authenticate error + error_description parameters

Could the team allowlist this server in the broker, or surface what specifically fails the start-step validation against this hostname? Happy to share more diagnostic data privately.

Cross-ref: #143, #214, #217, #219.

[localden]

Thank you for taking the time to report this and for the detailed diagnostics — they're genuinely helpful for narrowing this down. We're currently triaging open MCP issues, and this one is being closed in favor of tracking it in #214, which covers the same problem: claude.ai / Claude Desktop showing "Couldn't reach the MCP server" while the server's own access logs show zero inbound traffic — i.e. the request never leaves Anthropic's side.

Worth noting: #256 captured an x-deny-reason: host_not_allowed header from Anthropic's egress proxy, which is a strong signal that the underlying cause is a host allowlist on our side rather than anything in your server. We're consolidating the affected hosts and ofids in #214 — please follow that issue for updates and feel free to add your host/ofid there if it isn't already captured.