The core insight

Agent reliability is determined more by tool design than by model choice. Vague descriptions, overlapping responsibilities and oversized return payloads cause most of what gets blamed on "the AI being unreliable".

Tool use is what turns a language model into something that can act. It is also where most agent implementations quietly go wrong.

How it actually works

  1. You define tools — a name, a description, and a schema for the arguments.
  2. The model receives them alongside the user's request.
  3. The model decides whether to call one, and with what arguments.
  4. Your code executes it — the model never runs anything itself.
  5. The result returns to the model as context.
  6. The model continues, possibly calling another tool, or answers.

Step 4 is the security-relevant one. The model produces a request to call a tool; your code decides whether to honour it. That is where validation, permission checks and approval gates belong. An architecture where the model's output directly triggers execution has no control point.

What makes a good tool

A precise, unambiguous description

This is the interface between your intent and the model's decision-making. It should state exactly what the tool does, when to use it, and — often overlooked — when not to.

Poor description

  • "Gets customer information"
  • Ambiguous scope
  • Overlaps with three other tools
  • No guidance on when to use it

Good description

  • "Returns contact details and account status for a customer, given their account ID. Use when the user asks about a specific known customer. Does not return order history — use get_customer_orders for that."
  • Clear scope and boundary
  • States what it does not do

One responsibility

A tool doing several things forces the model to reason about which mode it wants, and makes validation harder. Separate tools with clear boundaries are more reliable than one flexible tool.

Strict argument schemas

  • Every parameter typed and described.
  • Required versus optional stated explicitly.
  • Enumerated values where the set is fixed — do not accept free text for a status field.
  • Format constraints on identifiers and dates.

Trimmed return payloads

Return what is needed to answer, not everything available. A tool returning a full record with forty fields when three are relevant wastes context, costs tokens, and makes it harder for the model to find what matters.

A diagnostic worth running: read your tool descriptions as though you were an intelligent person with no knowledge of your systems. If you could not confidently choose between two of them, neither can the model. That ambiguity is the single most common cause of unreliable agents.

Error handling that helps the model

Tools fail. What you return determines whether the agent recovers or gives up:

SituationPoor returnBetter return
Record not found"Error""No customer with ID X. Verify the ID or search by name."
Invalid argumentStack trace"Date must be YYYY-MM-DD. Received '15/03/26'."
Permission deniedSilent empty result"This user cannot access billing records."
Upstream timeoutException"System temporarily unavailable. Retry or escalate."
Too many resultsEverything"412 matches. Narrow by date or status."

An error message written for the model is one it can act on. An error message written for a developer is one it will paraphrase to the user as a failure.

Managing tool count

Reliability degrades as the number of tools grows. Strategies:

  • Ruthless consolidation — do you need separate tools, or one with a parameter?
  • Routing — a first-stage classifier narrows to a category, then a smaller tool set applies.
  • Context-dependent exposure — only offer tools relevant to the current task.
  • Naming discipline — consistent verb-noun naming makes selection easier for the model and for you.

The security dimension

  • Never expose arbitrary execution — no raw query, no generic HTTP call, no shell.
  • Validate every argument server-side, regardless of the schema. The schema guides the model; validation protects you.
  • Apply the user's permissions, not the service's.
  • Gate consequential tools behind confirmation.
  • Rate limit — an agent in a loop calls tools rapidly.
  • Log every call with arguments and outcome.

Testing tool use specifically

  1. Selection accuracy — given a query, does it choose the right tool?
  2. Argument accuracy — are the parameters correct and well-formed?
  3. Error recovery — given a failure, does it retry sensibly or escalate?
  4. Refusal — when no tool applies, does it say so rather than forcing one?
  5. Chaining — for multi-step tasks, does it sequence correctly?

Score these separately from answer quality. An agent that answers well but selects tools poorly will fail unpredictably as your tool set grows.

Building an agent that needs to act on your systems? Tell us what operations it needs. See our agentic AI service, MCP server guide, and evaluation frameworks.

Frequently asked questions

Almost always because the tool descriptions are ambiguous or overlapping. The model selects based on the description you wrote. If two tools sound similar, it will confuse them — and the fix is clearer descriptions, not a better model.
Reliability degrades as the count grows, typically becoming noticeable somewhere past fifteen or twenty. If you need more, group them behind a router that first narrows to a category, then selects within it.
Structured data the model can reason about, but trimmed to what is needed. Returning an entire database record wastes context and buries the relevant field. Returning a pre-formatted sentence removes the model's ability to combine it with other information.