[BUG] Model searches connector directory, then reports it as having searched the loaded tool index

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [ ] I am using the latest version of Claude Code — the failure is in a cloud routine session, so the local CLI version (2.1.41) is not the executing version.

What's Wrong?

When connector tools are unavailable, the model searches the connector directory (the installable-connector registry) and then reports the outcome as though it had searched its loaded tool index.

It stated it had tried "direct tool-name guesses (list_issues, get_issue, create_comment, update_issue), keyword searches, and generic terms" and that none surfaced any tool — but the visible tool calls show only directory searches.

Impact

The self-report is confident and wrong, and it misdirects debugging. It sent me through connector settings, re-authentication, and network access configuration before the actual cause (#86908) was found. It also surfaced a "Connect Google Drive" suggestion in response to a request for a local filesystem MCP server, and offered a connect card for a mail provider unrelated to the mail service actually being asked about.

What Should Happen?

Either query the loaded tool index, or accurately describe which index was searched.

The reach for the directory is explainable — the misreport is the bug

Worth separating two things that look like one failure.

Reaching for the directory is close to rational. #79319 documents the same end-state from an unrelated cause, and its run output describes it precisely: the session was left with "only meta-tools like ListConnectors/SearchMcpRegistry." In the broken state, the registry meta-tools are essentially the only tools present. The model reaching for them is not a wild misfire — it is using what it has.

The misreport is the actual defect. Having searched the directory, it described that as having searched its loaded tool index, and asserted a negative result about tools it never queried. That is the part that cost me hours of misdirected debugging, and it is a tighter claim than "the model searched the wrong index."

A likely contributing cause: connector tools carry no human-readable name

Connector tools are namespaced by an opaque server UUID:

mcp__<server-uuid>__list_issues

The connector's name appears only in tool descriptions, never in tool names. So a model reasoning by name about "the Linear tools" finds nothing that looks like Linear — while the connector directory does match on that word.

This also explains the otherwise-impossible claim in the self-report. "Direct tool-name guesses" cannot work under deferred loading, since an unloaded tool can't be invoked — but a direct-selection search by name is legal, e.g. select:list_issues, and it fails, because the real name is mcp__<server-uuid>__list_issues. So the model plausibly did attempt name-based lookups, they failed for the naming reason above, and it then narrated them as tool-index searches.

If that is what happened, this is less a reasoning failure than a naming failure surfacing as an inaccurate self-report. Worth confirming against the actual call log before treating it as a model-behavior bug.

Asks

1. Alias connector server namespaces to their display name (mcp__linear__list_issues) so name-based lookup works and descriptions aren't the only place the connector is identifiable.
2. Disambiguate the connector-directory search from the loaded-tool-index search in naming or description — under failure conditions they are easy to confuse, and the directory is what survives.
3. When the loaded index is empty, say so directly rather than reporting a searched-and-found-nothing result.

Related: #86908 — resumed cloud routine sessions losing MCP tool registration, which is the condition that produced this.