Custom remote MCP connector: tools never surfaced to the model in claude.ai web, while the broker completes the full OAuth + MCP handshake server-side (same server works in ChatGPT + Claude Code)

[micelijo]

Summary

A Connected custom remote MCP connector (FastMCP, OAuth, Streamable HTTP, stateless_http=True + json_response=True) shows as Connected with all its tools listed in claude.ai web Settings, but its tools are never handed to the model in conversations — the model only sees first-party connectors (e.g. Notion, Gmail). The same server with the same OAuth identity works in ChatGPT and in Claude Code's native MCP client. Server-side access logs prove Anthropic's broker completes the full OAuth + MCP handshake and even issues tool calls, so the failure is host-side tool surfacing, not the server.

Environment

• Custom remote MCP server: Python FastMCP on Starlette/uvicorn, Streamable HTTP at /mcp, stateless_http=True, json_response=True.
• Auth: OAuth 2.1 authorization-code + PKCE/S256, JWKS backed by AWS Cognito, refresh tokens enabled.
• Plan: Max (personal).
• Onset: ~2026-06-18 to 06-20 (the connector worked before this window).

What I verified server-side (healthy and unchanged)

1. Healthy: valid TLS; unauthenticated POST /mcp returns 401 with a correct RFC-9728 WWW-Authenticate header + resource_metadata pointer; both /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server return 200 and are well-formed.

2. OAuth / identity provider unchanged: the OAuth app-client config was last modified ~1 month before onset; audit logs show no auth-relevant change in the window; recent identity-provider updates are idempotent CI re-applies (identical request parameters across deploys).

3. The broker completes the handshake AND calls tools — the server returns success. Load-balancer access logs for a reconnect show, from Anthropic broker egress IPs (160.79.106.x, User-Agent Claude-User):

   POST /oauth/token  200   <- fresh token minted
   POST /mcp          200   <- initialize
   POST /mcp          202   <- notifications/initialized (handshake completed)
   POST /mcp  200 xmany     <- tool list/calls, all succeed
   

   So /oauth/token, initialize, notifications/initialized, and the subsequent /mcp calls all succeed at the server — yet the tools never appear to the model in chat.

4. Works in other clients: the identical server + OAuth works in ChatGPT (openai-mcp/1.0.0, 200s in the same logs) and in Claude Code's native MCP client (tools load and execute).

Expected vs actual

• Expected: a Connected custom connector's tools are loaded into the conversation's tool set, the way first-party connectors are.
• Actual: the tools are never surfaced to the model in claude.ai web; only first-party connectors (Notion, Gmail) appear.

Likely area

