Your production AI agent has too many tools (and the fix)

A production AI agent with too many tools costs more on every call and picks the wrong tool more often. Each tool definition sits in the prompt on every request, so a growing tool list quietly inflates token spend and pushes the model toward worse selections. Progressive disclosure fixes both problems: show the model a short index of tool names and one-line descriptions up front, and load the full definition only when it decides a tool is relevant. Context stays small, selection stays sharp, and cost stays flat as the agent gains capabilities.

This is the pattern behind the "agent skills" format that spread across the major model providers in the first half of 2026. The idea is older than the branding, and you can apply it to any agent you already run in production, no new framework required. Here is what tool sprawl actually costs, and how to claw both the money and the accuracy back.

The two hidden costs of a growing tool list

Most agents start with a handful of tools and grow by accretion. A support agent gets a refund tool, then an order-lookup tool, then a shipping tool, then someone wires in three MCP servers and suddenly the agent has forty tools. Nobody made a bad decision, but the bill and the error rate both crept up. Two mechanisms are at work.

Every tool definition is a tax on every call

Tool schemas live in the request as structured definitions: a name, a description, and a JSON schema for arguments. A single well-documented tool runs 150 to 400 tokens once you count the parameter descriptions the model needs to call it correctly. Forty of them is 8,000 to 12,000 tokens sent on every turn of every conversation, before the user has typed a word.

That payload is a prefix on each call, so a multi-turn session pays for it repeatedly. Prompt caching softens the blow when the tool block is stable, but it does not make the tokens free, and the moment you version a tool the cache entry churns. If you have not measured where your input tokens go, our note on how to control LLM input token cost from context is a good place to start before you optimize anything else.

More tools means worse tool selection

The second cost is quieter and more expensive. Every tool you add is another option the model has to reason over when it decides what to call. Below roughly ten tools, selection is reliable. As the menu grows past twenty or thirty, the model starts reaching for plausible-but-wrong tools, calling two tools where one would do, or hallucinating arguments because three similarly named tools blurred together in the context.

You see it as a rising rate of wrong-tool calls in your traces, and it is hard to catch without a real test set. We wrote separately about how to build an eval set from production failures, and tool-selection errors are exactly the kind of failure that belongs in it. The important point: adding a tool is not free even when the tool works perfectly. It taxes the selection accuracy of every other tool.

Progressive disclosure: load tools only when they are needed

Progressive disclosure inverts the default. Instead of putting every tool's full definition in front of the model at all times, you put a thin index there and defer the detail. It works in three tiers.

At startup, the model sees only a compact catalog: each tool or skill as a name and a one-line description, on the order of 20 to 40 tokens each. That is enough for the model to know a capability exists and roughly when to use it. When the model decides a specific capability is relevant to the task in front of it, the full instruction body and argument schema load into context, the part that runs a few hundred to a few thousand tokens. Finally, any bulky reference material, example payloads, or helper scripts load only at execution time, when the tool actually runs.

The effect on the numbers is direct. A forty-tool catalog that cost 10,000 tokens per call as full definitions collapses to a 1,000-token index, and the model pulls in the one or two full definitions it needs for the current step. Selection improves for the same reason cost drops: the model reasons over a short, high-signal menu instead of a wall of near-duplicate schemas. This is the same instinct behind good context engineering for production agents, spend the context budget on the smallest set of tokens that actually change the model's next decision.

A worked example: a 40-tool SaaS support agent

Take a B2B SaaS support agent, the kind Boundev ships for customers who want deflection without a worse experience. It grew to 40 tools across billing, provisioning, shipping, and a couple of internal MCP servers. Measured over a week of real traffic, the pattern was familiar: about 9,400 tokens of tool definitions on every call, and a wrong-tool-call rate near 14 percent on a 200-case regression set, most of it confusion between three billing tools with overlapping names.

The rebuild kept every tool but moved to progressive disclosure. The startup catalog dropped to roughly 900 tokens. A lightweight retrieval step matched the user's request against tool descriptions and surfaced the top few candidates, whose full schemas were loaded for that turn. On the same regression set, the wrong-tool rate fell to about 4 percent, and average input tokens per call dropped by more than 80 percent on multi-turn sessions. No model change, no prompt rewrite, just deciding what the model needed to see and when. Those are illustrative numbers from one build, not a benchmark, but the direction is consistent every time tool count is the bottleneck.

How to implement progressive disclosure without a new framework

You do not need to adopt a specific vendor's skills format to get most of the benefit. Three pieces are enough.

Build a two-tier tool registry

Split each tool's metadata into a summary (name plus a one-line description of when to use it) and a body (full description, argument schema, examples). Store both, but only the summaries go into the base system context. The body is fetched on demand. If your tools come from MCP servers, this is a good moment to revisit whether every server earns its place; our take on MCP versus plain function calling covers when a server is worth the overhead and when an inline function is simpler.

Add a retrieval or router step

Between the user's message and the agent's first action, insert a step that narrows the catalog to a handful of likely tools. Retrieval over the tool descriptions works well and is cheap. A small classification model works too. This is the same shape as model routing to cut AI costs: a fast, cheap decision up front that keeps the expensive call small and focused. Load only the selected tools' full definitions for that turn, and re-run the narrowing step when the task shifts.

Keep the index cheap and evaluated

The one-line descriptions in your catalog are now load-bearing, because they are all the model sees before deciding. Write them the way you would write good tool descriptions in the first place: state when to use the tool, not just what it does. Our guidance on designing tools for production agents applies directly to these summaries. Then measure. Track wrong-tool-call rate and tokens per call before and after, and keep the tool-selection cases in your regression set so a future description edit cannot silently regress selection.

When not to bother

Progressive disclosure is a fix for a specific problem: too many tools. If your agent has eight tools and they are all distinct, the indexing layer adds latency and complexity for savings you will not notice. The extra retrieval or routing hop costs real milliseconds, and a mis-narrowed catalog can hide a tool the model needed, which is a new failure mode you did not have before.

The signal to adopt it is empirical, not aesthetic. Watch two numbers. When tool definitions climb past a few thousand tokens per call, or when your wrong-tool-call rate starts rising as you add tools, the tool list has become the bottleneck and disclosure pays for itself. Under those thresholds, leave it alone and spend the effort elsewhere.

Frequently asked questions

Does prompt caching make tool sprawl a non-issue?

No. Caching lowers the cost of resending a stable tool block, but it does nothing for the accuracy problem, and the model still has to reason over every cached tool when it selects. A cache also churns the moment you edit or version a tool. Caching and progressive disclosure solve different halves of the problem, and the accuracy half is the one that hurts more.

How many tools is too many?

There is no fixed number, but selection reliability tends to hold up to around ten distinct tools and degrade noticeably past twenty to thirty, faster when tool names and purposes overlap. Treat it as a measured threshold in your own traces, not a rule. If wrong-tool calls rise as you add tools, you are over the line for your setup regardless of the count.

Is this the same as the agent skills format?

The skills format that providers standardized in 2026 is one concrete implementation of progressive disclosure, a summary the model reads first and a body it loads on demand. The underlying pattern is general, and you can apply it to raw tool definitions, MCP servers, or your own instruction files without adopting any particular format.

Will the extra routing step slow the agent down?

It adds one fast, cheap call before the main one, typically well under a second with a small retrieval or classification step. On multi-turn sessions the net effect is usually faster, because every subsequent turn runs on a much smaller context. Measure end-to-end latency, not just the added hop, before you judge it.