[BUG] ToolSearch loads MCP tools with names over 64 chars, next request 400s "Tool reference ... not found in available tools" and the session is permanently dead

Summary

When ToolSearch loads an MCP tool whose full name (mcp__<server>__<tool>) is longer than 64 characters, the very next API request fails with:

API Error: 400 Tool reference '<tool name>' not found in available tools

The tool_reference stays in the conversation history, so every following turn fails the same way. The session cannot be continued; only rewind or a new session recovers it.

Same symptom as #22336 (canonical), #22455, #21846, #19882 and #18015, all closed/locked, so filing new. It still reproduces on current builds.

Reproduction (no auth needed)

Uses the public hosted Firecrawl MCP endpoint with a long server name so the full tool name is 68 chars.

.mcp.json:

{ "mcpServers": { "firecrawl-longname-padding-control-xxxxxxxxxx": { "type": "http", "url": "https://mcp.firecrawl.dev/v2/mcp" } } }

.claude/settings.json: { "enabledMcpjsonServers": ["firecrawl-longname-padding-control-xxxxxxxxxx"] }

claude -p "Call the ToolSearch tool exactly once with query 'select:mcp__firecrawl-longname-padding-control-xxxxxxxxxx__firecrawl_scrape' and max_results 1. Do not call the loaded tool. Then reply with the single word DONE." --output-format json

Result: "is_error": true, API Error: 400 Tool reference 'mcp__firecrawl-longname-padding-control-xxxxxxxxxx__firecrawl_scrape' not found in available tools.

Same setup with a shorter server name (full tool name 59 chars) returns DONE.

Boundary and versions (all tested on the same day)

| Full tool name length | 2.1.246 | 2.1.281 | 2.1.282 | 2.1.283 |
|---|---|---|---|---|
| 59 (non-plugin server) | OK | | | OK |
| 64 (plugin server) | | | | OK |
| 65 (plugin server) | 400 | 400 | 400 | 400 |
| 68 (non-plugin server) | 400 | | | 400 |
| 72 (plugin server) | | | | 400 |

• Cutoff is exactly 64/65 characters, for plugin and non-plugin MCP servers alike.
• In late August 2026, 2.1.246 loaded 65-68 char tool references without error, but those were claude.ai connector tools (UUID-named servers), which I could not retest today. Local/plugin MCP servers fail on every build tested, so the version table is not evidence of a client-side regression.
• Debug log shows ToolSearchTool: selected <name>, then Dynamic tool loading: 1/N deferred tools included, then the 400. So the client believes the tool is included, but the reference is not matched.
• Docs state tool names may be up to 128 characters, so a 65-128 char MCP tool name is valid, yet it cannot be loaded via ToolSearch.

Real-world trigger

Plugin-provided MCP servers get the prefix mcp__plugin_<plugin>_<server>__, which pushes many tools of large servers (e.g. the Meta Ads MCP at https://mcp.facebook.com/ads) past 64. That server's instructions tell the model to load suggested tools via tool discovery, so sessions die "randomly" whenever a long-named tool is suggested.

Expected

Either the API accepts tool_reference names up to the documented tool-name limit, or ToolSearch never returns tools it cannot reference (and warns about them), so the session is not bricked.

Workarounds found

• Declare the same MCP endpoint in project .mcp.json under a short name; Claude Code suppresses the plugin duplicate and the names drop under 64.
• A PreToolUse hook on ToolSearch that denies select: queries naming tools over 64 chars prevents the session from dying (does not cover keyword searches).

Environment

• Claude Code native install, 2.1.283 (also reproduced with 2.1.246, 2.1.281, 2.1.282)
• Platform: Windows