This matches the recent web-only connector cluster (#470, #471, #472, #473, #474) and the tool-discovery issue anthropics/claude-code#69686. The distinguishing factor appears to be custom vs published/directory connectors: the tool-calling runtime is documented as identical between the two, but the tool surfacing/discovery layer — exactly where published and custom connectors differ — is where this fails.

Repro

1. Add a custom remote MCP connector (FastMCP, stateless_http=True + json_response=True, OAuth) in claude.ai web on a Max plan.
2. Complete the OAuth flow; the connector shows Connected with its tools listed in Settings.
3. Start a new chat: the model does not have the connector's tools (only first-party connectors surface).
4. Connect the same server in ChatGPT or Claude Code: tools load and execute normally.

Ask

Surface Connected custom-connector tools to the model in claude.ai web conversations, on par with directory connectors. Happy to provide load-balancer access logs or an ofid for a specific failing connect on request.

[raucci2000]

Related: this may be part of the same regression cluster described in #476 — where custom connectors using FastMCP (stateless_http=True + json_response=True) show as Connected but their tools are never surfaced to the model in claude.ai web conversations. If the tools are not reaching the model at all, the MCP Apps rendering failure I described here would be a downstream symptom of that, not the root cause.

[firesiteIO]

Independent reproduction on a completely different server stack — strong evidence this is host-side surfacing, not a server-implementation quirk.

We hit this exactly. A brand-new custom remote MCP connector (deployed 2026-06-30) shows Connected on claude.ai desktop web, but its tools are never handed to the model in conversations — tool_search/the model simply never sees them. The same connector, same account, same OAuth grant works on Claude.ai iOS and on Cowork (desktop), where the tools load and execute against live data. On desktop web we tried both Claude Opus 4.x ("5") and 4.6 — tools never surface. Because connectors sync account-wide, the grant is demonstrably valid (iOS uses it fine); desktop web just doesn't inject the tools.

Our stack shares nothing with the OP's (theirs: Python FastMCP / Streamable-HTTP / AWS Cognito). Ours:

• Server: Node/Express on Firebase Cloud Functions. Single request/response JSON-RPC over POST, stateless, Content-Type: application/json (no SSE stream).
• Auth: OAuth 2.1 authorization-code + PKCE S256, RFC 7591 Dynamic Client Registration (public client, no secret), RFC 8414 AS metadata, RFC 9728 protected-resource metadata. Access token is a Firebase-issued RS256 JWT (iss: https://securetoken.google.com/firesiteusers).
• Resource: https://max.firesite.ai/api/mcp/ar — authorization server https://auth.firesite.io.
• Tools (3): kb_search, artifact_get, coldstart_get.

Server-side evidence — everything the broker needs is healthy, and the broker itself completes the handshake:

1. Unauthenticated POST /api/mcp/ar → 401 with a correct RFC-9728 challenge:
   WWW-Authenticate: Bearer resource_metadata="https://max.firesite.ai/.well-known/oauth-protected-resource"
2. GET /.well-known/oauth-protected-resource → 200

   { "resource": "https://max.firesite.ai/api/mcp/ar",
     "authorization_servers": ["https://auth.firesite.io"],
     "scopes_supported": ["mcp:read"], "bearer_methods_supported": ["header"] }

3. GET https://auth.firesite.io/.well-known/oauth-authorization-server → 200 (RFC 8414), code_challenge_methods_supported: ["S256"], token_endpoint_auth_methods_supported: ["none"].
4. Full flow completes end-to-end (DCR → /authorize + PKCE → login → code → /token → access token → tool call). Verified via an automated harness: 15/15, including a real kb_search returning live corpus over HTTP.
5. initialize (with a real token) → 200 application/json:

   { "jsonrpc":"2.0","id":1,"result":{
       "protocolVersion":"2024-11-05",
       "capabilities":{"tools":{}},
       "serverInfo":{"name":"arkb-ar","version":"0.1.0"} } }

   (stateless — no Mcp-Session-Id header issued, matching the OP's stateless_http setup.)
6. tools/list → 200 application/json returns all three tools with valid JSON Schema inputSchema (e.g. kb_search requires query:string, optional plane enum + limit integer; additionalProperties:false). Full list returns every time.

We also just tightened initialize to negotiate the protocol version — it now echoes the client's requested version when supported (2025-06-18 / 2025-03-26 / 2024-11-05) instead of hard-pinning 2024-11-05 — to remove version handshake as a variable. It did not change desktop-web behavior (as expected, since the broker already fetches tools/list fine either way).

Net: two unrelated server implementations (FastMCP/Cognito vs Express/Firebase), identical symptom — the OAuth + MCP handshake completes, Anthropic's broker successfully fetches tools/list, but claude.ai desktop web never injects the connector's tools into the model's callable context, while iOS and Cowork do. This is host-side tool surfacing on desktop web, independent of the server. +1 — happy to provide full request/response captures or a live endpoint for tracing.

[indysigner]

#476

Confirming this on a different custom connector, same symptom-shape and same conclusion (host-side tool surfacing, not the server).

Environment:

• Self-hosted MCP server (n8n-based), Streamable HTTP, single tool exposed
• OAuth 2.1 authorization-code flow, static/pre-registered client
• Onset: unknown exact date, confirmed broken as of 2026-07-01

What I verified server-side (healthy and unchanged):

• Valid TLS, HTTP/2; unauthenticated POST returns a clean 401 JSON response
• Server-side access log shows successful OAuth token issuance during the exact window of a failing claude.ai chat attempt:
  [oauth] Auth code issued for client_id: [redacted]
  [oauth] Token issued for client_id: [redacted]
• Client secret verified identical between the running container's env and the source .env (ruled out a stale-secret theory before finding this issue)

Claude.ai settings UI already shows the connector as "Connected" with its single tool correctly listed and permission set to "Always allow": this implies a successful authenticated tools/list happened at connector-setup time, consistent with your point about the broker completing the handshake server-side.

Tested both tool-loading modes in claude.ai chat, same negative result in both:

1. "Load tools on demand": tool_search only returns first-party connectors (Gmail, Google Drive), never the custom connector's tool, across multiple fresh conversations
2. "Tools already loaded": tool_search correctly disappears (expected for this mode), but a direct call to the tool by its expected name fails with "Tool not found"

Same connector, same server: works correctly when invoked from Claude Code (successfully completed a real write operation via the same tool), matching your ChatGPT/Claude Code cross-check.

Happy to provide a fresh reproduction with correlated init/tools-list access-log timestamps if useful. Server URL and client ID redacted here; happy to share privately with an Anthropic engineer if it helps narrow down the root cause.

[glic3rinu]

for me this issue started yesterday, been running my mcp daily for months without issue, now the only place where claude is able to discover the tool is if i send a message from iOS app. Desktop and web ui dont work for me ATM. very annoying.

[jumpmancol]

Adding an independent repro on a different stack, which I think helps isolate this to the tool-surfacing layer rather than anything FastMCP-specific.

Setup

• Custom remote connector, claude.ai web (also confirmed on desktop)
• Server: Supabase Edge Function (Deno), MCP Streamable HTTP
• Stateless: no mcp-session-id issued
• enableJsonResponse: true (POST path returns plain JSON, not SSE)
• Auth: static key via Authorization: Bearer / x-brain-key / ?key= query param. No OAuth in the picture at all, which rules out the OAuth-metadata path as the cause and points at the same surfacing layer Custom remote MCP connector: tools never surfaced to the model in claude.ai web, while the broker completes the full OAuth + MCP handshake server-side (same server works in ChatGPT + Claude Code) #476 describes.
• 14 tools exposed (search_thoughts, capture_thought, etc.)

Symptom (matches this issue)

• Connector shows Connected, and all 14 tools appear in Settings > Connectors > Configure.
• In chat, none of the tools are ever surfaced to the model. Only first-party connectors (Gmail, Drive, etc.) are available. tool_search for the custom tools returns nothing.

Server is provably fine
Direct curl against the endpoint returns full results at every step:

• initialize -> 200
• tools/list -> 200, all 14 tool schemas returned
• tools/call on search_thoughts -> 200, real results back

So the handshake and tool execution both succeed server-side; the only broken step is the host handing those tools to the model in conversation.

Onset
Worked previously, broke around the same time (for me, I saw it on the 20th/21st) window others in this cluster report. I did have sporadic success since then, but not consistent and now fully broken after the latest client update.

Workaround confirmed
Same server loads and executes normally through Claude Code's native MCP client. Failure is isolated to the claude.ai web/desktop tool-loading path.

Happy to share an ofid for a specific failing session on request.

[firesiteIO]

A workaround for this, although annoying, is to open the same Claude session on the iPhone app, giving Claude the ability to access the MCP resources there and then returning to the desktop to pick up the changes in the same session. This works for our implementation anyway.

[gowry]

Confirming the same behavior here, and it is a recent regression on my side.

Setup: self-hosted remote MCP server (Python, FastMCP, Streamable HTTP at /mcp), OAuth 2.1 authorization code + PKCE (S256), single-tenant. Three tools: remember, recall, observe.

This worked for me until a few days ago. Same server and connector, unchanged: the three tools surfaced in claude.ai and Desktop chats and were callable. Then, without any change on my end, they stopped being handed to the model. The connector still shows "Connected" and lists all three tools in Settings with "always allow", but the assistant reports it has no such tools and describes the connector as usable only in the artifact/API context. The identical server still works in Claude Code and in ChatGPT.

It is host-side, not the server. I just reconnected and captured my server logs. The full OAuth + MCP handshake from claude.ai completes cleanly (redacted, endpoint host removed):

POST /mcp                                    401
GET  /.well-known/oauth-protected-resource   200
GET  /.well-known/oauth-authorization-server 200
POST /oauth/register                         201
GET  /oauth/authorize?...redirect_uri=https://claude.ai/api/mcp/auth_callback&code_challenge_method=S256&resource=https://<my-host>/mcp   302
GET  /oauth/identity/accept?token=<redacted> 302
POST /oauth/token                            200
POST /mcp                                    200   (initialize)
POST /mcp                                    202
POST /mcp                                    200   (session setup incl. tools/list)
POST /mcp                                    200
POST /mcp                                    200

So the server registers, authenticates, and answers the MCP session (including tools/list) with 200s. The tool list reaches Anthropic's infrastructure. It just never surfaces to the assistant in a chat.

Workaround confirmed: if I start the session in the iOS app and then continue it on claude.ai web or the desktop app, the tools do surface and are callable. So the failure is specific to sessions that originate on web/desktop, which further points at the surfacing/discovery layer rather than auth or the server.

Regression onset lines up with the recent connector changes. Is this a recognized custom-connector surfacing regression on the web surface, and is a fix or rollback in progress? Happy to share more.

[zoidberg-3]

Same symptom, independent server — with two data points that narrow the dividing line: it tracks OAuth vs no-auth, not custom vs published.

Setup: Python FastMCP (3.4.2) server, Streamable HTTP at /mcp, GitHub OAuth via fastmcp's OAuth proxy (authorization-code + PKCE, DCR supported), behind a Cloudflare named tunnel. Personal Max plan, claude.ai web.

Symptom (observed 2026-07-06 and 07-07): Connector shows Connected in Settings. Server logs show the claude.ai broker (160.79.106.x) completing the full OAuth flow and initialize → tools/list successfully on every single attempt across two days. tools/call never arrives from a web chat — the model reports it has no connector tools in fresh conversations with the connector toggled on.

Evidence that the server side is healthy:

• MCP Inspector (@modelcontextprotocol/inspector) against the same public URL: full OAuth + tools/call round-trip works.
• Claude mobile app, same account, same connector, no changes: tools surface and calls land (verified server-side — CallToolRequest in logs, real results returned). Web-only failure confirmed from this end too.

The data point that may narrow it: a no-auth custom connector (DeepWiki, https://mcp.deepwiki.com/mcp) added the same way on the same account works perfectly in web chat — tools surface and get called. So at least for this account, custom connectors as a class are fine on web; the failure follows the OAuth-protected connector specifically.

Also ruled out (each tested after a full Settings disconnect → reconnect to force a re-probe): json_response True/False and stateless_http True/False — all combinations behave identically. Response framing and session mode are not factors.

Happy to provide server logs if useful.

[Balzinho]

Confirming the same issue with an identical symptom pattern, on a paid connector integration.

Setup: claude.ai web, custom remote MCP connector for Peec.ai (AIO/GEO visibility analytics, OAuth).

Symptoms:

• OAuth completes successfully. The connector shows as Connected in Settings and correctly lists all 8 tools (list_projects, list_brands, list_prompts, list_topics, list_tags, get_brand_report, get_domain_report, get_url_report).
• In conversations, none of these tools are ever surfaced to the model. The model cannot call them. First-party connectors in the same account work normally.
• This worked reliably for roughly two months (April to June 2026). I built four complete market-tracking projects through this connector. It stopped working in early July with no changes on my side.
• The vendor (Peec AI) checked their server and API logs and confirmed everything is healthy on their side, and pointed me to this issue as the matching known bug.

Business impact: this connector is the primary reason for a paid annual analytics plan (CHF 8,000). The integration is used for weekly brand visibility reporting to our executive team and our parent banking group. It is currently fully blocked on claude.ai web.

Happy to provide timestamps, HAR files, or connector details to help triage. A fix or workaround guidance would be very welcome.

[aaronali1983-cloud]

Adding a directory/published connector data point to this cluster (most reports here are custom connectors — this one is the published Interactive Brokers connector, same failure signature).

Environment: Claude Desktop 1.18286.0 (latest), Windows 11 Pro. The IBKR connector registers under the Web connectors section; Desktop reuses that path.

Symptom: IBKR shows Connected with all 21 tools (18 read / 3 write) correctly listed in the Settings permissions ledger. In chat sessions, zero IBKR tools are surfaced to the model. First-party connectors (Gmail, filesystem) inject normally in the same sessions — confirmed by having the model enumerate its own tool context.

Host-side isolation proof: The identical connector + stored OAuth credentials work end-to-end via the Messages API mcp_servers path: tool discovery returns all 21 tools, and a read-only get_account_summary call executes successfully (mcp_tool_use → mcp_tool_result with live data). So OAuth, the connector registration, and the IBKR server are all healthy — the failure is specifically the session-side tool-surfacing layer in claude.ai/Desktop, matching the diagnosis in this thread.

Onset: consistent with the ~2026-06-18–20 window noted here.

Eliminated (full teardown + clean reconnect): app fully quit incl. tray, OAuth re-completed in incognito with a live provider session, timed 3-min wait between disconnect/reconnect, verified permissions ledger, "Tools already loaded" pre-load mode. No effect. First-party connectors as working controls.

Happy to provide reproduction timestamps for host-side injection-log inspection.