Your Agents’ Most Expensive Habit Is Carrying Every Tool to Every Job

We’ve argued that bigger context windows raise the ceiling while selection decides what earns it, and that context engineering, not prompt phrasing, is where reliability is decided. This post identifies the largest unmanaged occupant in that context: the toolbox. Every MCP server you expose can pay rent in the model’s window on every call, and almost nobody is metering it. MCP made tools easy to connect. TokenOps, Product Pillar 1 at Nasiko, makes them deliberate to expose.

The meter starts before the question is asked

Here is the quietest line item in your AI bill. In the simplest and still-common MCP pattern, the agent registers the available tool definitions before it reasons: descriptions, parameter schemas, usage notes, all of it, whether the tool gets used or not. Careful teams mitigate this with discovery, filtering, or lazy loading, but the default that most stacks ship with is the full surface, on every call.

Connect one server, and it’s noise. Connect a dozen, which is exactly what MCP made easy, and it’s a standing tax. Practitioners working from AWS’s tool design guidance put numbers on it: an agent with 20 tools can spend 5,000 to 10,000 tokens per invocation on tool descriptions alone. That’s cost, latency, and degraded accuracy, paid before the user’s question arrives.

MCP made a connection cheap. It didn’t make carriage free.

MCP deserves enormous credit. It collapsed the M×N integration problem into M+N and made connecting agents to systems nearly free. But that’s precisely the new problem: the connection became free while carriage stayed expensive. The protocol tells you how to plug a tool in. It says nothing about whether that tool deserves to ride along on this particular call.

Sound familiar? It’s the same unowned seam we’ve been writing about all series, one level further out. Nothing here is a knock on MCP, any more than the last post was a knock on prompts. Protocols standardize connections. Deciding what to carry is your job, and right now, in most stacks, nobody owns it.

The loop tax: bloat creates confusion, confusion creates retries

AWS’s guidance on MCP tool design points to two failure modes that recur in production, and they feed into each other.

The first is bloat. Tool definitions consume context, whether or not they’re relevant, and as context fills, the model’s ability to reason degrades. This is the same context rot we covered in the last post, now with a permanent tenant: research across 18 frontier models shows reliability declining continuously as input length grows, and tool definitions are input like everything else.

The second is confusion. As reasoning degrades, the model selects the wrong tool or parameters. Each failed call triggers a retry, each retry re-sends the tool surface, and the bloat compounds. You end up spending tokens on having spent tokens.

Bad descriptions make the toolbox harder to use, and fixing them isn’t free

The description is the model’s only decision surface when choosing among tools, and the ecosystem’s descriptions are in rough shape: a 2025 study of MCP tool descriptions found that 97.1% contained at least one quality issue, and 56% failed to state their purpose clearly. When the labels are vague, confusion isn’t a risk; it’s the default.

Here’s the part that should reframe the remedy. The same study tested richer, augmented descriptions and found they improved task success by a median of roughly 6 percentage points, but increased execution steps by 67% and caused regressions in about one case in six. Even remediation has a TokenOps tradeoff: better descriptions add tokens and can lengthen execution, which is why the answer cannot simply be “write longer tool descriptions.” Every fix to the tool surface is a budget decision in itself. There is no escaping the selection problem; there is only doing it deliberately or by accident.

And doing it deliberately appears to pay: AWS cites research suggesting disciplined tool governance, proper scoping, credential isolation, and rate limiting can improve task accuracy by 28 to 32 percent. AWS also argues that workflow-scoped tools are markedly more reliable than raw endpoint exposure, because the tool interface aligns with the task the agent is actually trying to complete. Managing the tool surface isn’t a compliance chore. It makes agents measurably better at their jobs.

The waste has an address

There’s a bigger token-economics story here. In a recent a16z guest essay, George Sivulka argues that tokens now behave like a workforce: unmanaged agents create loops the way unmanaged organizations create meetings about meetings, and his provocation is that “80% of tokens today do nothing.” Whether or not you buy the full analogy, tool sprawl is one of its clearest concrete cases: tokens paid to describe capabilities the agent rarely uses, then sometimes paid again when the excess surface causes retries.

The waste is not mysterious. It has an address. Addressable waste is governable waste.

Tool exposure is a TokenOps decision

TokenOps, as we’ve defined it in this series, is the practice of selecting, measuring, and governing what enters an agent’s context window at runtime. At Nasiko, the tool surface runs through all three of its motions:

Forecast and monitor. You cannot manage what you can’t see. Cost attribution per tool surface, per server, per agent, per workflow: which tools are carried, which are called, what each connection actually costs across a month of traffic. Most teams today can’t answer “what does this MCP server cost us in context,” because nobody is metering carriage, only usage. Optimize. The remedies are known, and they’re selection problems. Scope tools to workflows rather than raw endpoints. Load tools progressively instead of all at once. Expose each agent to only the toolset its job requires. This is the same budget-constrained selection discipline our PACMS research applied to conversation, memory, and tool outputs, applied one layer earlier: deciding which capabilities deserve the window before deciding which content does. Govern. Allowlists for which agents may see which servers. Budgets and caps on tool-heavy workflows. Alerts when a tool’s context footprint or retry rate crosses a threshold. Chargeback so the team that connects fifteen servers to a shared agent sees the bill.

Tieing the last three posts together

Three posts, one argument, three levels:

The window: capacity is necessary, but selection decides what earns it. The prompt: instructions are necessary, but context decides what they can operate on. The toolbox: connection is necessary, but exposure decides what every call pays for.

Each time, the leverage lives at the same place: the assembly step, where the system decides, per call, what the model gets to see. MCP made the supply of tools effectively infinite. That’s exactly why the demand side, what each call actually admits, is now the discipline that separates agents that compound value from agents that compound cost.

The gold rush advice was to sell pickaxes. The 2026 version is quieter: meter the pickaxes, because most of them are being carried up the mountain and never swung.

MCP made tools easy to connect. TokenOps makes them deliberate to expose.

The first TokenOps question is simple: what does each connected tool surface cost before it ever gets called? If you can’t answer that today, that’s the first number Nasiko’s control plane helps you find.