Your Agent Pays a Tax on Every Tool It Never Calls Microsoft Foundry introduced Tool Search at Build 2026 to address the token cost and accuracy degradation caused by large tool catalogs in AI agents. The feature uses meta-tools to retrieve a small ranked set of candidates instead of sending the full schema for every tool on each turn, with pinning for frequently used tools to minimize latency. The approach generalizes to any MCP-heavy agent and is most beneficial for catalogs exceeding roughly thirty tools. Most agents are billed for tools they don't use. Not once — on every single turn. The mechanics are simple enough that it's easy to miss. When you give a model a set of tools, the full JSON schema for every tool goes into the request. Names, descriptions, parameter types, enum values, nested objects, the lot. The model reads all of it, picks one, and calls it. Next turn, the whole catalog goes over the wire again, because the API is stateless and the tool list is part of the request. With eight tools this is invisible. With two hundred it dominates your input token bill, crowds out the context you actually care about, and — the part that hurts more — measurably degrades tool selection accuracy. Microsoft Foundry shipped Tool Search at Build 2026 to address exactly this. It's worth understanding, and worth understanding beyond Foundry: the same failure mode shows up in any MCP-heavy agent, and the mitigation generalizes. A moderately detailed tool schema runs 150–400 tokens once you account for parameter descriptions that are good enough for the model to use correctly. Cheap schemas produce bad tool calls, so teams write generous ones, which is the right call and also the expensive one. Multiply that across a catalog and across turns: tokens per turn = base prompt + conversation history + n tools × avg schema tokens tokens per task = tokens per turn × turns A twelve-turn task against a 200-tool catalog at 250 tokens per schema spends roughly 600,000 input tokens on tool definitions alone. The conversation itself might be 20,000. You are paying, overwhelmingly, to re-read a catalog the model already decided against eleven times. The token cost is the visible half. The invisible half is worse. As catalogs grow, they accumulate near-duplicates — get customer , get customer profile , fetch customer record , lookup account by customer — often from different teams, different MCP servers, different eras of the codebase. Selection accuracy falls not because the model got dumber but because you handed it a genuinely ambiguous menu. Instead of a flat list, Foundry exposes two meta-tools: tool search and call tool . The agent describes what it's trying to do, gets back a small ranked set of candidates, and invokes one. The trade is a retrieval round-trip in exchange for not shipping the catalog. Above roughly thirty tools that trade is strongly favourable. Below it, it usually isn't — which is the first thing to be honest about before adopting it. Tool Search isn't the only answer, and it isn't always the right one. | Strategy | Token cost per turn | Selection accuracy at scale | Added latency | Operational cost | |---|---|---|---|---| | Flat tool list | Linear in catalog size | Degrades sharply past ~50 tools | None | Trivial | | Hand-partitioned catalogs per task type | Low within a partition | Good, if routing is correct | None | High — routing rules rot as tools change | | Multi-agent split by domain | Low per sub-agent | Good within domains, poor across them | Handoff overhead | High — orchestration and shared state | | Tool Search | Roughly flat regardless of catalog size | Depends on retrieval quality | One extra round trip | Low — index is maintained for you | | Tool Search plus pinning | Flat, plus pinned schemas | Best available: hot path guaranteed, tail retrieved | Only on the tail | Low | Pinning is the part people skip and shouldn't. Foundry lets you pin critical tools so they bypass the search round-trip entirely, add context describing how your team actually thinks about a tool, and auto-pin frequently used ones. In practice a handful of tools account for most calls; pin those, retrieve everything else, and you get flat token cost without paying retrieval latency on the common path. Two commands scaffold a hosted agent with a toolbox attached. mkdir my-toolbox-agent && cd my-toolbox-agent azd ai agent init \ -m "https://github.com/microsoft-foundry/foundry-samples/blob/main/samples/python/hosted-agents/agent-framework/responses/04-foundry-toolbox/agent.manifest.yaml" \ --src src/toolbox-agent Then create the toolbox from the sample's descriptor: azd ai toolbox create my-toolbox --from-file ./src/toolbox-agent/toolbox.yaml That prints a versioned MCP endpoint, which is what your agent binds to: https://