How AI Agents Use Tools: Function Calling, Tool Design, and Real-World Examples

A language model on its own is a reasoning engine with no hands. It can think about a problem with impressive depth, but it cannot look anything up, send anything, modify anything, or run anything. Tools are how agents get hands. Here is exactly how that mechanism works, what good tool design looks like, and what the research tells us about how models learn to use tools effectively.

What a Tool Is

A tool, in the context of an AI agent, is any callable function that the agent can invoke to interact with the world outside the language model. A tool might be a search engine query, a database lookup, a weather API call, a calculator, a code executor, a file reader, an email sender, or a web scraper. The defining property is that the function takes inputs, does something in the external world, and returns a result that the agent can reason about.

Tools are the boundary between the language model and the real world. Everything inside that boundary is text that the model reads and generates. Everything outside it is state that changes when a tool is called. A search tool does not change state: the search index is the same before and after. An email-sending tool does change state: the email exists in the world after the tool is called in a way it did not before.

This read-write distinction matters enormously for how agents should be designed and what oversight is required. Read operations are reversible. Write operations often are not. The architecture of the agent's tool layer should reflect this difference clearly: read tools can generally be called freely by the agent, while write tools should be subject to more stringent conditions, validation steps, and potentially human review before execution.

How Function Calling Works

The technical mechanism for giving an agent access to tools is called function calling, sometimes also referred to as tool use. In function calling, each tool is described to the language model as a JSON schema that specifies the tool's name, a natural language description of what it does, and the parameters it accepts with their types and descriptions.

When the model determines it needs to use a tool, it outputs a structured call specifying the tool name and the argument values. The surrounding infrastructure executes that call, gets the result, and feeds the result back to the model. The model then continues its reasoning with the new information.

Here is what a tool definition looks like for a weather lookup tool:

{
  "name": "get_current_weather",
  "description": "Get the current weather conditions for a city.
    Use this when the user asks about current weather or temperature.
    Do not use this for historical weather data.",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "The city name, e.g. 'San Francisco'"
      },
      "unit": {
        "type": "string",
        "enum": ["celsius", "fahrenheit"]
      }
    },
    "required": ["city"]
  }
}

The description field is the most important part of a tool definition. It is what the language model reads to decide whether to use this tool and how. A vague description like "gets weather" produces worse tool selection than a specific description that explains what the tool does, when to use it, and when not to use it. The extra sentence "Do not use this for historical weather data" prevents the model from calling a live-data tool when the user is asking about a historical event.

When the model decides to use a tool, it outputs something like this:

{
  "tool": "get_current_weather",
  "parameters": {
    "city": "San Francisco",
    "unit": "fahrenheit"
  }
}

The infrastructure receives this, calls the weather API with those parameters, gets back a result like "68 degrees Fahrenheit, partly cloudy," and feeds that back to the model as an observation. The model continues its reasoning with this new information, treating the tool result as ground truth about the current state of the world.

The description field is not documentation. It is the agent's only guide for deciding when and how to use each tool. Every sentence in it shapes behavior at inference time.

The Three Tool Categories

Tools fall into three broad categories based on how they interact with external state. Understanding which category a tool belongs to shapes how you design the agent that uses it and what safeguards are appropriate.

Read-Only Tools

Read-only tools retrieve information without changing anything. A web search, a database query, a document retrieval, a weather lookup, a price check: all of these read state from the world without modifying it. If the tool produces a bad result or is called with wrong parameters, the consequence is a wrong piece of information, not a changed state. Read-only tools are safe to call freely because their mistakes are recoverable.

Read-only tools are also the category most suitable for parallel use. An agent that retrieves five different sources before synthesizing an answer is less likely to reason on incomplete information than one that retrieves only one. The cost is additional latency and context window usage, not additional risk. For research-oriented agents, parallel reads from multiple sources and then synthesis is a consistently high-quality pattern.

Well-designed read-only tools handle the case where no result is found. A search that returns zero results is not an error: it is information. The tool should return a clear "no results found" signal rather than an empty response that the agent might misinterpret. The agent can then try a different query or approach rather than assuming the information does not exist.

Write-Capable Tools

Write-capable tools modify state. They send emails, create records, update databases, post messages, process payments, delete files, or trigger downstream actions in other systems. When a write-capable tool is called, the world is different afterward in a way that may be difficult or impossible to reverse.

Write-capable tools require more careful design and more careful oversight than read-only tools. The parameters should be validated before the call is made. The tool should return a clear success or failure signal. When the action is high-stakes, whether that means sending an external communication, modifying financial records, or deleting data, the design should include a confirmation step or a human approval checkpoint before the tool is actually called.

One practical pattern is to give the agent a draft version of write-capable tools. A draft_email tool that creates a draft email without sending it allows the agent to compose and review before committing. The agent can call send_email as a separate step, potentially with a human review between the two calls. The same pattern applies to document creation, database modifications, and any other write operation where reviewing the intended change before committing adds safety without excessive friction.

Code Execution Tools

Code execution tools allow the agent to write and run programs, typically in a sandboxed environment. The agent writes code to perform a calculation, transform data, generate a chart, analyze a dataset, or test a hypothesis, runs it, and reads the output. This category is the most powerful and the most demanding from an infrastructure perspective: it requires a secure sandbox, resource limits, and careful monitoring of what the code is doing.

