How a model calls a tool

01What function calling actually is

Function calling — also called tool calling or, in Anthropic's docs, tool use — is a mechanism that lets a language model request that your application run an external function, instead of the model trying to do the work itself. The big thing to get straight up front: the model does not execute the function. It returns a structured request — a function name plus arguments — and your application is responsible for actually running the code and handing the result back. OpenAI and Google call this "function calling"; Anthropic calls it "tool use"; the underlying idea is the same in each.

• The model emits a structured request (function name + arguments) — it does not run anything itself.
• Your application executes the real function and returns the result to the model.
• "Function calling" (OpenAI, Google) and "tool use" (Anthropic) are the same mechanism under different names.
• This is what connects a text-only model to live data and real-world systems — APIs, databases, search.

02The loop: request → tool schema → call → result → answer

Tool calling is a multi-step loop, not a single API call. (1) Your app sends the user's prompt plus the tool definitions. (2) The model decides whether — and which — tool to call, and emits the arguments. (3) Your app executes the tool. (4) Your app returns the result to the model. (5) The model produces a final answer (or asks for another tool). Pick a request below and step through the whole sequence.

• One user turn can span several API round-trips — the model and your code take turns.
• Notice steps 2 and 3: the model emits the call; your application runs it. They are separate.
• The loop ends when the model returns a normal text answer instead of another tool request.

03The contract: tools are declared with JSON Schema

Before the model can call a tool, you have to describe it. Across OpenAI, Anthropic, and Google, tools are declared with a JSON Schema that gives the model three things: a name, a natural-language description of what the tool does, and a typed parameter object (types, enums, descriptions, required fields, nested objects). That schema is the entire contract. The model reads it to decide whether to call the tool and how to fill in the arguments — which is why clear names and descriptions matter so much. Anthropic's guidance on writing tools for agents stresses that vague or overlapping definitions degrade the model's ability to choose and populate the correct call.

Function calling is really a form of structured output. In a provider's strict / Structured Outputs mode, the model's arguments are guaranteed to conform to the declared schema rather than being best-effort JSON — so your code can parse them safely.

• A tool definition = name + description + typed parameter schema.
• The description is read by the model, not just humans — it drives tool selection.
• Strict / Structured Outputs modes make the emitted arguments schema-valid by construction.

04Many tools, parallel calls, and where they run

Real applications hand the model many tools at once, and the model picks. In a single step it may even emit several tool calls — for example, weather for Tokyo and for London — which your app can execute together before returning all the results. There's also a question of where the tool runs: with client tools, the model returns a request and you execute it in your application; with server / built-in tools (such as a provider's web search or code execution), the tool runs on the provider's infrastructure and the result comes back directly.

As the number of tools grows, the industry has converged on a shared way to connect them. The Model Context Protocol (MCP) — introduced by Anthropic and described as a kind of "USB-C for AI" — is an open standard that gives AI applications (clients) a uniform way to connect to external tools, data, and prompts (servers), replacing fragmented per-source integrations with one protocol. Per its docs and neutral overviews, it has since been adopted across multiple vendors.

• You can expose many tools; the model selects which to call from their schemas.
• A single model turn can emit multiple tool calls to be executed together.
• Client tools run in your app; server / built-in tools run on the provider side.
• MCP is an open standard for connecting models to tools and data across vendors.

05Errors, and how this differs from plain text output

Because a real function runs in the middle of the loop, real things go wrong: the API is down, an argument is invalid, the request times out. The pattern is to feed the error back to the model as the tool result — just like a successful result — so it can react: apologize, retry with corrected arguments, or fall back to a different tool. Anthropic's guidance on writing tools for agents treats clear, informative error messages and token-efficient results as part of good tool design, because the model reads them.

The contrast with a plain text completion is the whole point of the lesson:

• Tool errors are returned to the model as results, so it can retry or recover.
• Clear error text and compact results are part of good tool design — the model reads them.
• Plain text output is closed-book; tool use lets the model act and verify against live systems.

06Knowledge check