How Agents Use Tools, and Why That Changed Everything

Everything an agent does rests on one mechanism, and it is simpler than it sounds. Understanding it explains both why agents can do what they do and why they fail the way they fail.

The mechanism

Four steps, repeated.

For a vendor-side perspective, Monitask also has a page on workforce optimization.

1. The model is told what tools exist. Each with a name, a description of what it does, and what arguments it takes. "search_orders: find orders by customer name or order number."

2. The model decides whether to use one, and with what arguments. It produces a structured request rather than prose.

3. The system runs it. The actual search, query, message, calculation. This part is ordinary software — the model does not execute anything itself.

4. The result comes back into the conversation, and the model decides what to do next. Use another tool, use the same one differently, or answer.

Repeat until done.

Why this was a threshold rather than an increment

Before tool use, a model could only produce text from what it already knew. Fixed at training, with no way to check anything.

With tools it can find out. Look up the current figure, read the actual document, check whether the record exists.

And it can affect things, which is the larger change. Output stopped being text and became actions in real systems.

The reliability threshold matters here. Choosing the right tool with the right arguments and correctly interpreting the result had to become dependable enough that errors did not compound into nothing usable. That threshold being crossed is what made agents viable, and it is why they arrived when they did rather than earlier.

What follows from the mechanism

Each of these is a direct consequence, not a separate problem.

The agent can only do what the tools allow. The tool list is the boundary — which is why permissions are the real control rather than instructions. See permissions.

Tool descriptions matter enormously. The model chooses based on the description. Vague or overlapping descriptions produce wrong choices, and this is a common and easily fixed source of poor behaviour.

Results enter the conversation. Whatever a tool returns becomes context the model reads — which is exactly why content containing instructions is dangerous. See prompt injection.

Each cycle costs. Context accumulates and is resent, so long chains cost more per step as they go. See what agents cost to run.

Errors compound. Every cycle is a chance to choose wrongly, and 95% per step is 60% across ten. See what agents are still bad at.

And the agent cannot verify its own conclusion unless a tool does it. Verification has to be external.

Where tool use goes wrong

Too many tools. Beyond some number the model chooses less reliably. Fewer, clearly distinguished tools work better than a large library.

Overlapping tools. Two that do similar things produce inconsistent choices.

Poor descriptions. The most common and cheapest fix — the description is the interface, and writing it precisely is worth the time.

Tools that fail silently. Returning empty rather than an error means the agent concludes nothing was found.

Tools that return too much. A query returning ten thousand rows fills the context and pushes out everything else.

And missing tools. The agent works around the gap, sometimes creatively and wrongly, rather than reporting that it cannot do the thing.

What MCP changed

Before, each agent-to-system connection was bespoke. Every pairing was separate work.

The Model Context Protocol standardised how agents connect to enterprise data — a tool exposed once works with any compliant agent. For broader independent background, see NIST AI Risk Management Framework.

What it does not change: whether your systems have interfaces, whether the data is clean, what the fields mean, or who may do what. See integration is the hard part.

It removed a layer of work. The layers underneath are unchanged.

What this means practically

If you are evaluating an agent: ask what tools it has and what each can do. That list is the capability and the risk surface, and it is a more informative answer than any specification.

If you are building one: spend time on tool descriptions and on keeping the list short. It is the cheapest improvement available.

If you are worried about safety: the tool list is where to look. An agent with no tool that sends anything cannot send anything, regardless of what it is instructed to do.

And if it is behaving oddly: check the tool descriptions before the model. Ambiguity there produces most of the confusing behaviour.

The short version

Describe the tools, the model picks one, the system runs it, the result comes back. Repeated until done.

Tool use crossing a reliability threshold is what made agents viable, not a jump in general intelligence.

The tool list is the boundary — permissions, not instructions, are the real control.

Tool descriptions are the interface, and improving them is the cheapest fix for odd behaviour.

And results entering the conversation is why untrusted content is dangerous.