Agent Tools: How AI Agents Take Actions

What is it?

On its own a language model can only produce text. A tool is something it can ask your software to do: search the web, query a database, read a file, run code, call a calendar API, send an email. Each tool is presented to the model as a short description — a name, what it does, and the arguments it takes — and the model decides when to use it.

The model never runs the tool. It emits a structured request; your code (or the platform) performs the action and returns the result for the model to read. The request format is described in Function Calling (Tool Calling) Explained; a standard way to package and share tools across applications is What is MCP (Model Context Protocol)?.

Why does it matter?

Tools address the model's built-in limits:

• Stale knowledge → search or retrieval tools.
• Weak arithmetic and exact lookups → calculators, databases.
• Inability to act → APIs that create tickets, send messages, update records.
• Unverifiable claims → tools that fetch the source so answers can cite it.

They are also where most agent risk lives, because tools are what turn model mistakes or manipulated instructions into real-world effects.

How does it work?

Each tool definition typically has:

• a name (search_orders),
• a description that tells the model when to use it,
• an input schema (usually JSON Schema) describing arguments and types.

At run time: the model sees the definitions, chooses a tool and arguments, your code validates and executes, and the result goes back into the context.

Design guidelines:

1. Keep tools narrow and clear. get_order_status(order_id) beats a generic run_sql(query).
2. Write descriptions for the model: purpose, when to use, when not to, units and formats.
3. Return concise, relevant results. Huge outputs waste the context window and distract the model. Return helpful error messages so it can recover.
4. Validate every argument in code. Never trust model-supplied values.
5. Apply least privilege: read-only where possible; scoped credentials; per-user authorisation checked in code.
6. Separate safe from risky. Reading is low risk; writing, deleting, paying and sending need confirmation.
7. Make actions idempotent or reversible when you can, so retries do not duplicate effects.
8. Log calls for audit and debugging.

Example

A tool definition (generic JSON-Schema style; exact wrapper fields vary by provider):

{
  "name": "get_order_status",
  "description": "Look up the shipping status of a customer's order by its ID. Use only when the user provides or confirms an order ID. Read-only.",
  "input_schema": {
    "type": "object",
    "properties": {
      "order_id": { "type": "string", "description": "Order ID such as ORD-10492" }
    },
    "required": ["order_id"]
  }
}

The server-side handler checks that the logged-in user owns order_id before returning anything. That check lives in code, not in the prompt.

When should I use it?

Give a model a tool when the task needs fresh data, exact computation, or a real-world action — and when you can constrain it safely. If the model can already do the job from the prompt text, extra tools only add complexity. Start with the smallest useful toolset; each additional tool is more for the model to choose between, and more surface to secure.

Common mistakes

• Too many overlapping tools, causing wrong selection.
• Vague descriptions. The description is the model's only guide.
• Trusting arguments (SQL, file paths, URLs) without validation.
• Over-privileged credentials.
• Returning raw, enormous payloads.
• Assuming tool output is trustworthy. Content from tools can carry What is Prompt Injection?.

Related concepts