Claude.ai Web Connector — Tool Discovery Succeeds but CallToolRequest Never Sent

[MorysDrecht]

What happened?

Claude.ai's web connector (custom connector via Settings → Connectors) successfully discovers all tools from a remote MCP server via Streamable HTTP, but when Claude attempts to execute a tool (CallToolRequest), zero HTTP traffic reaches the server. The execution request is silently dropped inside Anthropic's infrastructure.
The same server works perfectly via the Messages API mcp_servers parameter (anthropic-beta: mcp-client-2025-11-20), confirming the server implementation is correct.

What did you expect to happen?

Claude sends a CallToolRequest HTTP POST to the MCP server and displays the result.

Steps to reproduce

Steps to Reproduce

Deploy a Streamable HTTP MCP server using the official Python SDK with 80+ tools
Expose via Tailscale Funnel (valid HTTPS, publicly reachable)
Verify with curl that initialize, notifications/initialized, and tools/list all return correct responses
Add as custom connector in Claude.ai Settings → Connectors
Start a new conversation — tools appear in Claude's tool list (discovery works)
Ask Claude to call any tool

Area

MCP Connector (adding/managing servers)

MCP Server (if applicable)

No response

Error messages or logs

Server Logs — Discovery Phase (works)
160.79.106.11:0 - "POST /mcp?token=[redacted] HTTP/1.1" 200 OK       ← initialize
160.79.106.11:0 - "GET  /mcp?token=[redacted] HTTP/1.1" 200 OK       ← SSE listener
160.79.106.11:0 - "POST /mcp?token=[redacted] HTTP/1.1" 202 Accepted ← notifications/initialized
Processing request of type ListToolsRequest
160.79.106.11:0 - "POST /mcp?token=[redacted] HTTP/1.1" 200 OK       ← tools/list
Server Logs — Execution Phase (broken)
(empty — zero requests received)
Verification: Messages API Works
The same server works perfectly via the Messages API MCP connector:
json{
  "model": "claude-sonnet-4-20250514",
  "max_tokens": 4096,
  "messages": [{"role": "user", "content": "Call the ha_status tool"}],
  "mcp_servers": [{
    "type": "url",
    "url": "https://[redacted].ts.net/mcp?token=[redacted]",
    "name": "my-mcp"
  }],
  "tools": [{"type": "mcp_toolset", "mcp_server_name": "my-mcp"}]
}
This returns tool results successfully, confirming the server is correctly implemented.
Configurations Tested (all show same behavior)
SettingResultstateless=True, json_response=TrueDiscovery OK, execution failsstateless=False, json_response=TrueDiscovery OK, execution failsAuth via path prefix (/mcp/TOKEN)Discovery OK, execution failsAuth via query param (/mcp?token=TOKEN)Discovery OK, execution failsNo auth at all (open endpoint)Discovery OK, execution fails

Additional context

Analysis
The web connector appears to use separate code paths for tool discovery vs. tool execution. The discovery client (which runs at connector setup / conversation init) successfully communicates with the server. The execution client (which runs when Claude invokes a tool during conversation) silently fails to make the outbound HTTP request.
This is consistent with issue #1716 on modelcontextprotocol/modelcontextprotocol, where backend discovery succeeds but UI-side tool calls never fire.
Impact
Custom MCP connectors with Streamable HTTP transport cannot execute tools via the web UI, despite successful discovery. The Messages API workaround functions correctly but requires building a separate client interface.

[Galph]

I've been experiencing this exact issue today after it working correctly for months. I have two MCP servers connected to Claude.ai and the behaviour differs between them:
Working: n8n native SSE endpoint

URL format: https://[my-n8n-instance]/mcp/{uuid}/sse
Transport: SSE (Server-Sent Events)
Tool discovery: ✅
Tool execution (CallToolRequest): ✅ works perfectly

Broken: MCPHub proxy endpoint

