One tool that writes code: why our agent has nothing else

Because a tool the model can see is paid for at every step of every conversation, while a function that code imports costs nothing until it is used. So Balt has one tool, which runs code, and everything it can do is a function it imports. On the day a company connects its fiftieth integration, the fixed part of what the model rereads has grown by a single line.

This is not an engineer’s affectation. It follows from simple arithmetic, and we learned it by doing the opposite first, like almost everyone: one tool per action, added on the day the action became useful, until the list cost more than the work.

What does a tool cost when the agent is not using it?

It costs its entire description, at every step, multiplied by the number of steps, and it is the line item almost nobody looks at. We have described elsewhere how tool definitions account for 14% of an agent’s bill, ahead of the reasoning it actually produces. That figure is an average, and it hides a slope.

Anthropic measured the slope in November 2025: five common MCP servers, 58 tools in all, consume around 55,000 tokens before the user has typed anything. In their own systems, tool definitions reached 134,000 tokens before optimisation. An agent connected to a company’s messaging, calendar, CRM, ATS and shared drive therefore rereads, at every step of a task that touches only one of them, the complete manual for the other four.

Volume is not the only problem. The longer the list, the more often the model picks the wrong tool or the wrong parameter, which is why the same post reports that letting the model search for its tools, rather than presenting them all, raised one model’s accuracy from 49% to 74% on their MCP evaluations. A long tool list makes the agent more expensive and worse at the same time, which is rare enough to take seriously.

Why one tool rather than one tool per action?

Because a model writes code better than it chains tool calls, and code keeps out of the context everything that has no reason to be there. Three independent publications arrived at the same shape within a year, and that is what convinced us this was not a matter of taste.

The first is academic. The authors of CodeAct, presented at ICML in 2024, compared seventeen models expressing their actions either as structured calls or as executable Python, and code came out with up to 20% higher success. The explanation is that a loop, a condition or an intermediate variable is natural to write in code and awkward to express as a series of separate calls.

The second came from Cloudflare in September 2025, under a headline that pulled no punches: “we’ve all been using MCP wrong”. Their argument is about how models are trained, having seen enormous amounts of real code and very few tool calls. So they turn each MCP server into a typed library and give the agent a single tool, the one that runs the code in an isolated environment.

The third is Anthropic’s, two months later. By letting the agent call the same tools from code, one task went from 150,000 tokens to 2,000, a reduction of 98.7%. The saving comes from two places: descriptions are read only when the agent needs them, and intermediate results stay in the execution environment instead of passing through the model. A two-hour meeting transcript copied from one tool to another adds about 50,000 tokens to the context; handled by code, it never enters it.

How does the agent know what it can do if it sees no tools?

It reads, the way a new colleague opens the documentation for the application they need rather than learning every piece of software in the company on day one. Each capability takes one line in what the model sees: what it does and where to read the detail. The rest lives in a file the agent opens when the task leads it there.

That line has a requirement we discovered by getting it wrong. It has to say where to read, otherwise the agent refuses, quite rightly, to use a capability whose instructions it cannot find. A capability found by reading is only useful if the path to the reading is written down.

The other consequence is the one that made us choose this shape rather than simply pruning the tools. The agent can write its own functions and keep them, in the same place and in the same form as the ones we ship. An agent that can only use what we wrote stops at what we had imagined, and that is exactly where a colleague starts being useful. It is also why written, reviewed know-how beats splitting the work across sub-agents: both rest on the same idea, context loaded when it is needed.

Where does prompt caching come into this?

It is the second multiplier, and it is bigger than the first. A model remembers nothing between two calls, so every step resends everything before it; the provider then bills the part it has already seen at a tenth of the price, on one strict condition: the beginning of the request must be identical, byte for byte.

A tool list that changes on the day someone connects an application therefore does not only cost its own tokens. It alters the very start of the request and forfeits the discount on everything behind it, which is to say on most of the bill. That is the mechanism that makes it possible to save 88% over fifty steps, and it only works if the fixed part stays fixed.

We eventually understood that the single-tool rule and the stable-prefix rule are the same rule seen from opposite ends. A new capability must change nothing in what the model rereads at every step, neither its size nor its content, or it gets paid for twice.

What happens when the rule gets in the way?

It gets in the way often, and that is how you tell a rule from a preference. Adding a visible tool is always quicker than writing a function and its index line, and each time the convenience argument is sound taken on its own.

So we wrote the rule into the code rather than into a document. The list of tools the model can see is pinned in a test, and the build fails if a tool appears that is not on it. That ceiling can fall and cannot rise: not because a tool is small, not because a capability would be easier to reach, and not because a vendor asks for it.

And it has fallen. The messaging reads, which duplicated functions already available, moved behind the code. Triggers, which were only a routine fired by a condition instead of a clock, joined the routines. The company’s record became an integration like any other. Each time, someone had a good reason to leave the tool where it was, and each time the reason applied just as well to every tool that would come after it.

One tool stayed when it could have gone, because it had already shipped and moving it gained nothing. We wrote that down as a dated exception rather than a precedent, because a list never grows by decision: it grows one reasonable paragraph at a time.

Does writing code make the agent more dangerous?

No, and claiming the opposite would be a poor sales pitch. The shape of the call changes nothing about what the agent can reach, and that is the only thing that matters for security: a limit that holds is a right that was never granted, whether it is crossed by a tool or by a line of Python.

The code runs in an isolated environment, and credentials stay with the platform that relays the calls, which is also the choice Cloudflare made. An outbound action goes through the same human approval as before. And an MCP server tucked behind a library is still a supplier holding access to your systems: its description is read by the model when the model opens the file, which makes it neither more nor less trustworthy than before.

What MCP does well is connecting an application and describing what it exposes, and we are happy to use it. The debate about what MCP changes compared with API integrations is about the connection; ours is only about where the tools land. MCP is a transport, not an interface the model has to carry around.

Will this choice still hold with the next model?

That is the second test we apply, and it settles the cases arithmetic cannot: will this still be useful to a model two generations better than ours? A tool list does not get cheaper as the model improves, whereas a better model writes better code and gets more out of the same functions.

The concession is real and we pay it. A small model writes mediocre code, a round trip through an execution environment takes time, and an agent that has to read before acting needs one more step to get going. For an assistant that does three things, a list of three tools is simpler and will stay that way.

For a colleague who works across every application in a company, the arithmetic stops being debatable beyond a handful of integrations, and it gets worse with each one. What remains is the question every architecture built for a given model has to face: what happens on the day that model is retired, and what you need to have kept separate so the migration breaks nothing.