How you split a capability into tools is usually inherited — one tool per endpoint, because that is what the API looked like. This study makes it the variable instead, running the same 81 multi-step tasks against four interface shapes over nine locally served models and 8,748 trials. Four tools grouped by function completed 16.4% more tasks than eight to ten single-purpose ones and 33.6% more than a single tool for everything, and doubled the share of calls with correct arguments, from 0.20 to 0.40. Model size barely predicted completion at all.
Nine domains, each with a fixed set of things an agent can do, and each exposed at four different interface shapes: one tool per operation, four tools grouped by what the caller is trying to accomplish, two tools split into reads and writes, or one tool that takes an action name as an argument. The underlying capability never changes. Only the shape of the door does — and the same nine models, run on the same 81 tasks, score very differently depending on which door they are given.
Slide through the four shapes and watch the toolbox and the scores move together.
Notice that tool selection and task completion do not peak together. The two-tool split scores the best selection F1 of any shape at 0.71 — with two options, picking the right one is nearly free — and still completes fewer tasks than the four-tool grouping, because once you are inside a tool that broad, the work has moved into the arguments. Picking the right door is not the hard part. Describing what you want once you are through it is.
There are two different failures at the two extremes, and they are worth separating because they look nothing alike in a trace. At the fine-grained end the model has to reason over eight to ten candidate tools for every step, and the sequences get longer because each step is its own call. At the consolidated end, something stranger happens: the model stops calling tools at all.
Step across the four shapes and watch the runs that never touched a tool.
Against a single monolithic tool, 28.2% of runs invoked nothing. The models either announced the task was done without touching anything, or reached for a tool name they remembered from somewhere else. A wide enough interface stops reading as an interface.
The error rate climbs with it, from 11.4% at the four-tool grouping to 15.8% against the single tool. If you have ever watched an agent confidently report success on a job it never started, this is the shape of that bug, and it is a property of the interface rather than of the model.
The tempting response to an agent that cannot drive your tools is a bigger model. The study puts nine of them, from 268 million to 20.9 billion parameters, on the same tasks and measures what size actually predicts. It predicts wall-clock time almost perfectly. It barely predicts whether the job gets done.
Switch the vertical axis between the two things size might buy you.
The headline comparison is the 3.2 billion parameter model at the four-tool grouping, which completed 0.61 of its tasks in 6.7 seconds with a zero percent error rate, against the 20.9 billion parameter model's 0.44 at its own best shape and 0.34 averaged over all of them. Six times the parameters, four times the latency, fewer tasks finished. The interface was worth more than the model.
A reasonable objection: maybe the four-tool result is really about small models being bad at long candidate lists, and a capable model would happily take ten tools. The authors split the bank at eight billion parameters and ran the same comparison inside each half. The grouping wins in both, and the thing it moves most in both is the same thing.
Switch between the two size classes.
In both halves the four-tool grouping roughly doubles or triples argument accuracy against one tool per operation, while task completion moves by a handful of points. That ratio is the tell: the grouping is not helping the model choose, it is helping the model describe. Related operations behind one tool share an argument shape, and the model gets more chances to learn it within a single task.
Most tool servers grow one tool per endpoint, because each endpoint arrived on its own. Set the sliders to whatever yours looks like now, and see which of the two moves available to you — regroup the tools, or upgrade the model — the study's numbers actually support.
The energy column is the same argument in another currency. At the four-tool grouping, the 3.2 billion parameter model spent 621 joules per completed task and the 14.8 billion parameter model spent 14,544 — twenty-three times as much for eighteen more points of completion. If you are running agents at any volume, the shape of the toolbox is the cheaper variable, and it is one you control without changing a single model.