Tools are what make agents agents. Without tools, you have a chatbot — brilliant at text, incapable of action. With tools, the same model can search the web, run code, query databases, send emails, and control systems. I’ve come to think of tool design as the highest-leverage work in agent building: the tools you give an agent shape its behavior more than the prompts you write.
But “tools” is doing a lot of conceptual work in that sentence. What exactly is a tool, how does a language model actually use one, and what separates good tool design from bad? This guide explains the machinery. For context, see what is an AI agent and the types of AI agents.
Table of Contents
- What Counts as a Tool
- How Function Calling Actually Works
- The Tool Taxonomy
- How Agents Choose Which Tool to Use
- MCP: The USB Standard for AI Tools
- Tool Design Principles
- The Permission Problem
- When Tools Go Wrong
- Frequently Asked Questions
What Counts as a Tool
A tool is any function an agent can invoke to interact with something beyond its own text generation. Formally, it’s a named function with a description and a typed input schema, exposed to the model through the API. Practically, it’s the agent’s hands.
The range is enormous. A calculator tool takes two numbers and returns their sum. A web search tool takes a query and returns results. A code execution tool takes a program and returns its output. An email tool takes recipients, subject, and body — and sends an actual email. A robotic control tool takes movement commands and moves physical hardware.
What unites them: the agent doesn’t do these things itself. It requests them by generating a structured function call, and external code executes the request and returns results. The model never touches the web, the database, or the email server directly — it asks, and the tooling layer acts. This separation is both the architecture’s power and its security boundary.
How Function Calling Actually Works
The mechanics, step by step:
-
Tool definitions go into the prompt. When you configure an agent, you provide tool schemas — JSON describing each function’s name, purpose, and parameters. The model sees these as part of its context: “you have these capabilities available.”
-
The model generates a tool call. Instead of (or in addition to) text, the model outputs a structured call:
{"name": "web_search", "arguments": {"query": "current EV battery specs", "max_results": 5}}. Modern models are fine-tuned to produce these reliably. -
Your code executes it. The agent framework parses the call, validates arguments against the schema, and runs the actual function — hitting the search API, querying the database, whatever the tool does.
-
Results return to the model. The tool’s output gets formatted back into the conversation as a “tool result” message. The model reads it and decides the next step: another tool call, or a final answer.
-
The loop continues. This repeats until the model produces a final response instead of a tool call, or hits a step limit.
The elegant part: the model never needs to understand HTTP, SQL, or APIs. It just needs to understand what each tool does (from descriptions) and what arguments it needs (from schemas). The better your descriptions and schemas, the better the model uses the tools — which is why tool documentation is really prompt engineering in disguise.
The Tool Taxonomy
Information tools — the agent’s senses: – Web search and browsing (current information beyond training data) – Document readers (PDFs, spreadsheets, slides) – Database queries (structured organizational data) – API lookups (weather, stocks, product catalogs)
Computation tools — the agent’s scratch paper: – Code interpreters (Python execution for math, data analysis, file processing) – Calculators (reliable arithmetic — models are bad at this unaided)
Communication tools — the agent’s voice: – Email (send, read, draft) – Messaging (Slack, Teams, SMS) – Calendar (schedule, check availability) – Notifications and alerts
Creation tools — the agent’s workshop: – File operations (read, write, organize) – Image generation and editing – Code repositories (commit, branch, PR)
Control tools — the agent’s hands on the world: – Smart home and IoT APIs – Robotic systems – System administration (the scary ones) – Payment transactions (the scariest ones)
Meta tools — tools about tools: – Tool search (finding the right tool from hundreds) – Sub-agent invocation (delegating to specialist agents) – Memory read/write (the agent’s notebook)
The what AI agents are used for landscape maps closely to which tool categories are involved — information work needs retrieval tools, automation needs control tools.
How Agents Choose Which Tool to Use
Tool selection is a reasoning problem the model solves each loop iteration:
Description matching. The model reads tool descriptions and matches them to its current need. “I need current information” → web search. “I need to compute this” → code interpreter. Clear, specific descriptions produce correct selection; vague ones produce creative misfires.
Argument filling. Once a tool is chosen, the model must provide valid arguments — the right types, the required fields, sensible values. Schema design matters enormously here: required vs optional fields, enums constraining choices, examples showing format. Good schemas make correct calls natural.
Sequencing. Complex tasks need tool chains: search → read → analyze → write → send. The model plans these sequences, and errors compound — a bad search poisons everything downstream. This is why tool results need to be informative enough for the model to detect when something went wrong.
The selection failure modes: calling the wrong tool (bad descriptions), calling with bad arguments (bad schemas), calling tools in the wrong order (bad planning), and the classic — calling tools when no tool is needed (the model showing off). That last one is more common than you’d think and a pure cost sink.
MCP: The USB Standard for AI Tools
The Model Context Protocol (MCP), introduced by Anthropic, standardizes how tools are exposed to agents. Before MCP, every tool integration was custom — each agent framework had its own way of defining and calling functions. MCP provides a common protocol: servers expose tools, resources, and prompts; clients (agents) discover and use them uniformly.
Why it matters:
Interoperability. A tool built once works with any MCP-compatible agent. No more rebuilding integrations per framework.
Ecosystem effects. Standard interfaces create markets — tool marketplaces where developers publish MCP servers and agent builders plug them in. The ecosystem is growing fast.
Security model. MCP includes a permission framework: servers declare what they can do, clients request scoped access, users approve. It’s not perfect, but it’s better than the ad-hoc permission handling it replaces.
The analogy holds. USB didn’t make peripherals better; it made them composable. MCP is doing the same for agent capabilities — and composability is what turns individual tools into an ecosystem.
Tool Design Principles
From watching agents succeed and fail with tools, the principles that matter:
1. Narrow scope. Each tool should do one thing well. A “database tool” that can read, write, delete, and reconfigure is a liability; separate read and write tools with different permissions. Narrow tools are easier for models to use correctly and safer when misused.
2. Descriptive names and docs. The model only knows what you tell it. “get_weather” with a description “Returns current weather and forecast for a location” gets used correctly. “util_v2” with no description gets used creatively and badly.
3. Informative errors. When a tool call fails, the error message goes back to the model — it’s the model’s only feedback. “Error 400” is useless; “Invalid date format — expected YYYY-MM-DD, got ‘tomorrow'” lets the model self-correct. Good error messages are a reliability multiplier.
4. Idempotency where possible. Tools that can safely run twice (reads, searches) versus tools that can’t (sends, charges, deletes). Design irreversible tools to require confirmation, and make the confirmation part of the tool flow, not an afterthought.
5. Sensible defaults. Required parameters should be truly required; everything else gets smart defaults. Every required field is a chance for the model to hallucinate a value.
6. Result formatting. Tool outputs should be structured for model consumption — not raw API dumps. Summarize, highlight the relevant fields, flag anomalies. The model reasons better on clean inputs.
7. Rate limiting and cost awareness. Tools that hit paid APIs need budgets. An agent in a loop with an expensive tool and no limit is a billing incident waiting to happen.
The Permission Problem
The deepest issue in agent tools: the model can’t distinguish “can” from “should.” If a tool is available, the model may use it — including in situations where a human would recognize the request as inappropriate, mistaken, or malicious.
This is why production tool design is really permission design:
- Read vs write separation. Most agents need broad read access and narrow write access. Enforce this at the tool level, not the prompt level.
- Confirmation gates. Irreversible actions (send, delete, purchase, publish) require explicit user confirmation. Not a prompt instruction — a system-enforced gate the model cannot bypass.
- Scope limitation. Tools restricted to specific resources: “read files in /project/docs” not “read files.” The narrower the scope, the smaller the blast radius.
- Audit everything. Log every tool call with arguments, results, and the reasoning that led to it. You can’t secure what you can’t see.
The principle: tools define the agent’s power; permissions define its safety. Most agent security failures I’ve studied trace to tools with excessive permissions, not to clever attacks.
When Tools Go Wrong
Tool confusion. With many similar tools, the model picks wrong ones — using the dev database tool instead of prod, the send-email tool instead of draft-email. Mitigation: distinct names, clear descriptions, and confirmation gates on the dangerous variants.
Argument injection. Malicious content in tool results that manipulates subsequent tool calls — a form of indirect prompt injection through the tool channel. Mitigation: treat tool outputs as untrusted data, validate arguments before execution.
Runaway loops. The agent calls tools repeatedly without progress — searching the same query, retrying the same failing call. Mitigation: loop detection, step limits, and escalating to the user when stuck.
Unexpected side effects. Tools that do more than their description suggests — a “get user info” tool that also logs access, a “search” tool with side effects. Mitigation: audit tool implementations, prefer tools you control.
Dependency failures. The tool’s backend goes down, changes its API, or returns garbage. The agent’s reliability is bounded by its least reliable tool. Mitigation: status checks, fallbacks, and graceful degradation.
Frequently Asked Questions
Tools are functions an AI agent can invoke to interact with the world beyond text generation — web search, code execution, database queries, email, file operations, APIs. Each tool has a name, description, and input schema; the model generates structured function calls, external code executes them, and results return to the model for its next decision.
Tool schemas are included in the model’s context. The model outputs a structured call (function name + arguments), the agent framework validates and executes it, and the result returns as a message the model reads before deciding its next step. This loop repeats until the task completes or hits a step limit.
The Model Context Protocol (MCP) is an open standard for exposing tools to AI agents — like USB for AI capabilities. Servers expose tools uniformly; any MCP-compatible agent can discover and use them. It enables interoperability, tool marketplaces, and a standardized permission model.
Narrow scope (one thing per tool), descriptive names and documentation, informative error messages, idempotency where possible, sensible defaults, model-friendly result formatting, and rate limiting. Most importantly: separate read from write tools, gate irreversible actions behind confirmation, and scope permissions to least privilege.
Tools multiply both capability and blast radius: wrong-tool selection, argument injection via malicious tool outputs, runaway loops burning budget, unexpected side effects, and dependency failures. The core issue is permissions — models can’t distinguish ‘can’ from ‘should.’ Mitigate with least-privilege scoping, confirmation gates, and comprehensive audit logging.
