Every tool was deferred to tool search, with none directly callable

The symptom

A request configured with tool search — the mechanism that lets Claude discover and load tool definitions on demand instead of receiving every schema up front — ends up slower and clumsier on the tools it uses constantly than the setup it replaced, because every single tool in the request was deferred to search, including the ones nearly every turn needs.

What tool search is actually for

Tool search earns its keep when a request has a large tool surface and only needs a small slice of it on any given turn — a big internal API surface, dozens of MCP-connected systems, a toolkit built for a general-purpose agent rather than one narrow task. Deferring all of that to on-demand discovery avoids paying the cost of sending every schema on every request when most of them go unused most of the time. That's a real win for a large, sparse tool surface.

Why deferring everything is the wrong default

The mistake this error catches is treating tool search as an all-or-nothing setting rather than a per-tool decision. A tool your task calls on nearly every turn — reading a file, running a command, whatever sits at the core of the workflow — pays a discovery step before it can be used at all if it's deferred to search alongside everything else, adding a round trip that a directly declared tool never needed. Deferring literally every tool, including the ones used constantly, turns a mechanism built to save overhead into one that adds it.

The fix

Split your tool list: keep the small set of tools your task uses on nearly every turn declared directly, and defer to search only the long tail that's genuinely used occasionally. That split is the entire point of the mechanism — it isn't meant to replace direct tool declarations, only to avoid paying their cost for tools that rarely get called. See building a tool-search workflow for how to draw that line for your specific tool surface rather than guessing at it.