A team's agent has grown to use MCP servers for GitHub, Slack, Sentry, Grafana, and Splunk, and now has well over a hundred available tool definitions. They notice two problems: the tool definitions alone are consuming tens of thousands of tokens of context before the agent does any actual work, and the agent has started picking the wrong tool more often than it used to. Enabling Claude's tool search tool and marking most of those tool definitions with `defer_loading: true` is meant to address this by doing what?
- Deleting the unused tool definitions from the request entirely, so the calling application no longer needs to send their schemas to the API at all on any request
- Keeping only a small non-deferred set of tools (and the tool search tool itself) loaded into context up front, while the rest stay out of context until Claude searches the catalog by name, description, or argument details and the API expands only the matching tools it finds -- cutting the upfront token cost and keeping tool-selection accuracy high even as the total catalog grows into the hundreds or thousands
- Forcing Claude to call every deferred tool once, in sequence, at the start of each conversation, so that all of them become available for the rest of the session
- Merging all the deferred tools from every MCP server into a single combined tool with one shared schema, so there is only ever one tool definition to select from
Why B? And why not the others?
Correct answer: B. Keeping only a small non-deferred set of tools (and the tool search tool itself) loaded into context up front, while the rest stay out of context until Claude searches the catalog by name, description, or argument details and the API expands only the matching tools it finds -- cutting the upfront token cost and keeping tool-selection accuracy high even as the total catalog grows into the hundreds or thousands
Marking most tool definitions with `defer_loading: true` keeps only a small non-deferred set of tools, plus the tool search tool itself, loaded into context up front; the rest stay out of context until Claude searches the catalog by tool names, descriptions, and argument details, at which point the API expands only the matching tools it finds into full definitions. This directly addresses both symptoms: it cuts the large upfront token cost that a typical multiserver setup otherwise consumes before any real work happens, and it keeps tool-selection accuracy high even as the catalog grows into the hundreds or thousands, since Claude is only ever choosing among the small set of tools its search actually surfaced. The option describing deletion of the unused definitions is wrong because every tool's full definition still has to be sent in the `tools` array on every request regardless of `defer_loading` -- the API needs them server-side to run the search and expand matches -- deferred tools are kept out of context, not out of the request. The option describing forced sequential calling of every deferred tool at session start is wrong because deferred tools load only when Claude's search discovers them as relevant to the current task, not automatically or unconditionally at the start of a conversation. The option describing merging every deferred tool into one shared schema is wrong because each tool keeps its own distinct name, description, and schema throughout; tool search discovers and expands individual matching tools rather than combining them into a single tool.
Source: Anthropic, 'Tool search tool' (platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool) -- 'Instead of loading all tool definitions into the context window up front, Claude searches your tool catalog... and loads only the tools it needs,' noting a typical multiserver setup can consume roughly 55k tokens up front, that tool search 'typically reduces this by over 85 percent,' and that tool-selection accuracy 'degrades once you exceed 30-50 available tools.'