Function Calling (Tool Use)

What is function calling?

Function calling, also known as tool use, is the capability that lets a large language model (LLM) interface with external systems by emitting a structured request to invoke a named function. Instead of replying only with free-form prose, the model analyzes a natural-language input, decides that a registered tool is relevant, and produces a machine-readable object containing the function name and a set of arguments. The application parses that object, runs the corresponding code, and returns the result so the model can continue.

A defining property is that the model itself does not execute anything. It selects the appropriate function, fills in the parameters, and hands the request back to the calling application. Execution, authentication, error handling, and side effects remain entirely under the developer's control. This separation is what makes function calling safe to wrap around databases, payment APIs, search indexes, file systems, and other live systems.

Function calling is the mechanism that turns a text-prediction model into something that can take actions: look up current weather, query a SQL table, send an email draft to a queue, or retrieve a document. It is the foundational primitive beneath most LLM agents.

• The model emits a structured tool call; it does not run the function.
• Inputs: a user prompt plus a list of tool definitions the model may call.
• Outputs: a tool name and JSON arguments, or a normal text answer.
• It bridges a frozen, text-only model to live data and external actions.

Function calling vs. tool calling vs. tool use: the terminology

The terms function calling, tool calling, and tool use describe the same underlying mechanism, and the differences are largely vendor vocabulary rather than distinct concepts. OpenAI popularized the phrase function calling and frames each tool as an object with type set to function. Anthropic uses tool use across Claude's documentation, where the model returns a tool_use content block and the application replies with a tool_result. Google and other providers use comparable language.

