Skip to main content
Tool search enables your agent to work with hundreds or thousands of tools by dynamically discovering and loading them on demand. Instead of loading all tool definitions into the context window upfront, the agent searches your tool catalog and loads only the tools it needs. This approach solves two challenges as tool libraries scale:
  • Context efficiency: Tool definitions can consume large portions of the context window (50 tools can use 10-20K tokens), leaving less room for actual work.
  • Tool selection accuracy: Tool selection accuracy degrades with more than 30-50 tools loaded at once.

How tool search works

Tool search is on by default, with the exceptions listed in Configure tool search. When it is active, tool definitions are withheld from the context window. The agent receives a summary of available tools and searches for relevant ones when the task requires a capability not already loaded. Up to five of the most relevant tools are loaded into context by default, where they stay available for subsequent turns. If the conversation is long enough that the SDK compacts earlier messages to free space, previously discovered tools may be removed, and the agent searches again as needed. Tool search adds one extra round-trip the first time Claude discovers a tool (the search step), but for large tool sets this is offset by smaller context on every turn. With fewer than ~10 tools whose definitions fit comfortably in the context window, loading everything upfront is typically faster. For details on the underlying API mechanism, see Tool search in the API.
Tool search isn’t supported on Microsoft Foundry deployments hosted on Azure, which reject it server-side: the SDK detects the rejection and loads tool definitions upfront for that deployment instead. ENABLE_TOOL_SEARCH can’t override this, since the rejection comes from the deployment itself.
Tool search is on by default. For models on the SDK’s unsupported-model list, the SDK loads tool definitions upfront instead, and no ENABLE_TOOL_SEARCH value overrides that. On Google Cloud’s Agent Platform, the SDK decides by model generation:
  • Claude Opus 4.5, Sonnet 4.5, Haiku 4.5, and later: tool search is on by default.
  • Earlier Agent Platform models: the SDK loads tool definitions upfront, because their serving stacks reject the required beta header. ENABLE_TOOL_SEARCH can’t override this.
Before Claude Code v2.1.221, the SDK disabled tool search for all models on Google Cloud’s Agent Platform unless you set ENABLE_TOOL_SEARCH. The SDK also disables tool search when ANTHROPIC_BASE_URL points to a non-first-party host, since most proxies don’t forward tool_reference blocks. You can override that default with the ENABLE_TOOL_SEARCH environment variable: Setting CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS keeps tool search off. You can’t override it by setting ENABLE_TOOL_SEARCH yourself. Your organization can keep tool search on through managed settings, on Claude Code v2.1.227 or later. Disable pre-release capabilities covers where the override applies and what the variable strips. Tool search applies to all registered tools, whether they come from remote MCP servers or custom SDK MCP servers. When you use auto, the SDK counts every definition that tool search can defer toward one combined threshold: each MCP tool that isn’t marked alwaysLoad, from any server, plus the built-in tools that load on demand. The SDK always loads core built-in tools such as Bash, Read, and Edit upfront and doesn’t count them toward the threshold. Set the value in the env option on query(). In TypeScript, env replaces the subprocess environment, so spread ...process.env to keep inherited variables. In Python, env is merged on top of the inherited environment. This example connects to a remote MCP server that exposes many tools, pre-approves all of them with a wildcard, and uses auto:5 so tool search activates when the definitions it can defer reach 5% of the context window: