Tool calling

Tool calling is the mechanism by which a language model requests an external function, API or command through a structured interface, with the surrounding application responsible for invoking it and returning the result. A tool call represents a requested operation, not proof that the operation succeeded.

A language model can process whatever content it is given, including files, query results and messages placed in its context. What it cannot do by itself is reach outside that context to fetch, change or send anything. Tool calling is the convention that lets software act on a model's behalf: the model states, in a structured form, which operation it wants and with which arguments, and other software decides whether and how to carry that out. It is what turns a model into the working part of an AI agent.

How a tool call works

The major model APIs implement the same round trip, with different field names.

1. The application describes its tools. Each tool has a name, a plain-language description, and a schema for its parameters, usually JSON Schema. The descriptions matter: together with the schema, they are what the model has to go on when choosing a tool.
2. The model decides whether to use one. The model receives the tool descriptions and parameter schemas, often alongside developer instructions, the conversation so far and the results of earlier tool calls. It either answers in text or emits a tool call: the name of a tool and a set of arguments that should satisfy its schema. It may emit several at once.
3. The application handles the request. The software around the model, the agent harness, receives the call. It can validate the arguments, check permissions, ask a person, run the tool, or refuse.
4. The result goes back to the model. Normally a result is returned as a new message: the tool's output, or an error. That is not assured. Execution or communication can fail before any usable result reaches the model, and the harness then decides what the model is told. When a result does arrive, the model reads it and chooses its next step.

Repeated, this round trip is the agent loop.

In a provider-neutral form, the three messages look like this.

The tool definition:

{
  "name": "run_command",
  "description": "Run a shell command in the project directory and return its output.",
  "parameters": {
    "type": "object",
    "properties": { "command": { "type": "string" } },
    "required": ["command"]
  }
}

The model's tool call:

{ "id": "call_01", "name": "run_command", "arguments": { "command": "pytest tests/test_dates.py -q" } }

The result the application returns:

{ "tool_call_id": "call_01", "content": "1 failed, 3 passed", "is_error": false }

The details differ by provider. Anthropic's API returns a tool_use content block and expects a tool_result block in reply. OpenAI's APIs return the function name with its arguments encoded as a JSON string. The shape of the exchange is the same.

One distinction is worth knowing. Most tools are executed by the developer's own application. Some providers also offer built-in tools, such as web search or code execution, that run on the provider's infrastructure and return results directly. The model's role is identical in both cases. What changes is which party executes the call, and therefore where a record of it can be made.

A request, not an effect

The most important property of a tool call is easy to miss: it is a request. Between the model emitting a call and anything changing in the world, several things can happen.

• The harness can refuse the call, because of a permission rule, a guardrail or a person declining it. The Model Context Protocol specification says applications should keep a person able to deny tool invocations.
• The arguments can be wrong. A model can produce arguments that do not match the schema, or that match it and still name a file, a record or an endpoint that does not exist.
• The tool can fail, time out, or partly succeed.
• The result can mislead. The model sees only what the tool returns. Truncated output or a swallowed error leaves the model reasoning from an incomplete picture.

A tool call therefore establishes that an operation was requested, and with which arguments. Whether the operation ran, and what it changed, are separate facts that need separate evidence: the tool's result, the state of the target system, or both.

The tool name is not the operation

Tools vary enormously in how much their name tells you. A call to get_weather does one thing. A call to run_command, to a generic HTTP tool or to a database tool can do almost anything, because the operation lives in the arguments.

In the example above, the same run_command tool that ran pytest could equally carry rm -rf build/ or a cloud command that deletes infrastructure. A record that says only "the agent called run_command" is accurate and tells a reviewer very little. This is why general-purpose tools, which are the most useful ones for agents, are also the hardest to reason about from the tool name alone. Semantic action classification is one response: describing a shell command by its potential effects rather than by the tool that carried it.

Often confused with

Function calling. Function calling and tool calling overlap, and usage differs between providers. Function calling was the original name for the capability in which a model returns a function name and structured arguments. Tool calling is commonly used as the broader term, covering developer-defined functions, built-in provider tools and tools supplied through protocols. Many people use the two interchangeably, and in most conversations nothing is lost by doing so.

The Model Context Protocol. The Model Context Protocol standardizes how AI applications connect to external systems. Tools are one of three things its servers expose, alongside resources and prompts. Tool calling is the model-side mechanism, and the protocol is one way tools reach the application that offers them to the model. An agent can call tools with no protocol involved, and the protocol remains useful without tool calling, since resources and prompts can be supplied to an application directly.

Structured output. Asking a model to reply in a fixed JSON shape uses similar machinery, since both constrain the model's output to a schema. The difference is intent: structured output is data for the application to read, while a tool call is a request for the application to do something.

Tool use. A synonym. Some providers and papers say tool use, others tool calling. Toolformer is one influential early formulation of models learning when to call external tools.

Why tool calls matter for governance

For agents that act on external systems, tool calls are a major execution boundary, though not the only possible one: a harness can also act on a model's output directly, without a declared tool. Many established controls attach at this point:

• Permissions decide which tools an agent is offered and which calls the harness will run.
• Human approval places a person in front of selected calls.
• Guardrails can validate a call's arguments against rules before it runs.
• Sandboxes limit what a tool can reach once it does run.
• Observability records calls, arguments, results and timing, so a run can be inspected.

Tool calls also widen what prompt injection can do. Injected instructions can be consequential with no tools at all, by producing misleading, manipulative or data-leaking output. Tool access adds a further possibility: unintended actions on external systems.

One further use of this point is evaluating each call against what the agent was asked to do. Sentience describes the moment a requested operation is about to reach a real system as the execution boundary, and what is captured there as an agent action: the tool, the type of operation and the system it targets, recorded as structured metadata rather than as prompt or completion content. The evaluation asks whether that action is consistent with an objective and scope declared beforehand, and with the operator's policy. None of this replaces the controls above. It adds a declared reference to judge calls against, and an explicit record of the judgment.

Sentience Governor implements this where it is instrumented: in Claude Code, in MCP clients, in LangChain and LangGraph, and in Pydantic AI through a separate package. It records the tool calls that pass through those integration points and does not see calls made elsewhere. A tool that a provider executes on its own infrastructure is recorded only where the integration exposes the invocation. The Claude Code integration, for example, records web search and web fetch calls because Claude Code surfaces them to its hooks; where an invocation is not exposed, there is no record of it. It records that an operation was attempted, not that its effect occurred. For Claude Code shell commands it also classifies the command by its potential effects. It flags what it finds and does not interrupt the call.

Where the concept stops

Tool calling is an invocation mechanism. It carries a model's request to software that can act on it and carries the result back. It does not establish that the request was appropriate, that it was authorized, that it ran, or what it changed. A tool's description is a claim made by whoever wrote it, and a tool's result is a report from the tool. Treating either as ground truth is a choice the surrounding system makes, and the quality of an agent depends heavily on how carefully it is made.