Tools Are the Model's Hands

An agent is only as capable as the tools you hand it. The model supplies the reasoning, but it cannot read a file, query a database, or send a message on its own. Each of those is a tool you wrote and exposed, a function the model invokes by emitting structured arguments. So the ceiling on what your agent can do is the set of tools in front of it, and the quality of each call is set almost entirely by how you described that tool. The model decides whether to call a tool, and with what arguments, from its name, its description, and its parameter schema. Nothing else. It never sees your implementation. The description is the only interface the model has, which means the description is the prompt, and a tool with a vague one fails in a way that looks like the model being stupid when it is really you under-specifying the job.

Watch what a loose description does. "Query the database" tells the model nothing about scope, so it writes a query against the wrong table, or a write where you meant a read, and it does this confidently because nothing told it not to. Tighten the same tool to "Run a read-only SQL SELECT against the analytics Postgres. Returns at most 100 rows. Do not use for writes or schema changes." and the wrong call mostly stops happening, because the boundary is now stated where the model reads. The strongest descriptions say two things a beginner leaves out: when to use the tool and when not to. The "when not to" is what stops the model from grabbing the nearest plausible tool the moment a task gets ambiguous.

Naming carries as much weight as the description. Two tools called get_data and fetch_data give the model a coin-flip every time it needs one of them, and it will sometimes call the wrong one and pass arguments shaped for the other. Names should be unambiguous about what the tool does and distinct enough that the model never has to guess between near-synonyms. The same discipline runs into the arguments. If a tool takes a free-text date field, the model will hand it 5/30 and next Tuesday and 2026-05-30 on different turns. Constrain the shape instead. An enum for a status, an ISO-8601 type for a date, a bounded integer for a limit. You are making the wrong call hard to express, which is poka-yoke applied to a function signature. A constrained argument blocks a whole class of wrong calls before the agent ever runs.

The return matters as much as the call. The naive instinct is to mirror your REST API one endpoint to one tool and pass the raw response straight back. That return is shaped for a programmer reading JSON, not for a model spending a context budget. A tool that hands back a 50KB JSON blob does two bad things at once. It burns thousands of tokens of context, and it buries the three fields the agent actually needed under pagination metadata, null fields, and nested envelopes the model now has to reason through. Return what the task needs, in the shape it can use. Filter, summarize, and page on the server side so the agent gets the answer rather than the API's idea of a response.

The same logic applies one level up, to how many tools you expose. The intuition is that more tools means a more capable agent. The opposite is true past a point that arrives faster than anyone expects. Every tool you connect injects its name and full description into the model's context on every single call, so a wall of tools is a standing tax paid before the agent does any work, and worse, it is a selection problem. The model has to pick the right tool from the list, and that choice degrades as the list grows. On the Berkeley Function-Calling Leaderboard, every model tested performed worse with more than one tool available, and the slide is steep. Past roughly thirty tools the descriptions start overlapping and selection accuracy falls. Past a hundred, failure is close to guaranteed. The sharpest single data point: Llama 3.1 8B failed a benchmark when handed 46 tools and succeeded on the same work when the set was cut to 19. The tools did not change. The number of them did.

Good tool design has a floor it cannot lift you above. If the underlying task genuinely needs reasoning the model does not have, no description rescues it. A perfectly named, tightly scoped tool still fails when the work itself is beyond the model, and reaching for better tool copy there is the wrong fix. The opposite trap is consolidating too aggressively. "Fewer tools" is real advice, but collapsing three honest tools into one overloaded tool with a mode flag and eight conditional arguments just moves the ambiguity from tool selection into argument selection, where it is harder for the model to get right and harder for you to see go wrong. Consolidate around a task the agent actually performs, not around your urge to shrink the list. None of this trips an alarm. Nothing warns you that a description is too vague or that your fortieth tool tipped selection into the failure zone. The signal shows up in the calls themselves: the model reaching for the wrong tool, passing an argument shaped for a different one, or looping because a tool returned an error it could not act on. Those are tool-design symptoms wearing a model-stupidity mask, and the fix is in the tool, not the prompt.