The new `tool_search` mechanism is interesting — it's Anthropic telling Claude "don't claim a tool doesn't exist until you've actually asked the harness about it". The old failure mode was Claude saying "I don't have web access" when the harness DID have web search but it just wasn't in the current tool list. tool_search fixes that confabulation by giving Claude an explicit "check for deferred tools" step.

The wider implication: this is Anthropic admitting the tool-list-in-the-system-prompt model doesn't scale. Once you have dozens of specialised tools (remote MCPs, custom agents, per-workspace plugins), you can't fit them all into the context window's tool slots at initialization. You need a searchable tool registry and a mechanism for the model to pull tools on demand.

MCP's tools/list pagination (added in the 2025-06-18 spec) is the protocol-level version of the same idea. Clients that actually use paginated tool loading + dynamic tool fetching haven't taken off yet — most still flatten all tools into the initial handshake. The tool_search system-prompt entry is Anthropic's nudge for the model itself to handle deferred tools smarter.

Is this really a common problem? This stuff is way above me, but my toy agent seems to have bypassed this as a problem.

I did this in mine by only really having a few relevant tool functions in the prompt, ever. Search for a Tool Function, Execute A Tool Function, Request Authoring of a Tool Function, Request an Update to a Tool Function, Check Status of an Authoring Request.

It doesn't have to "remember" much. Any other functions are ones it already searched for and found in the tool service.

When it needs a tool it reliably searches (just natural language) against the vector db catalog of functions for a good match. If it doesn't have one, it requests one. The authoring pipeline does its thing, and eventually it has a new function to use.