[BUG] claude.ai web: custom connector tools shown in Settings but not injected into the in-conversation tool registry (model even calls a tool removed from the server)

[Movm]

Summary

On claude.ai (web), a remote Streamable-HTTP MCP custom connector reaches a fully healthy state — connected, resources readable, and the connector Settings page lists all its tools ("Read-only tools: 5", correct titles, "Tool list updated"). But in an actual chat the model cannot find or call these tools: tool_search returns only a different connector's tools, and direct invocation returns "Tool not found". Discovery (Settings) and execution (chat) appear to be desynced.

Strongest signal: the model calls a tool that no longer exists on the server

Server A's tools changed weeks ago — an old gruenerator_ask was removed; the server now exposes gruenerator_search, gruenerator_get_filters, gruenerator_cache_stats, gruenerator_examples_search, get_client_config. The Settings page shows the current tools. Yet in chat the model still tries to call gruenerator_ask — a tool the server hasn't advertised in weeks. A model can only know that name from a stale cached tool index → the in-conversation registry isn't re-synced with the server's current tools/list, even though the Settings/discovery path is.

Environment

• Surface: claude.ai web app (Settings → Connectors → Custom Connector)
• Server A (affected): remote MCP, Streamable HTTP, stateless, JSON responses (enableJsonResponse), MCP TypeScript SDK 1.29, endpoint https://mcp.gruenerator.eu/mcp
• Server B (working sibling): a second custom MCP on the same account (also SDK 1.29, Streamable HTTP, JSON) that works in chat — its tools DO appear in tool_search.

Symptom (precise)

1. Connector status: Connected ✅
2. Resources: list_mcp_resources / read_resource_link work ✅
3. Connector Settings UI: lists the current 5 tools, "Tool list updated" ✅
4. In-conversation tool_search: returns ONLY Server B's tools; never Server A's ❌
5. Direct invocation in chat: "Tool not found" ❌
6. The model even attempts gruenerator_ask — a tool removed from Server A weeks ago ❌

Server is provably correct

Verified via curl:

• initialize → capabilities { tools, resources, prompts }, no Mcp-Session-Id header (stateless)
• tools/list → the current 5 tools, valid JSON-RPC 2.0, Content-Type: application/json
• tools/call → succeeds

The same server also works fine as a Claude Code MCP server (tools listed and callable). A server-side /health/mcp endpoint reports claudeAiReady: true, jsonResponseMode: true, stateless: true.

(Happy to share full initialize + tools/list curl transcripts on request.)

Why this looks like a client/backend bug, not a server bug

• Server passes curl + Claude Code end-to-end.
• Discovery clearly reaches Server A (Settings lists the exact current tools with correct titles).
• Yet the execution / tool_search path behaves as if Server A contributes zero tools, and even references a removed tool — i.e. it is serving a stale index.
• A sibling connector on the same account populates tool_search normally.
• → discovery (Settings) and execution (chat tool registry) appear to use separate, independently-cached code paths.

Discriminators / questions

• Is per-conversation tool indexing capped to / selecting only a subset of connected connectors?
• Does tool_search index only one ("winning") connector and miss the others?
• Is the in-conversation tool registry cached from an earlier connection and never re-synced with the server's current tools/list (which would explain the removed-tool reference)?
• Is a stateless + JSON-response Streamable-HTTP connector treated differently at the execution-indexing stage than at Settings-discovery?

Repro

1. Add two remote Streamable-HTTP MCP custom connectors (stateless, JSON) on one account.
2. Confirm both appear "Connected" and both list their tools in Settings.
3. In a chat, use tool_search — observe only one connector's tools are available; the other's are never surfaced, and direct calls to them fail.

Related

