[BUG] ToolSearch returns incomplete MCP tool list on first query, causing false 'tools removed' claims

Bug: ToolSearch returns incomplete MCP tool list on first query, leading the assistant to falsely report tools as "removed"

Summary

ToolSearch (the tool used to look up deferred/unloaded tools, including MCP-server tools) returned only 10 of 20 available tools from an MCP server on its first query in a session. The assistant took the incomplete result at face value and told the user that half the tools — an entire category — had been removed in a version upgrade. A second, more specific set of calls against the MCP server's own introspection tools (get_server_info, list_tool_categories) revealed all 20 tools were present and unchanged.

The core problem isn't just that the first search was incomplete — it's that ToolSearch gave no signal of incompleteness, so the assistant treated a partial index as ground truth and fabricated a regression that never happened.

Repro

MCP server: a Keepit MCP server ("KART") exposing 20 tools across 7 categories (restores, billing-management, job-management, connector-management, reporting, general, account-management).

1. Fresh session, user asks: list the keepit mcp tools
2. Assistant calls ToolSearch (twice, per the transcript's "Searched available tools" entries) to enumerate available MCP tools.
3. Result: only 10 KART tools surfaced — the entire restores category (6 tools: restore_m365_mailbox, restore_m365_onedrive_data, restore_entra_user, restore_entra_group, restore_sharepoint_site, restore_sharepoint_item) was missing, along with get_resource_history, get_job_status, schedule_backup_job, and manage_api_tokens.
4. Assistant response includes: "Worth noting: KART lost some tools compared to 0.5.x (the restore tools like restore_m365_mailbox, restore_entra_user, etc. aren't showing in the search results). That's either a KART 0.6.x reorganization or they're in a different category."
5. User asks the assistant to run get_server_info and list_tool_categories (tools exposed directly by the KART server itself).
6. Those calls return the true, complete picture: 20 tools across 7 categories, including all 6 restore tools, unchanged from before.

Expected behavior

One of:

• ToolSearch should return the complete tool list for a connected MCP server on the first query, or
• If the index is cold/partial, the tool result should indicate that the listing may be incomplete, so the assistant doesn't present a partial result as authoritative — especially for a query like "list the tools," which implies exhaustiveness.

Actual behavior

ToolSearch silently returned a subset (10/20) of the true tool list with no indication of truncation. The assistant then presented this partial result as a complete, confident claim that specific named tools (an entire "restores" category) had been removed from the server — a fabricated regression.

Impact

This is a correctness/trust issue: the assistant asserted a false technical fact (tools removed / possible version regression) based on tooling behavior it had no way to detect as unreliable. In a real incident-response or on-call context, this kind of false "you lost functionality" claim could send someone down the wrong path before they think to double check via the server's own introspection tools.

Environment

• Claude Code CLI
• MCP server with 20 tools across 7 categories (large tool count, several tools deferred and only discoverable via ToolSearch)