Fewer tools, better names: the hidden cost of giving an agent everything

There is a common reflex when building an agent: if I give it more tools, it will be able to do more. It feels intuitive and it is wrong.

Tool definitions live inside the context window, on every single call. A typical definition runs between one hundred and five hundred tokens. A five-server setup with fifty-eight tools eats roughly fifty-five thousand tokens before the agent reads a single word from the user. Some popular integrations run seventeen thousand on their own.

But the token cost is the smaller of the two.

The cost that matters is hesitation

If the agent sees fifty tools, it has to read and rank fifty descriptions to decide which one to use. That inflates the prompt, slows the response, and worst of all, nudges it toward the broad tool when the narrow one would have been safer.

We saw this with a generic "save file" tool. It existed for legitimate cases, but the agent started reaching for it constantly, including for things that had their own validated path. It never did anything catastrophic. It simply took the wide road because the wide road was there.

The fix was not a better prompt. It was removing the generic tool from that agent's catalog.

How we design ours

The name does half the work. A tool called delegate_asset gets used differently than one called process_file. The name tells the model what kind of action this is before it reads the description.

The description says when NOT to use it. This is what helped us most. Explaining what a tool does is not enough; you have to say in which cases something else is a better fit. "Use this only if the file is not already in the account storage; if it is, use X instead."

Each agent gets its own catalog. The agent that talks to clients and the one that executes internal tasks do not share tools. They share infrastructure, not capabilities.

Tools are tested. We have a test that validates the schema of every tool and fails if one ends up with a wrong type or an empty description. That sounds obvious until an empty description ships to production and the agent starts picking blind.

Lazy loading

There is an elegant way out when the catalog genuinely has to be large: do not load every definition upfront, fetch them when needed. The published numbers are striking: one case where definitions consumed one hundred thirty-four thousand tokens dropped to roughly five thousand with lazy loading, an eighty-five percent reduction.

That is the right direction as a catalog grows. But the other half deserves saying out loud: if your agent needs fifty tools, maybe you do not need lazy loading. Maybe you need two agents.

The question we ask before adding one

Before adding a new tool to a catalog, the question is not "would this be useful?" Almost everything would be useful. The question is: what concrete task is impossible today, and why does none of the existing tools cover it?

If there is no clear answer in one sentence, the tool does not get in.