There is a cost line item in agent systems that nobody puts on the slide: tool sprawl. Wire up a library of MCP integrations and you can suddenly give an agent access to a thousand or two thousand tools out of the box. It looks like power. It is actually a tax you pay on every single run.
The surprising part is that the cost is not in calling the tools. It is in knowing about them. Every tool's name and description gets loaded into the agent's context. Multiply that across hundreds of tools and you have inflated the context window before the agent does any real work. We had one run cost fifteen dollars on Opus. The same job, after we restricted the agent to only the tools it actually needed, cost about a dollar. Same outcome, fifteen times the price, and the only difference was how much the agent was told it could do.
Cost is half the story. The other half is blast radius. An agent that has all twenty-three Gmail tools can fetch, send, and delete messages. An agent that has only the send-email tool can do exactly one thing. When you are running on a cheaper model like Sonnet, a bloated tool set is not just expensive, it is an opportunity for the agent to get confused and do something damaging. Scoping the tools makes the agent more predictable, and predictability is the currency of enterprise deployment.
This is why the right pattern is to lock each agent down to its minimal tool set by default and expand only when a use case demands it. It is the same instinct as least-privilege access in security. You are not limiting the agent for the sake of control theater. You are reducing both the bill and the surface area for failure. This is the unglamorous reality of closing the gap between AI demos and production: the demo works with everything wired up; the deployment needs discipline.
The practical move: treat tools as a budget, not a buffet. Start narrow, measure the token cost per run, and add capability deliberately. The teams that operationalize agents at scale will be the ones who learned that controllability beats magic, and that every tool an agent knows about is a tool you are paying for.
Key takeaways
- An agent's cost scales with the tools it knows about, not just the tools it calls.
- Locking each agent to a minimal tool set cuts token cost dramatically and reduces the blast radius of mistakes.
- Scoped tools make agents more predictable, which is what enterprise deployment actually requires.
FAQ
Why does giving an agent more tools cost more even if it does not use them?
Every tool's name and description gets loaded into context. With hundreds or thousands of tools, that metadata alone inflates token usage. In practice, narrowing tools took one run from fifteen dollars on Opus down to about a dollar.
Isn't it easier to just give an agent access to everything?
Easier to set up, expensive to run, and dangerous. An agent with full Gmail access could delete messages. Scoping to a single send-email tool means the worst it can do is the one task you intended.
Related Essays
Tech Context Is Tractable. Org Context Is Not
The hardest unsolved problem in agent infrastructure is not compute or sandboxing. It is context — and most of that context lives in people, not repos.
Stop Re-Deriving the Same Facts
The practical win in agent memory is not total recall. It is a shared fact store with a lifecycle, so agents stop re-deriving what the organization already knows.
Facts Rot. Reports Supersede. Build Memory Accordingly
Organizational agent memory needs rot and supersession semantics. Facts have lifespans, and the fresh report that replaces yesterday's is the format LLMs actually need.
Drowning in pull requests that need your review? Try Tembo Review, a beautiful AI-assisted PR review tool unlike anything you’ve used.