Code execution is particularly valuable for numerical tasks, where language model arithmetic is unreliable, data transformation tasks, where writing a one-off script is faster than designing a dedicated tool, and verification tasks, where the agent can check its own outputs by running them. An agent that generates code and can run it immediately to verify whether it works is substantially more reliable than one that only generates code for humans to run.

How Toolformer Changed Our Understanding of Tool Learning

Until 2023, the prevailing assumption was that teaching a language model to use tools required extensive human-labeled examples of correct tool use: a dataset showing the model the right tool to call for each type of query. Schick et al. (2023) challenged this with Toolformer, a method that enables models to learn when and how to call tools through self-supervised training on a small number of human-annotated examples (arXiv:2302.04761).

The core insight of Toolformer is that a model can generate candidate tool-use examples for itself. The model first produces a text about a topic, then samples possible tool calls that could be inserted into that text: a Wikipedia lookup here, a calculator call there, a translation request somewhere else. The tool calls are actually executed, and the ones that produce results that help the model predict subsequent text are kept as training examples. The ones that do not help are discarded.

This self-supervised approach dramatically reduces the human annotation burden. The result is a model that learns to use tools appropriately in context, calling a calculator for arithmetic rather than attempting the arithmetic itself, calling a search tool for current events rather than generating an answer from training data that may be outdated.

Toolformer demonstrated that models can be reliable about when to use tools, not just how. The when decision is actually harder than the how decision: a model that always calls a search tool is correct at using the tool but wasteful and slow. A model that knows to call the search tool when its own knowledge might be stale or incomplete, and to rely on internal reasoning when the question is one it can answer reliably, is genuinely more capable and more efficient.

Parallel Tool Calling

In the basic function calling model, the agent calls one tool, waits for the result, and then decides what to do next. This sequential pattern is correct when the next tool call depends on the result of the current one. But many tasks involve tool calls that are independent of each other, and for those, calling tools in parallel rather than in sequence reduces latency substantially.

An agent researching three companies for a competitive analysis can search for all three simultaneously rather than waiting for the first search to complete before starting the second. An agent checking the status of five customer orders can query all five in a single batch. An agent that needs weather data, stock prices, and news headlines for a morning briefing can fetch all three concurrently.

Most modern agent frameworks support parallel tool calling. The mechanism is that the model outputs multiple tool calls in a single reasoning step, the infrastructure executes them concurrently, and the results are all fed back together for the model's next reasoning step. The agent writes one Thought that identifies multiple needed pieces of information, gets all of them at once, and then writes its next Thought with the full set of information available simultaneously. This pattern reduces the total number of round trips between the model and the infrastructure, which is where most of the latency in agent tasks comes from.

Tool Reliability and Failure Handling

Tools fail. APIs return errors. Network timeouts occur. Search results come back empty. Rate limits are exceeded. A well-designed agent has explicit handling for each of these cases rather than treating tool failures as unexpected exceptions that the system does not know how to handle.

The core principle is that every tool call should produce a result the agent can reason about, including failure results. A search that returns no results is not an error: it is information. The agent should be able to reason: "The search returned no results. I should try a different query rather than concluding that no information exists." An API that returns a 429 rate-limit error is telling the agent to slow down and retry, not to give up.

Tool failure handling is also where the minimal footprint principle applies most directly. An agent that cannot complete a subtask should report what it attempted and what failed, rather than silently skipping the subtask or generating plausible-sounding information to fill the gap. Transparency about what was and was not accomplished allows humans reviewing the agent's output to identify where it is incomplete and to take appropriate action.

Writing Tool Descriptions That Actually Work

The quality of tool descriptions is one of the highest-leverage variables in agent performance. A poorly described tool gets called at the wrong time with wrong parameters. A well-described tool gets called exactly when it should be, with correct parameters, and its output gets interpreted correctly.

Effective tool descriptions have four properties. First, they say what the tool does in concrete terms. "Retrieves the current bid and ask price of a US equity given its ticker symbol" is better than "gets stock information." Second, they say when to use the tool: "Use this when the user asks about current market price. Do not use this for historical prices or for options data." Third, they describe the output format: "Returns a JSON object with fields: price (float, USD), timestamp (ISO 8601), change_pct (float, 24-hour change percentage)." Fourth, they note important constraints: "Only supports US equities listed on NYSE or NASDAQ. International stocks and OTC securities will return an error."

These descriptions do not need to be long. They need to be precise. A tool description that is ten lines of clear, specific guidance produces better agent behavior than two paragraphs of vague language. Every sentence should tell the model something it could not reliably infer on its own. Precision in description translates directly to reliability in tool selection.

Tool design is one of the highest-leverage places to invest time when building an agent. The model can only be as good as the tools available to it, and the tools can only be used as well as their descriptions allow. The Tool Use module in the AI Agents course covers this in depth with interactive exercises and real function calling examples.

One final point on tool selection: the number of tools available to an agent should be kept to the minimum needed for the task. Giving an agent access to fifty tools when the task requires five does not make the agent more capable; it makes the tool selection decision harder and increases the probability of the agent choosing the wrong tool or attempting to use a tool it does not need. Start with the minimal tool set, add tools when a specific capability gap is identified in practice, and retire tools that are not being used. A lean, well-described tool set produces more reliable agent behavior than a broad tool set with mediocre descriptions.