What Is Tool Calling? How AI Models Use External Tools

What is tool calling?

Tool calling is a model's ability to request an external action instead of only writing text. You describe the tools available, and the model chooses when to use one and what inputs to pass.

The key idea is a division of labour. The model decides and formats, and your application executes. When the model wants the weather, it does not fetch it. Instead it emits a structured request such as "call get_weather with city: Nairobi," and your code makes the actual call.

That structured request is the whole point. It turns a fuzzy natural-language intent into a precise, machine-readable instruction your systems can run safely.

Tool calling vs. function calling vs. tool use

These three terms describe the same capability. The differences are branding, not mechanics.

Term	Who uses it	Notes
Function calling	OpenAI (introduced the API pattern in 2023)	The modern API uses tools and tool_choice. A function is one kind of tool, defined by a JSON schema.
Tool use	Anthropic (Claude)	Distinguishes client tools (your app executes) from server tools (the provider executes).
Tool calling	Industry-wide	The umbrella term, interchangeable with the two above.

In every case the flow is identical. You define a tool with a schema, the model returns structured arguments, your code runs the action, and the result goes back to the model. If you see any of these terms in the wild, read them as the same thing. For a short definition, see the function calling glossary entry.

Why tool calling matters

A model on its own is frozen at its training cutoff and cannot touch your systems. Tool calling removes both limits.

It gives a model live data (prices, inventory, a user's records), actions (send an email, file a ticket, run a query), and grounding (answers backed by retrieved facts rather than memory). This is what separates a demo chatbot from a system that does real work.

Nearly every advanced AI pattern is built on it. Agents, retrieval workflows, and structured extraction all depend on the model reliably choosing and calling the right tool.

How tool calling works

The mechanics are a short loop between your application and the model. There are four steps.

1. You define tools. Each tool has a name, a plain-language description, and a JSON schema for its inputs. The description matters, because it is how the model knows when the tool applies.
2. The model decides. You send the user's request plus the tool definitions. The model either answers in text or returns a structured tool call with arguments.
3. Your code executes. You parse the call, run the real function, and capture the result. The model has no access to your code, so you are always in control of execution.
4. The model responds. You return the result, and the model uses it to write the final answer, or to call another tool, which starts the loop again.

That final branch is what makes agents possible. A model that can call a tool, read the result, and decide the next call can chain many steps toward a goal.

A minimal example

Here is a single tool defined as a JSON schema, the canonical "get the weather" example:

{
  "name": "get_weather",
  "description": "Get the current weather for a city.",
  "parameters": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "City name, e.g. Nairobi" }
    },
    "required": ["city"]
  }
}

And here is the loop in provider-neutral pseudocode:

tools = [get_weather_schema]
# 1) The model decides whether to call a tool.
response = model.chat(messages, tools=tools)
# 2) If it asked for a tool, YOUR code runs it.
if response.tool_calls:
    for call in response.tool_calls:
        result = run_local(call.name, call.arguments)
        messages.append(tool_result(call.id, result))
    # 3) The model uses the result to write the final answer.
    final = model.chat(messages, tools=tools)

Notice that run_local is your function, not the model's. The model only produced the instruction, and execution stayed on your side.

Tool calling vs. MCP

Tool calling and the Model Context Protocol are often confused, but they solve different problems.

Tool calling is the model capability — the model deciding to call a tool. It is implemented per provider, so an OpenAI tool schema and an Anthropic tool schema differ in shape.

MCP is a standard layer on top. It defines one common way to expose tools so any model can use them, which means you build a tool once instead of re-wiring it for each provider. For a hands-on build, follow our tutorial on bridging Claude and a local model with MCP.

In short: tool calling is what the model does, and MCP is how you standardize the tools it calls.

Where tool calling appears

Once you know the pattern, you will see it everywhere in production AI.

It powers AI agents that plan and act, RAG systems where retrieval is exposed as a tool, structured extraction that returns validated data, and support bots that look up orders or file tickets. Coding assistants use it to read files and run commands, and analytics assistants use it to query databases.

The common thread is simple. Any time an AI feature needs current data or a real action, tool calling is doing the work underneath.

Tool-choice modes

You do not have to leave every decision to the model. A tool_choice setting controls how freely it may call tools.

Setting	Behavior
auto	The model decides whether and which tool to call. The common default.
required	The model must call a tool (useful when an action is mandatory).
none	No tools. The model answers in text only.
specific	Force a named tool (useful for deterministic extraction).

Some models also support parallel tool calls, returning several calls at once so your app can run them together. Reach for the stricter modes when correctness matters more than flexibility.

Common mistakes

Most tool-calling failures trace back to a handful of avoidable errors.

The frequent ones:

• Too many or overlapping tools, so the model gets confused about which to pick.
• Vague descriptions, so the model cannot tell when a tool applies.
• Not validating arguments before execution.
• Forgetting to handle errors and retries.
• Assuming the model executes the tool itself.

Fixing these is mostly discipline. Keep the tool set small and distinct, write descriptions as if for a new teammate, and validate every argument as untrusted input.

Risks and limitations

Tool calling is powerful precisely because it lets a model trigger real actions, which is also its main risk.

Security is the headline concern. A model can be steered by prompt injection or a malicious tool description into calling a tool with harmful arguments, so treat every tool call as an action that needs authorization and validation. We cover this attack class in our guide to MCP security and tool poisoning.

There are practical limits too. Calls can carry wrong or hallucinated arguments, latency grows with each round-trip, cost rises with the extra tokens, and smaller models (under about 7B parameters) select tools unreliably. Validate outputs, cap the loop, and test on a representative workload before trusting it in production — the evidence-first approach we apply across ModelRefs methodology.

Sources and further reading

• OpenAI, Function calling — confirms function calling and tool calling are the same capability, the JSON-schema tool pattern, and tool_choice modes.
• Anthropic, Tool use with Claude — client tools (your application executes) versus server tools, and the structured-call model.