claude-code - 💡(How to fix) Fix ToolSearch does not index tools from claude.ai-hosted MCP servers (visible in /mcp, invisible to deferred-tool search)

Title: ToolSearch does not index tools from claude.ai-hosted MCP servers (visible in /mcp, invisible to deferred-tool search)

Body:

Summary

On Claude Code v2.1.114 (Windows 11, Git Bash), Claude.ai-hosted MCP servers added at claude.ai/settings/connectors are fully loaded into the session — /mcp lists them with their tool counts and claude mcp list shows them as ✓ Connected — but the ToolSearch deferred-tool discovery mechanism does NOT include them in its index. Any ToolSearch query that should match a claude.ai MCP tool returns zero results, which means autonomous / agentic flows that rely on ToolSearch to discover and load tool schemas on demand effectively cannot see these servers at all.

Tools from local .mcp.json servers and plugin-bundled MCPs ARE indexed by ToolSearch normally, so the deferred-tool infrastructure itself is healthy — the gap is specific to the claude.ai-hosted transport.

Per the official docs (§ "Use MCP servers from Claude.ai"):

If you've logged into Claude Code with a Claude.ai account, MCP servers you've added in Claude.ai are automatically available in Claude Code.

This is not what is observed.

Environment

• Claude Code: 2.1.114 (install method: global npm)
• OS: Windows 11 Pro 10.0.26200
• Shell: Git Bash (bash)
• ENABLE_CLAUDEAI_MCP_SERVERS: unset (default=enabled)
• numStartups: 16 since v2.1.104
• GrowthBook flags (from ~/.claude.json::cachedGrowthBookFeatures):
  • tengu_claudeai_mcp_connectors: true
  • tengu_mcp_tool_search: true
  • tengu_mcp_elicitation: true
  • tengu_mcp_retry_failed_remote: false ← relevant; no retry on initial tool.list() failure

Reproduction

1. Log in to Claude Code with a claude.ai account.
2. At claude.ai/settings/connectors, add and authenticate a hosted MCP server (e.g., Context7, Figma, Airtable).
3. Start a fresh Claude Code session: claude
4. Run claude mcp list — the server shows ✓ Connected.
5. Inside the session, run /mcp — the server appears in the list with its tool count populated.
6. From the same session, query ToolSearch for any tool name you'd expect from that server.

Expected

ToolSearch returns matching tool schemas for claude.ai-hosted MCP tools the same way it does for local .mcp.json and plugin MCP tools. This is what the docs imply when they say servers are "automatically available in Claude Code."

Actual

• /mcp shows the server loaded and reports tool counts — confirming tools were fetched during session init.
• ToolSearch does NOT index those tools. Concrete checks that returned empty in a session where /mcp showed these servers loaded:
  • ToolSearch query="+claude_ai" → No matching deferred tools found
  • ToolSearch query="figma component" → returns only unrelated local tools
  • ToolSearch query="airtable base" → returns no Airtable tools
• Tools from local .mcp.json Context7 (cmd /c npx -y @upstash/context7-mcp@latest) ARE indexed by ToolSearch under mcp__context7__*. Same vendor, different transport path — only the hosted HTTP MCP is affected.

So the bug isn't "tools aren't fetched." The bug is "tools are fetched but never registered with the ToolSearch deferred-tool index." This matters because autonomous agent flows rely on ToolSearch to discover tools on demand without paying for every schema up front; from an agent's perspective, claude.ai MCPs effectively don't exist.

Workaround

Install the stdio/local equivalent of any needed connector via .mcp.json (for Context7, that's npx -y @upstash/context7-mcp@latest). Tools then expose correctly under mcp__<name>__*.

Suggested investigation

1. The session loader IS fetching claude.ai MCP tool schemas (proven by /mcp showing tool counts). Check where those fetched schemas are kept and why they are not registered with the ToolSearch deferred-tool index.
2. Compare the registration path for local .mcp.json tools vs claude.ai-hosted tools — the former reach ToolSearch, the latter do not.
3. Separately, claude mcp get does not honor the claude.ai server store (see below).

Secondary, related anomaly

claude mcp get "<claude.ai server name>" returns No MCP server found even though the same name appears in the "Configured servers" list printed by the same command on error:

$ claude mcp get "claude.ai Context7"
No MCP server found with name: "claude.ai Context7". Configured servers: agent-visualizer, ..., claude.ai Context7, ...

So the claude.ai-hosted entries are visible to mcp list but not introspectable by mcp get. This reinforces the theory that claude.ai MCPs live in a separate internal store that several CLI surfaces (mcp get, ToolSearch) don't consult.

Happy to supply redacted ~/.claude.json, claude --debug logs, or a /mcp screenshot from a live session on request.