The 20-Tool Ceiling: Why More Tools Make Agents Dumber

There's a specific kind of technical debt that accumulates silently because every individual commit looks like progress. You integrate a new API. You add a tool for it. The agent can now do one more thing than it could before, the demo works, the PR merges. Repeat that a dozen times over a few months and you have an agent with twenty-five tools, every one of which was a reasonable addition in isolation, and an agent that's measurably worse at its job than it was with eight.

That's not a hypothetical. OpenAI's own guidance recommends keeping agent toolsets under twenty tools, with accuracy degrading noticeably once a toolset crosses roughly ten — and the mechanism behind that isn't mysterious once you understand what a tool actually costs, as opposed to what it appears to cost.

The cost nobody bills for

When a tool gets added to an agent, the visible cost is development time — writing the function, describing it, testing it. The invisible, recurring cost is that the tool's schema now lives in context on every single call the agent makes, whether or not that call has anything to do with the tool. A twenty-tool agent pays the context cost of twenty tool descriptions on the call where it needs tool number three, exactly as much as on the call where it needs tool number nineteen.

That recurring cost compounds with the attention-budget mechanics that govern the rest of context: more tokens spent on tool schemas means less attention available for actually selecting between them, and less attention available for everything else in the window too. The tool count isn't just adding linearly to context size — it's degrading the precision of every decision the model makes on top of that larger context, tool-selection included.

This is why the ceiling isn't really about the number twenty specifically. It's about the point where tool-schema overhead starts meaningfully competing with the rest of what the model needs to reason well, and empirically, for most agents, that point sits somewhere between ten and twenty tools depending on how differentiated the tools are from each other.

Differentiation matters as much as count

Two tools with clearly distinct purposes — send_email and query_database — cost the model less to disambiguate than two tools with overlapping purposes, like search_customers and find_customer_by_name. The second pair forces the model to guess at a distinction the tool names and descriptions don't make obvious, and it will guess wrong some nonzero fraction of the time, especially as more near-duplicate tools pile up around it.

This means the twenty-tool ceiling isn't a hard number so much as a description of where overlap and volume together start costing more than they're worth. An agent with fifteen sharply distinct, non-overlapping tools may perform better than one with eight tools that include two or three near-duplicates. Count is a proxy for the real variable, which is how much genuine disambiguation work the model has to do per call.

How toolsets actually get to twenty-five

Nobody sits down and designs a twenty-five-tool agent on purpose. It happens through addition without subtraction. A team ships an MVP with six tools. A new integration request comes in — add a tool. A slightly different version of an existing capability is needed for an edge case — add a tool, rather than generalizing the existing one. An old tool that's rarely used anymore never gets removed, because removing things feels riskier than adding them and nobody's actively measuring whether it's still earning its keep.

MCP — the protocol standardizing how agents discover and call tools, now governed by the vendor-neutral Agentic AI Foundation after Anthropic's original November 2024 release moved under the Linux Foundation in December 2025 — makes this dynamic worse in one specific way if teams aren't careful: it makes adding a new tool server nearly frictionless. Frictionless addition without a matching discipline of frictionless removal is exactly the pattern that produces toolset bloat. The protocol solves the plumbing problem. It doesn't solve the curation problem, and treating "we can now connect to more tool servers" as a reason to connect to more of them is how a lean six-tool agent becomes an unwieldy thirty-tool one over a year.

Pruning a toolset that's already too big

If an agent has already crossed the ceiling, the fix isn't usually "remove tools until you hit twenty" as an arbitrary target — it's auditing for the actual sources of overlap and dead weight:

• Merge near-duplicates. If two tools differ only in a parameter the model could just as easily supply to one generalized tool, collapse them. Every merge removes one full schema's worth of standing context cost.
• Retire the unused. Instrument actual call frequency. A tool that's been called twice in three months is costing full price on every call in between for near-zero return — a strong candidate for removal or for moving behind a skill that's loaded on demand rather than kept always-registered.
• Move rarely-needed capabilities out of the always-on toolset. Not every capability needs to be a standing tool. Some belong behind a skill or a sub-agent that's invoked only for the specific task that needs it, so the cost is paid only when the capability is actually relevant — the same progressive-disclosure principle that keeps a large skill library cheap even though any individual skill can be as detailed as it needs to be.
• Sharpen descriptions before cutting tools. Sometimes the problem isn't count, it's ambiguity — two tools that could coexist fine if their descriptions clearly staked out non-overlapping territory instead of both vaguely claiming similar ground.

Measuring the ceiling instead of guessing at it

Most teams find out they've crossed the ceiling anecdotally — a support ticket about the agent calling the wrong function, a user complaint that gets shrugged off as a one-off, repeated a few more times before anyone connects it to tool count. That's a slow and unreliable way to detect a problem with a known, testable cause. A more direct approach is to run the same set of representative tasks against the agent at different toolset sizes — the current toolset, and a pruned version with the near-duplicates merged and the rarely-used tools removed — and compare tool-selection accuracy directly. If the pruned version performs as well or better with fewer tools, that's a strong, concrete signal the extra tools were net negative, not just theoretically risky.

This kind of test is worth running before a toolset ever gets close to the ceiling, not just after symptoms show up. Establishing a baseline early — accuracy at six tools, at ten, at fifteen — gives a team an actual curve to watch as new integrations get proposed, rather than a vague sense that "more tools is probably fine until it isn't." Vague senses are exactly what let toolsets drift from six to twenty-five without anyone noticing the point where it started costing more than it was worth.

Treat the toolset like a budget line, because it is one

The twenty-tool ceiling is really a specific instance of the broader context-budget principle: every tool is a recurring cost paid on every call, and it has to keep earning that cost, not just have earned it once at the moment it was added. The discipline that keeps a toolset lean isn't a one-time design decision — it's a recurring audit, the same way a finance team doesn't approve a budget line once and never revisit it.

Teams that treat tool count as something to actively manage, rather than something that only grows, end up with agents that stay accurate as their capabilities expand. Teams that don't end up with agents that were sharp at six tools, fine at twelve, and quietly, measurably worse at twenty-five — with nobody quite sure which addition tipped it, because none of them looked like the problem in isolation.

---

Part of the "Context Engineering" series on aiskill.market.