What Is Tool Calling in AI Agents

What is tool calling in AI agents? It is what happens when an AI model, instead of only writing text, outputs a structured request naming a function and the arguments to run it, then waits while your code executes that function and returns the result. A language model cannot query a database or run code on its own; describing a function as a small schema, then letting the model call it when needed, is what closes that gap. This article traces one real call from schema to finished reply.

What Is Tool Calling in AI Agents: A Worked Example From Schema to Response

Most explanations of tool calling stop at the diagram: decide, call, run, answer. Here is what actually crosses the wire, using the format from Claude's tool use guide; it transfers directly to other providers.

Tool Calling Explained in Four Steps

Every tool call, regardless of vendor, moves through the same four steps.

1. Define the tool as a schema.

2. The model responds with a structured call, not prose.

3. Your application executes the function.

4. You send the result back and the model answers.

Step 1: Define the Tool Schema

Say you are building a support agent that checks order status. The description field matters more than people expect: it is the main thing telling the model when this tool is relevant.

{
  "name": "get_order_status",
  "description": "Look up the current shipping status of a customer's order using its order ID.",
  "input_schema": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "description": "The order identifier shown on the customer's receipt, e.g. ORD-48213"
      }
    },
    "required": ["order_id"]
  }
}

Step 2: The Model's Structured Tool-Call Output

When a customer asks where order ORD-48213 is, the model has no idea. Its response comes back with a stop reason for a tool call, and the content includes a tool_use block naming the tool and its inferred arguments.

{
  "type": "tool_use",
  "id": "toolu_01A9q9CvZk2m7Rn3xLPq8T2j",
  "name": "get_order_status",
  "input": {
    "order_id": "ORD-48213"
  }
}

Notice the id. It tells the next request which result belongs to which call, and it matters once an agent has several calls in flight at once.

Step 3: Your Code Executes the Tool

Nothing about the model's output runs by itself. Your application reads name and input, calls the real get_order_status(order_id) function, and catches whatever it throws; the model only sees the string you return.

Step 4: The Result Goes Back to the Model

You send a new request with the conversation so far, plus a tool_result block that references that id as tool_use_id, with the actual output as its content.

{
  "role": "user",
  "content": [
    {
      "type": "tool_result",
      "tool_use_id": "toolu_01A9q9CvZk2m7Rn3xLPq8T2j",
      "content": "Order ORD-48213 shipped on August 9 via UPS and is expected to arrive August 13. Tracking number 1Z999AA10123456784."
    }
  ]
}

The model reads that result and writes the reply a human actually sees.

Your order ORD-48213 shipped on August 9 via UPS and should arrive by August 13. You can track it with number 1Z999AA10123456784.

That is the entire mechanism: two requests, one structured call, one answer. Agentic behavior is this loop run repeatedly, with several calls sometimes chained together.

Function Calling vs Tool Calling

The terminology split is mostly historical: OpenAI called this function calling, OpenAI's current API and Anthropic now say tool calling, since a tool can also mean a hosted web search. Same loop, different field names.

What is tool calling in AI agents comes down to those five fields, however a provider names them. Learn one implementation and the rest read like a dialect.

How AI Agents Use Tools in Practice

A single tool call rarely makes an agent. Chaining does: the model calls a tool, reads the result, decides it needs more, and only then answers, looping until enough or a step limit stops it.

• A coding agent reads a file, edits it, then runs tests as three calls.

• A research agent searches, then fetches top results, before summarizing.

• A support agent looks up an account, then an order, using two narrow tools instead of one that does everything.

Providers can also constrain this: a tool choice setting can require, forbid, or cap calls per turn, and strict mode validates output against your schema first.

Why the Schema Is the Part People Get Wrong

The mechanism above is simple. The failure mode almost never is. Most tool-calling bugs trace back to the schema, not the model.

• Vague descriptions: an undocumented tool named search gets called at the wrong moments, or not at all.

• Loose types: an untyped date field invites next Tuesday instead of something parseable.

• Missing required fields: leave required off and the model omits arguments your function needs.

• Silent failures: an empty string on error leaves the model guessing.

None of this is exotic: it is the same discipline you would apply to any API meant for a client you cannot fully control, and the model is that client.

Related reading

• the how AI models work pillar

• what a context window is

• what mixture of experts means

• what multimodal AI is

• debugging a prompt that stopped working