Tool Use: How Agents Take Action

Talking versus doing

A language model, on its own, can only produce text. It can describe how to book a flight in beautiful detail, but it cannot book one. Tools, the functions you expose to the model, are what close that gap: they let it check a calendar, place an order, query a database, update a record, or send a message. The moment a model can call tools, it stops being a very articulate text generator and starts being something that can act.

This reframes where your effort should go. Teams new to agents spend their time tuning the prompt and choosing the model. Teams who have shipped agents know that the quality of the system is largely the quality of its tools, and the clarity with which those tools are described. A brilliant model with badly designed tools is a frustrated genius with the wrong equipment.

Describe tools like you would brief a new hire

The model selects which tool to call, and how to call it, based almost entirely on three things: the tool's name, its description, and its parameter schema. It has no other window into what the tool does. If the description is vague, the model guesses, and guesses become wrong calls.

So write tool descriptions the way you would brief a capable new hire on their first day. State plainly what the tool does, when it should be used (and when it should not), what each parameter means, what the tool returns, and any cost or risk involved. "Searches orders" is a weak description. "Looks up a customer's past orders by their email address; returns up to the 20 most recent with status and total; use this before answering questions about order history" is one the model can actually act on. The description is part of the prompt. Treat it with the same care.

Fewer, sharper tools beat a big menu

There is a temptation to expose everything: dozens of tools, just in case. It backfires. A long menu of overlapping tools confuses the model about which to pick, and every tool definition consumes context tokens on every single call. The result is slower, costlier, and less accurate.

Prefer a small set of well-scoped tools, each with a clear and distinct purpose. If two tools do nearly the same thing, either merge them into one with a parameter that distinguishes the cases, or make the boundary between them unmistakable in the descriptions. When you find the agent repeatedly choosing the wrong tool, the fix is almost never a smarter model; it is sharper tool design.

Validate everything the model produces

A model will, sooner or later, hand you arguments that are wrong: a missing required field, a string where you expected a number, a date in the wrong format, or an ID it simply invented because it seemed plausible. If you pass those straight through to your real systems, you get crashes at best and corrupted data at worst.

Put a validation layer between the model and execution. Enforce the schema, check ranges and types, and verify that referenced IDs actually exist. Crucially, when validation fails, do not crash the loop, return a clear, machine-readable error message back to the agent. A good error ("date must be in YYYY-MM-DD format; you sent 'next Tuesday'") lets the model correct itself on the next pass. This single pattern, validate and return a recoverable error, turns a large class of hard failures into self-healing ones.

Side effects are not free

Not all tools are equal. There is a world of difference between a tool that reads and a tool that writes. A read, looking something up, fetching a record, can be retried freely; if it fails, you just try again. A write, sending money, emailing a customer, deleting a record, changes the world, and a mistaken or duplicated write can be expensive or impossible to undo.

Design with this split front of mind. Give read tools generously; they are low-risk. Treat write tools with caution: require confirmation for the consequential ones, use idempotency keys so a retried call does not fire twice, and route the truly irreversible actions through a human approval step. Separating reads from writes in your architecture is one of the simplest, highest-impact safety decisions you can make.

Test tools in isolation

When an agent misbehaves, the instinct is to blame the agent, the model, the prompt, the loop. But a large share of "the agent is broken" reports are really "a tool returned something the agent could not handle": an unexpected error shape, a null where data was assumed, a payload too large for the context.

Before integrating, prove each tool works on its own. Call it with good inputs and confirm the output. Call it with bad inputs, missing fields, wrong types, edge cases, and confirm it fails gracefully with a useful message. Tools that are individually solid and predictable make agents that are far easier to reason about. Tools that are flaky in isolation make agents that are impossible to trust, no matter how good the model is.