What Is Tool Calling?
Tool calling, also called function calling, is the mechanism by which a language model asks the application around it to run an external function, such as a database query, an API request or a calculation, and then uses the result. The model does not execute anything itself. It emits a structured request naming a tool and its arguments, the application or the model provider runs it, and the output goes back to the model as input to its next step.
Updated
What is tool calling?
Alone, a language model cannot look up a balance, check an order or send an email. Research showed models could learn to use tools: Toolformer (Schick et al., 2023) trained a model to decide which APIs to call, when, and with what arguments, and ReAct (Yao et al., 2022) interleaves reasoning with actions that "interface with external sources, such as knowledge bases or environments."
Model providers then built the pattern into their APIs. OpenAI's function calling guide describes it as a way for models "to interface with external systems and access data outside their training data." Anthropic's tool use docs separate client tools, which "run in your application," from server tools such as web search, which "run on Anthropic's infrastructure."
The Model Context Protocol (MCP), which Anthropic open-sourced on November 25, 2024, standardizes the other side: how tools are offered. Its tools specification "allows servers to expose tools that can be invoked by language models," so one server works with any compliant client. The current revision, 2026-07-28, made the protocol stateless, removing the initialize handshake and protocol-level sessions. Servers that need state across calls now "use explicit, server-minted handles passed as ordinary tool arguments."
How tool calling works
OpenAI's guide lists five steps:
- 1.Make a request to the model with tools it could call.
- 2.Receive a tool call from the model.
- 3.Execute code on the application side with input from the tool call.
- 4.Make a second request to the model with the tool output.
- 5.Receive a final response from the model (or more tool calls).
An illustrative exchange (exact shapes vary by provider):
Tool definition sent with the request
name: get_available_balance
description: Available balance for one account, with the time it was read
parameters: { "account_id": string }
The model's tool call
get_available_balance({ "account_id": "acc_481" })
The result the application sends back
{ "available": 1240.00, "currency": "USD",
"as_of": "2026-10-19T14:02:11Z", "version": 98213 }The description does real work. Anthropic's docs say the model "determines when to call a tool based on the user's request and the tool's description." A model can also request several tools in one turn, which Anthropic's docs call parallel tool use, and the loop repeats until the model answers without asking for another.
Why tool calling matters in real-time systems
A tool call that reads data is a read, and its result has an as-of time. The model then reasons over that result, often alongside results from other tools, before it answers or acts. Three things follow.
Results age in the context window. The balance read at 14:02:11 is a snapshot. By the time the model concludes "approve," other writes may have changed it. Unless the tool says so, nothing in the result tells the model when its data was current, which is why the example returns as_of and version.
Parallel calls can read different moments. If one tool reads the ledger directly and another reads a risk score that a pipeline refreshes every few minutes, the model combines two moments that never existed together. Tools that serve one decision should read from one consistent snapshot, or at least report their freshness so the gap is visible.
Action tools should re-check, not trust. A tool that writes, such as issue_refund, should take the version the decision was based on and fail if the state has moved, rather than act on the earlier read. It should also be safe to repeat, since a model can issue the same call twice. MCP lets a server mark tools with hints such as readOnlyHint and idempotentHint, but its schema says these are "not guaranteed to provide a faithful description of tool behavior," so the guarantee has to live in the tool.
How a fact can be wrong before it reaches the model is covered in context rot vs. context lag.
FAQ
Related terms
An agent handoff transfers an in-progress task from one AI agent to another. What has to move with it: the conversation, the task's state and authority to act.
Context lag is the delay between a fact changing at its source and the system an automated decision reads from reflecting it. Also called stale context.
Shared context means every service and agent in a decision system reads one internally coherent snapshot of state, instead of private copies that diverge.
Idempotency means an operation has the same effect whether applied once or many times. Covers its math origin, HTTP methods, and API idempotency keys.
A race condition occurs when a system's outcome depends on the timing of concurrent operations, letting interleaved reads and writes corrupt shared state.
Decision context is everything an automated decision reads and everything earlier decisions committed, as it stands at the moment the decision executes.
Agent context is everything an AI agent step reads before it acts: prompt and history, tool results, retrieved documents and the live state it depends on.
Agent hijacking is an attack that redirects an AI agent to an attacker's goals through instructions hidden in content it reads, such as a web page or email.