• Claude.ai Web Connector — Tool Discovery Succeeds but CallToolRequest Never Sent #123 (web: discovery succeeds, CallToolRequest never sent — separate discovery/exec paths)
• Cowork: connected local MCP server's tools missing from tool-discovery on first turn (search-before-connect race); agent then wrongly reports the connector 'not installed' #383 (Cowork first-turn tool-discovery race)
• Bug Report: Claude.ai Custom Connectors - Tools Not Visible Despite Successful Connection modelcontextprotocol/modelcontextprotocol#1675 (connected, tools not visible; labeled "external")
• [BUG] Claude Code Web interactive sessions lost all claude.ai MCP connectors ~April 23, 2026 while routines retain them claude-code#53489, #57033 (tool_search indexes only one connected MCP server)

Impact

The connector is unusable in chat despite a fully healthy handshake and a correct, curl-verified, Claude-Code-compatible server.

[jfahrni]

Independent reproduction on a completely different server — strong corroboration.

Setup: a private remote Streamable-HTTP MCP connector (mcp-handler 1.1.0, OAuth DCR + authorization_code/PKCE), 13 read-only tools. Same symptom as this issue, verified from the server side.

What my server logs prove (times UTC):

• Claude.ai's infra fetches tools/list and gets HTTP 200 with the FULL payload, repeatedly (e.g. 07:55:36, 07:59:21, 07:59:27 — all 200, ~16ms), even tools/call → 200. Discovery + execution both succeed at the protocol level.
• Yet in-chat, tool_search returns "No matching tools found", and only a different connector's tools ever surface — exactly as described here ("returns only a different connector's tools").
• Same account, same connector works perfectly in Claude Code (different client surface). Fails identically on claude.ai Web AND Desktop.

Ruled out from the server side (all with logs):

• Not auth/token: initialize/tools/list/tools/call all 200.
• Not payload shape: identical mcp-handler stack to a second connector on the same account that DOES index fine.
• Not OAuth token churn: I implemented refresh tokens and fully cleared all server-side OAuth state, then reconnected fresh — tools/list still returns 200 and still isn't injected into the chat registry.
• Reconnect / delete+recreate / a second connector on an alternate hostname / full re-authorization — none fix it.

So the in-conversation tool registry is not being populated from a connector whose tools/list the platform successfully fetches. This has been intermittent for ~6 weeks for me. Happy to provide timestamped logs for a given request window.

[jfahrni]

Follow-up — possible clue/workaround: non-ASCII characters in the connector's display name.

My connector was named "Migräne Tagebuch" (note the umlaut "ä" and the space). After renaming it to pure ASCII without a space — "MigraeneTagebuch" — its tools started appearing in tool_search in a fresh chat, where before they never did.

Why this might matter: the client labels tools in tool_search by the connector's display name as a namespace prefix — I see MigraeneTagebuch:get_overview, exactly as another (unrelated, pure-ASCII-named) connector on the same account shows up as OtherConnector:…. If a non-ASCII character (or the space) breaks the registry key / search index for that connector, its tools would silently fail to register — while the plainly-named, pure-ASCII connector's tools surface normally. That lines up with this issue's "tool_search returns only a different connector's tools."

This looks like the same root cause as #580 — there the special character was a dot in the name (Windsor.ai); here it's an umlaut and a space. Same class: a special character in the connector's display name breaking tool discovery, and renaming to a clean ASCII name is the workaround.

Caveat — I'm not presenting this as the fix: the symptom has been intermittent for me for weeks, so a single success after renaming isn't conclusive. But renaming to an ASCII-only connector name (no umlauts/accents, no spaces/special characters) is cheap to try, and if it reliably helps for others too, it points at connector-name sanitization in the tool-registry keying as a likely culprit.

[Movm]

Confirmed on my end too — this was exactly my issue. My connector was named Grünerator (with the umlaut ü). Renaming it to pure ASCII Gruenerator (no ü, no spaces/special chars) made the tools show up in tool_search and the chat registry, in a fresh conversation, where before they never did.

This matches @jfahrni's finding above (umlaut + space in the display name) and #580 (a dot in Windsor.ai) — same class: a non-ASCII/special character in the connector display name breaks the in-conversation tool-index key, while the server (tools/list) is verified healthy the whole time. No server-side change was needed; the fix is purely the connector name in the claude.ai UI.

[localden]

Duplicate of #580. We'll be consolidating the discussion there.