Tool is the broader word because not every tool is a user-defined function. Modern APIs distinguish client-side tools (code that runs in the developer's application) from server-side or hosted tools (such as web search or code execution that the provider runs on its own infrastructure). A user-defined function is one kind of client-side tool. In practice, treat function calling, tool calling, and tool use as synonyms for the request-response pattern described here, and read each provider's field names rather than assuming portability across APIs.

• OpenAI: function calling; tool type is function.
• Anthropic Claude: tool use; tool_use and tool_result blocks.
• Client tools run in your app; server/hosted tools run on the provider's infrastructure.
• The terms are interchangeable; field names and request shapes are not.

How it works: tool schemas, the structured call, and the execution loop

A function call begins with a tool definition. Each tool is described with a name, a natural-language description that tells the model when and how to use it, and a parameters object expressed as a JSON Schema. The description is read by the model, so clear, contract-like wording materially improves tool selection. These definitions are passed in the request alongside the user's messages.

The loop then proceeds in a small number of well-defined steps. As OpenAI documents it, the developer makes a request with the available tools; the model returns a tool call; the application executes the corresponding code with the supplied arguments; the application makes a second request that includes the tool output; and the model returns a final answer or further tool calls. Anthropic describes the same agentic loop: Claude responds with stop_reason set to tool_use and one or more tool_use blocks, the application runs the operation and returns a tool_result, and the exchange repeats until the model stops requesting tools.

Whether the model calls a tool at all is controllable. With the default automatic setting, the model decides per turn whether a request maps to a tool's described capability; developers can also force a specific tool, allow any tool, or forbid tools, and can steer behavior through the system prompt.

{
  "tool_calls": [
    {
      "id": "call_a1",
      "type": "function",
      "function": {
        "name": "get_weather",
        "arguments": "{\"city\": \"Berlin\", \"unit\": \"celsius\"}"
      }
    }
  ]
}

• Step 1: send the prompt plus tool definitions (name, description, JSON Schema).
• Step 2: the model returns a structured tool call or a direct answer.
• Step 3: the application executes the function and captures the result.
• Step 4: the result is returned to the model, which answers or calls again.

JSON Schema and argument validation

The parameters of each tool are described with JSON Schema, which lets developers specify property types, enums, descriptions, nested objects, required fields, and recursive structures. This schema acts as a contract between the model and the external environment: it tells the model exactly what shape of arguments to produce, and it gives the application a basis for validating what comes back.

By default, generated arguments are best-effort and should be validated before use. To tighten this, both OpenAI and Anthropic offer a strict mode, enabled by setting strict to true on the tool definition, which uses constrained decoding to guarantee that the model's arguments conform to the supplied schema. OpenAI's strict mode additionally requires that each object set additionalProperties to false and that all fields be marked required, with optional fields represented by allowing a null type.

Even with strict schema conformance, semantic validation remains the developer's responsibility. A model can emit a well-typed but wrong value (for example, a plausible but incorrect identifier), so applications should range-check, authorize, and sanity-check arguments before performing any consequential action.

• JSON Schema defines types, enums, required fields, and nested or recursive objects.
• strict: true uses constrained decoding to force schema conformance.
• Strict mode in OpenAI requires additionalProperties: false and all-fields-required.
• Schema validity is not semantic correctness; validate argument values before acting.

Parallel and multi-step tool calls

Models can request more than one tool in a single turn. When calls are independent, the model may emit several at once so the application can run them concurrently. OpenAI exposes a parallel_tool_calls flag that can be set to false to restrict a turn to at most one call. With Claude, parallel calls arrive as multiple tool_use blocks, and the application must return every corresponding tool_result inside a single user message, each in its own block, to avoid API errors and keep the model using parallel tools.

Multi-step (sequential) tool use is different: the output of one tool feeds the input of the next, so the loop repeats across several turns until the task is complete. This is the backbone of agentic behavior. To reduce the cost of many individual round-trips, providers have introduced techniques such as Anthropic's programmatic tool calling, where the model writes code that orchestrates several tools and controls which intermediate outputs actually enter its context window.

• Parallel calls: multiple independent tools requested in one turn, run concurrently.
• Sequential calls: each tool's output becomes the next tool's input across turns.
• Claude requires all parallel tool_result blocks in one user message.
• Orchestration techniques reduce round-trips by running tools in generated code.

Function calling vs. plain text generation and structured outputs

Plain text generation produces an unstructured answer that the application must parse heuristically. Function calling instead produces a typed call the application can act on directly, which is what enables reliable integration with external systems.

Function calling is closely related to, but distinct from, structured outputs (sometimes called JSON mode). Structured outputs constrain the model's final answer to a JSON Schema for data extraction, classification, or formatting; they shape what the model returns to the user. Function calling shapes what the model asks the application to do. A common rule of thumb: use structured outputs when you need clean data back from the model, use function calling when you need the model to trigger an action, and combine the two when an agent must call tools and then return a formatted result. The mechanisms overlap because both rely on the same constrained-decoding machinery to enforce a schema.

• Plain text: unstructured, parsed heuristically by the application.
• Structured outputs: constrain the model's final answer to a schema (data in, data out).
• Function calling: constrain the model's request to invoke an action.
• They share constrained-decoding internals and are often combined in agents.

Reliability concerns: hallucinated arguments, wrong tool selection, and guardrails

Function calling introduces failure modes beyond ordinary text generation, generally grouped as tool selection errors and tool usage errors. Selection errors include calling an inappropriate tool, calling a tool at the wrong time, or fabricating a tool that does not exist in the available set. Usage errors include supplying malformed or invalid arguments, hallucinating plausible-but-wrong values, or bypassing the tool entirely and simulating an output instead of invoking it.

Mitigations operate at several layers. Tight tool definitions help most: descriptions that read like contracts, with a clear purpose, a couple of crisp examples, and unambiguous argument types, reduce both misselection and bad arguments. Strict schema enforcement removes malformed structure. Beyond that, applications add their own guardrails: validating and authorizing arguments before execution, limiting which tools are exposed per task, requiring confirmation for consequential actions, and monitoring for anomalous calls. Research directions include reliability-focused alignment and detectors that flag tool-calling hallucinations, distinguishing tool selection from tool usage errors.

• Selection errors: wrong tool, wrong time, or a fabricated tool.
• Usage errors: malformed arguments, hallucinated values, or simulating instead of calling.
• Defenses: contract-style tool docs, strict schemas, and pre-execution validation.
• Operational guardrails: minimal tool exposure, confirmation gates, and call monitoring.

Relationship to the Model Context Protocol and agent frameworks

Function calling defines how a single model talks to tools within one API. The Model Context Protocol (MCP), an open standard announced by Anthropic in November 2024, standardizes how those tools, plus data resources and prompts, are exposed to any model. MCP is transported over JSON-RPC 2.0 and takes inspiration from the Language Server Protocol, with a host, a client, and servers that publish capabilities. OpenAI adopted MCP in March 2025 and Google DeepMind followed in April 2025; in December 2025 Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation. The practical effect is that an MCP server's tools become callable by a model through the same function-calling mechanism, without bespoke integration code per tool-model pair.

Agent frameworks such as LangChain and LlamaIndex sit on top of this stack. They manage the function-calling loop, register tools (often via MCP), maintain conversation and scratchpad state, and orchestrate multi-step plans. AI memory and second-brain tools follow the same pattern: an application can expose its semantic search and retrieval over stored documents as a tool a model invokes through function calling. In short, function calling is the per-call primitive, MCP is the portable tool-distribution layer, and agent frameworks are the orchestration around both.

• Function calling is the per-API primitive for model-to-tool communication.
• MCP (Anthropic, Nov 2024; JSON-RPC 2.0) standardizes tool, resource, and prompt exposure.
• OpenAI (Mar 2025) and Google DeepMind (Apr 2025) adopted MCP; it later moved to the Linux Foundation's Agentic AI Foundation.
• Agent frameworks like LangChain and LlamaIndex orchestrate the loop and register tools.