When people ask what separates an AI agent from a plain chatbot, the answer almost always comes down to tool use capabilities — the set of external actions a model can invoke, and how reliably it invokes them. A chatbot produces text; an agent produces text plus structured calls to real functions — searching the web, running code, querying databases, sending messages — and then reacts to the results. Everything that makes agents powerful, and everything that makes them fragile, lives in this mechanism. This guide explains the full mechanism, the standard taxonomy of tools, what makes a tool-use capability good, the failure modes that production teams actually hit, and how to evaluate an agent framework by its tooling rather than its marketing.
Think of tool-use capability as two things bundled together: the inventory of tools an agent can reach, and the reliability of the loop that invokes them. A framework with hundreds of tools and a sloppy loop is usually worse than one with a dozen well-described tools and a disciplined loop.
What “Tool Use” Means for an AI Agent
A tool is an external function exposed to the model through three things: a name, a natural-language description, and a JSON Schema describing its parameters. That is the entire contract. The model never executes the tool itself — it only requests execution. Your code (the runtime, the framework, the server) validates the request, runs the function with its own permissions, and feeds the result back into the model’s context as a new message.
This back-and-forth has a canonical name: the agentic loop, also described as the reason–act–observe cycle. The research community formalized it in the ReAct paper (Yao et al., 2022), which showed that interleaving reasoning traces with actions makes agents both more capable and more inspectable: reasoning helps the model track and update plans and handle exceptions, while acting keeps reasoning grounded in facts returned from tools. ReAct beat baselines by 34 percentage points on ALFWorld and 10 on WebShop — and its plain-text reasoning traces make agent behavior auditable, which is why the pattern survives in production frameworks today.
One point that trips up newcomers: the model does not “know” your tools the way it knows facts. It sees only the name, description, and schema you declared at prompt time. As one practical guide puts it: “Every tool is a JSON Schema description of its parameters. The model reads this schema and decides when each tool is appropriate… The model picks tools based on the description, not the name.” Vague descriptions produce flaky routing; specific descriptions that state when to use the tool route correctly.
How Tool Calling Actually Works
The mechanics are the same across vendors, differing only in message format. Here is the loop, step by step:
1. Call the model with the conversation plus the tool definitions. Tools are declared as JSON schemas alongside the system prompt. A typical declaration looks like this:
{
"name": "web_search",
"description": "Search the public web for current information. Use when the user asks about recent events, prices, or anything outside the model's training data.",
"parameters": {
"type": "object",
"properties": {
"query": { "type": "string", "description": "The search query" },
"max_results": { "type": "integer", "description": "Maximum results to return", "default": 5 }
},
"required": ["query"]
}
}2. Inspect the model’s response for tool-use blocks. Instead of (or before) a text answer, the model may emit a structured call. Anthropic’s format uses typed content blocks — here is one requesting a web search:
// Anthropic-style tool_use block (emitted by the model)
{
"type": "tool_use",
"id": "toolu_01abc",
"name": "web_search",
"input": { "query": "Anthropic IPO governance structure 2026", "max_results": 5 }
}OpenAI’s format attaches tool calls to the assistant message:
// OpenAI-style tool_calls (emitted by the model)
[
{
"id": "call_9f2d",
"type": "function",
"function": {
"name": "web_search",
"arguments": "{\"query\": \"Anthropic IPO governance structure 2026\", \"max_results\": 5}"
}
}
]3. Execute in your own code, with your own validation and permissions. The model never touches your systems directly: every action passes through code you wrote and can audit. You run the function, and you can validate parameters, enforce permissions, and log the call before anything happens.
4. Feed results back as new context. You append the assistant’s turn and a user turn carrying the tool results. Anthropic returns results as tool_result blocks inside a user-role message:
// Anthropic-style tool_result block (sent back to the model)
{
"type": "tool_result",
"tool_use_id": "toolu_01abc",
"content": "Anthropic announced... [search results]"
}OpenAI sends results as tool-role messages:
// OpenAI-style tool result (sent back to the model)
{
"role": "tool",
"tool_call_id": "call_9f2d",
"content": "Anthropic announced... [search results]"
}5. Repeat until done. If the model emits no tool-use blocks, it has produced its final answer and you exit the loop. Otherwise you go around again. Practical implementations set a hard cap — tool loops typically converge in 2–10 iterations, and a cap of 15–20 prevents runaway loops where the model keeps calling tools without converging.
Two details worth knowing: the model can emit multiple tool-use blocks in a single response, and independent calls can run concurrently. And while the runtime enforces the execution controls — stop conditions, retry policies, and permission checks are code — the sequence of tool requests itself stays model-driven and nondeterministic: the model decides whether to request tools and which calls to emit, which is exactly why those limits and gates have to live in your code rather than in the prompt.
The Main Categories of Tool Use Capabilities
Every agent’s capability set maps onto a small taxonomy. Production frameworks usually expose some mix of these:
Information access. Web search, browsing, document retrieval, database queries, API reads. These feed facts into the loop. In the Model Context Protocol (MCP) vocabulary, read-only data can be exposed as resources — context the model can reference without a tool invocation — alongside tools (operations the server performs on the model’s behalf) and prompts (reusable templates).
Computation. Code execution, data analysis, file read/write, transformations. This is how an agent moves from “find the numbers” to “compute the answer.” Note that file and code capabilities blur the read/write boundary, which is exactly why scoping matters.
Action. API calls, messaging, ticketing, deployment operations, purchases. These change the world outside the model’s context, and they are where the failure modes get expensive.
Underneath all three sits the distinction that matters most for safety: read tools versus write tools. Reads are cheap and recoverable; writes are where you need idempotent design, least-privilege grants, human confirmation at irreversible steps, and per-call logging. In production, the dominant pattern is single tool-use followed by human review — broad autonomous write access is the exception, not the rule.
One more architectural layer: MCP is one level of abstraction above vendor tool APIs. OpenAI function calling and Anthropic tool use are model-specific APIs for a single model; MCP is an open standard for exposing capabilities to agents — one protocol replacing per-assistant, per-service custom integrations, where servers expose tools (operations such as running a query or editing a file), resources (read-only data), and prompts (reusable templates). Anthropic open-sourced MCP on November 25, 2024, and its governance moved to the Linux Foundation’s Agentic AI Foundation in December 2025; the official MCP registry listed 6,400+ servers as of February 2026.
What Makes Tool-Use Capabilities Good
Tool quality is the highest-leverage variable in agent reliability. A checklist, derived from what actually goes wrong in practice:
Precise names, descriptions, and schemas. The model only knows what you tell it. Descriptions should state when to use the tool and what it returns, not just what it does. Overlapping or vague descriptions across tools are a common cause of wrong-tool selection, and the risk grows as tool counts rise — recall the ~30–50 tool ceiling where selection accuracy degrades.
Idempotent, side-effect-aware design for write tools. A write tool that can safely be called twice (or that detects prior execution) survives the retry loops and duplicate emissions that real agents produce.
Useful error messages the model can recover from. An error that says “invalid parameter: max_results must be between 1 and 20” lets the loop correct itself; “bad request” sends it into a spin.
Least-privilege scoping. Each tool should hold only the permissions its job requires. An agent that can read a database does not need the same grant as one that can drop a table — and the read/write split from the taxonomy above should be enforced in grants, not just in documentation.
Observability of every call. Per-call logging — which tool, which parameters, which result, how long it took — is what turns a mysterious agent failure into a debuggable one. ReAct’s reasoning traces help, but they do not replace call logs.
A useful scale heuristic: Claude’s ability to pick the right tool degrades once you exceed roughly 30–50 available tools. A five-server MCP setup can inject around 55,000 tokens of tool definitions into context before any work happens — mitigated by tool search, which cuts that overhead by more than 85%. The lesson is not “fewer tools” but “better selection”: precise descriptions plus search or routing layers beat dumping the entire registry into the prompt.
Common Failure Modes and Limits
Simulations of production agents surface the same repeatable failures, and they are worth recognizing by their signatures in logs:
Ambiguous tool descriptions → wrong parameter choices. The agent calls the right tool with the wrong arguments, or a near-duplicate tool that does something subtly different. In logs this looks like correct intent, wrong execution.
Missing error handling → infinite retry loops. A tool fails, the model retries the identical call with identical parameters, and the loop burns through its iteration cap. Fixed by stop conditions on repeated failure and by error messages the model can act on.
Over-permissioned tools → unsafe or unintended side effects. Evaluations of production-style agents have found models taking unintended actions when tool grants were broader than the task required. The fix is the read/write discipline: least-privilege grants, confirmation gates at irreversible steps.
Context bloat from verbose tool outputs. Tool results are context, and context is finite. A search tool that returns full page dumps will crowd out the reasoning the agent needs to use the results. Truncation and summarization of verbose outputs keep the loop lean.
Evaluation gaps. Tool-use reliability deserves explicit measurement as its own quality dimension. The research records that 88% of agent pilots never reach production, with evaluation gaps, governance friction, and model reliability among the leading blockers — a reminder to check whether your own evaluations probe ambiguous tool choices and permission boundaries, not just the happy path. The failure modes above give you the adversarial cases to start with.
Tool Use in Practice: Evaluating an Agent Framework
When you compare frameworks, compare the tooling, not the marketing. Here is what to check:
The tool registry. How are tools declared, versioned, and discovered? Is there schema validation before execution, or does validation happen only when the tool itself errors? Can descriptions be tuned without redeploying the agent?
Schema validation and execution controls. Does the framework validate parameters against the declared schema before calling your code? Does it support retries with backoff, timeouts, and concurrency for parallel tool-use blocks?
MCP support. Can the framework consume MCP servers (tools, resources, prompts) rather than requiring bespoke integrations for every service? MCP is now the closest thing the ecosystem has to a standard, and a framework that cannot speak it will cost you per-integration work.
Testing hooks. Can you record and replay tool calls, inject tool results, and run the loop against a mock registry? Agent behavior is nondeterministic; deterministic tool stubs are how you make it testable.
The summary formula: tool-use capability = the set of tools + the reliability of the loop. Evaluate the loop with adversarial cases — ambiguous descriptions, failing tools, permission edges — and evaluate the set with the taxonomy above. A framework that scores well on both is one you can actually build on.
Tool use is the difference between a model that talks about the world and an agent that operates in it. Get the mechanism right, describe tools precisely, scope writes tightly, and measure the failure modes instead of the demo — and the capability stops being a party trick and becomes infrastructure.
