Why a custom tool costs an agent fewer tokens than the same workflow improvised

When an agent works through a workflow on its own, it pays for every step in tokens: the tool definitions it loads, each intermediate result that passes through its context, the scripts it writes and the retries after they fail. Packaging the same workflow as one custom tool removes most of those steps. In our own measurement of one task, the custom tool used 31% fewer tokens, cost 23% less, took 26% less time, needed 25% fewer turns and had 55% fewer failed calls.

This post explains where the tokens go, what we measured and how to decide which workflows to package.

##Where an improvised workflow spends tokens

Take a request like "which campaigns overspent last week, and by how much?". With only general MCP servers and a shell, a capable agent finds an answer, but the path looks something like this:

• Tool definitions. Most MCP clients load every connected tool's definition into context before the agent does anything, and they stay there for the whole conversation.
• Exploration. The agent lists tables or endpoints, reads a schema and samples a few rows to learn what the data looks like.
• Intermediate results. Every row it fetches passes through its context, even when the answer is three numbers computed from them.
• Scripts. It writes a small script to join and sum the data, runs it, and often fixes it once or twice.
• Retries. A wrong column name, a date in the wrong format or a missing permission each costs another turn.

Anthropic described the same cost from the other side: tool definitions and intermediate tool results both consume context, and in one example moving that work into code reduced a workflow from about 150,000 tokens to 2,000. The model does not get worse at the task. It just repeats the discovery every time it is asked.

##What a custom tool changes

A custom tool does the discovery once, when a person writes it. After that the agent's part is small: read the tool's description, fill in a typed input and read a compact result.

• One call instead of a chain. The joins, filters and sums run in the tool, and only the result comes back.
• Input checked before anything runs. Every property is required and unknown ones are rejected, so a wrong argument fails at once with a message the agent can act on, instead of halfway through a script.
• A declared output. The output schema tells the agent what it will get before it calls, and the result is checked against it.
• The same answer every run. Two people asking the same question in different agents get the same numbers, because they call the same code.

##What we measured

We ran one task both ways. In the first, an agent got a description of the workflow and worked through it on its own, with MCP calls, its own scripts and retries. In the second, it had the same workflow as one custom tool. We ran each version three times and compared the medians:

• 31% fewer tokens
• 23% lower cost
• 26% less wall time
• 25% fewer turns
• 55% fewer failed calls

This is one task with three runs each way, so treat it as a direction rather than a benchmark. The gap depends on the workflow. A task with one API call has little to save, while one that explores, joins and retries has much more.

##How this relates to code execution

Letting an agent write code against MCP servers, so intermediate data stays out of its context, attacks the same cost. The difference is when the code is written. With code execution the agent writes it during the task, every time. A custom tool is written once, reviewed in a pull request, tested with zya exec --local and shared with everyone in the group. For a workflow people ask for every week, writing it once is cheaper and easier to trust.

##Which workflows to package

• Asked for at least weekly, by more than one person.
• The steps are known and the answer should not depend on who asked.
• The agent reads much more data than it reports, such as rows summed into a total.
• You have seen an agent get it slightly wrong, or take several tries.

##Keep tool output small

A tool can still waste tokens if it returns everything. Return only the fields the agent needs to answer, aggregate on the tool's side, add a limit input for lists and declare an output schema so the shape is known up front. A tool that returns three numbers instead of three thousand rows is where most of the saving comes from.

##Questions people ask

##Further reading

• Anthropic: Code execution with MCP: building more efficient agents
• Zenitya docs: Writing tools
• Model Context Protocol: Specification: Tools