URL format: https://[my-mcphub-instance]/mcp/{server-name}
Transport: Streamable HTTP (MCPHub's proxy implementation)
Tool discovery: ✅ — full typed schemas load correctly
Tool execution (CallToolRequest): ❌ silently fails, zero requests reach the server

MCPHub's own built-in tool tester executes tools successfully. The Cloudflare AI Workers AI playground also executes tools successfully against the same MCPHub endpoint. Only Claude.ai's web connector fails at the execution step.

This suggests the bug may be specifically in how Claude.ai handles Streamable HTTP transport vs SSE transport — the SSE-based endpoint works, the Streamable HTTP endpoint does not. Both endpoints were configured identically in Claude.ai settings and the MCPHub endpoint worked correctly until today (29 March 2026), suggesting a regression was introduced recently.

MCPHub logs show sessions rebuilding constantly (SESSION AUTO-REBUILD) but tool call requests arriving and initialising successfully — they just never get a response sent back from Claude's execution client, consistent with the behaviour described in this issue.

[jinglejammer]

Additional data point — narrower variant of this bug (2026-04-19)

Adding a reproduction that matches your config (stateless=True, json_response=True, Streamable HTTP on FastMCP + Vercel) but with one diagnostic-useful difference: in my case, only some tool calls hang — others succeed. That narrows the failure from "client never dispatches ANY tool execution" toward "client fails to dispatch specific tool-call shapes", which may help isolate the root cause in the UI state machine.

Setup

• MCP server: FastMCP 1.26+, stateless_http=True, json_response=True, Streamable HTTP at /api/mcp on Vercel
• Tool: search_knowledge with a scope: Literal[...] parameter that maps server-side to different entity-type arrays
• Clients tested: Claude.ai web UI (hangs), Claude Code MCP (works), direct JSON-RPC POST with Bearer token (works)

Failure-mode summary

Tool call args	Claude.ai web UI	Claude Code MCP	Direct POST
scope='expert' + query	✅ works in <1s	✅ ~1s	✅ 0.73s
scope='notes'	✅ works	✅ works	✅ works
scope='subscriptions' (returns 0 rows — expected for my data state)	✅ works	✅ works	✅ works
scope='articles'	❌ hangs ~300s	✅ ~1s (5 results)	✅ 0.63–0.78s (5 results)

The only structural difference server-side between scope='expert' and scope='articles' is the length of the entity-types array the scope maps to internally (1-element vs 2-element) — but the client never sees entity_types, only the scope string. I verified response shapes are byte-identical at ~4450 bytes (same Content-Type: application/json) with raw curl across the Accept negotiation matrix.

Browser DevTools console during the hang

This is probably the highest-signal artifact for upstream isolation:

index-D72Sf481.js:2 [COMPLETION] Starting completion request (attempt 1, mode=legacy)
index-D72Sf481.js:2 [MCP] tool_approval_gate {toolId: 'toolu_01GVaFuBi4SGzwwR64XJ7xtf', toolName: 'jonmick-ai:search_knowledge', approvalRequired: false, hasBufferedInput: false}
[... hundreds of lines of React render cascade: yl → ac → tc → ac → tc → ac → tc → ... ]
index-D72Sf481.js:2 [MCP] tool_approval_gate {toolId: 'toolu_01GVaFuBi4SGzwwR64XJ7xtf', toolName: 'jonmick-ai:search_knowledge', approvalRequired: false, hasBufferedInput: true}
[... more render cascade ...]

The same toolId fires tool_approval_gate twice — once with hasBufferedInput: false, once with hasBufferedInput: true — with a massive React commitRoot / recursivelyTraverseMutationEffects cascade between them. The POST is never dispatched to the MCP server: zero POST /api/mcp entries in my Vercel logs during the hang windows, only the long-lived SSE GET /api/mcp streams hitting Vercel's 300s function timeout.

Consistent with the signature in anthropics/claude-code#32246 ([RenderLoopDetector] RENDER LOOP) and anthropics/claude-code#4895 (infinite React render loop from API state). The architectural cause looks adjacent to modelcontextprotocol/modelcontextprotocol#1716 (separate discovery/execution code paths).

Hypothesis (speculative)

The tool_approval_gate state machine enters a feedback loop when evaluating hasBufferedInput for certain argument shapes, triggering re-renders that re-fire the gate. Whether the discriminator is the literal scope string "articles" or something derived from the arguments (multi-element array in derived state, particular token in the argument JSON) would distinguish client planner issues from rendering issues. Happy to run targeted experiments if it would help — e.g., I can alias the scope to a different string and re-test to isolate literal-string vs. argument-shape triggers.

Workaround applied on our side

Shipped a docstring warning on the affected tool directing Claude.ai users to an equivalent alternative (scope='expert' in our case, since the additional entity types in scope='articles' that aren't yet populated produce the same result set today). Server-side code is unchanged — when Anthropic patches this, our code instantly works without reversion.

Related server-side investigation — for calibration with other reports

• 3-model AI consensus (Gemini 3.1 Pro / GPT-5.4 / GPT-5.3-codex) unanimously attributed to client
• Raw curl transport matrix across Accept: application/json, Accept: text/event-stream, and dual negotiation — server always returns Content-Type: application/json body (per json_response=True), same timing/size for affected and unaffected scopes
• Direct Supabase RPC (bypassing MCP) returns the same payload in <2s
• 30 unit tests pin scope routing + response schema (all green; 992 total project tests pass)

Reproducible on demand in a fresh Claude.ai conversation. Can share additional traces (full DevTools network waterfall, curl traces, browser console) if they'd help.