Stop Giving Your AI Agent 25 Tools

An agent with seven tools makes good decisions. The same agent with twenty-five picks the wrong one often enough that people stop trusting it, and it costs several times as much to do it.

This is the least intuitive failure in agent design, because nothing breaks. No error is raised. The agent confidently chooses a tool that was never right for the request.

What actually goes wrong when you add tools

Every tool definition is paid for twice.

It is paid for in tokens, because the definition sits in the context window on every single request whether or not it gets used, which is the same standing cost that made prompt caching worth 57% of our per-request bill. And it is paid for in decisions, because each new tool is one more near-neighbour the model has to rule out before it picks. Choosing between seven options is a different problem from choosing between twenty-five, and models degrade on the second one in a way that better models only partly fix.

The symptoms arrive together: responses slow down, costs climb, and the agent starts reaching for the wrong tool on requests it used to get right.

Where does the curve actually turn?

We did not run this benchmark ourselves. The numbers below are a synthesis of published reports on production deployments across OpenAI, Anthropic and LangGraph systems, including Redis's research on MCP tool overload, and they agree with each other closely enough to plan against:

Two things stand out. The accuracy decline is not gentle: it holds up to about fifteen tools and then falls off. And the token column is worse than linear, because a large tool catalogue tends to bring large schemas with it. Redis's write-up reports over 150,000 tokens consumed before the user has asked anything at all, and a 96% token reduction from loading tools dynamically instead.

The pattern: a small base, everything else on demand

The fix is not to have fewer capabilities. It is to have fewer capabilities in context at once.

Keep a base set of tools that earn their place on nearly every request:

1BASE_TOOLS = [
2    "list_skills",           # discover capabilities
3    "activate_skill",        # load specialised tools
4    "search_knowledge_base", # core RAG
5    "get_current_time",      # basic utility
6    "calculator",            # basic math
7    "remember",              # memory write
8    "recall",                # memory read
9]

Seven tools. Two of them exist purely so the agent can go get the others.

Everything else is grouped into skills that enter the tool list only when the run needs them:

1async def prepare_tools(ctx, tool_defs):
2    # Start with base tools only
3    allowed = list(BASE_TOOLS)
4
5    # Add tools from activated skills
6    for skill in ctx.deps.activated_skills:
7        skill_tools = get_skill_tools(skill)
8        allowed.extend(skill_tools)
9
10    return [t for t in tool_defs if t.name in allowed]

Activating a research skill brings in web search, URL crawling and news search. A documents skill brings in PDF generation and markdown export. A visualisation skill brings in charts and image generation. None of them is in context until it is wanted.

What belongs in the base

The line is easier to draw than it looks:

The side-effects row is the one people skip. A tool that sends an email should never be sitting in context by default, because "available" and "chosen by mistake" are closer together than anyone wants.

What it changed here

Our own before-and-after, measured on our agent in February 2026:

Accuracy went up because the agent had fewer wrong answers available, not because anything about the model changed. That is the part worth internalising: the context window is a design surface, and what you leave out of it is a decision you are making on the model's behalf.

It is also the architecture the product runs on. Savra carries dozens of marketing skills across a dozen domains, and the agent never sees more than a handful of them at once, which is what makes one agent workable where a stack of tools is not.

FAQ

How many tools should an AI agent have?
Five to ten always available, everything else loaded on demand. What matters is how many are in context for a single decision, not how many exist.

Why does adding tools make an agent less accurate?
Each definition costs tokens on every request and adds one more near-neighbour to rule out when choosing. The failure mode is a confidently wrong choice, not an error.

What belongs in the base tool set?
Things used in most requests, cheap, side-effect free and domain-neutral. Anything that writes a file or sends a message belongs in a skill.

What is dynamic tool loading?
The agent starts with the base set plus the ability to discover and activate more, so the tool list stays short and relevant at every decision point.