Function Calling

What Function Calling Is

Function calling is a capability that lets an LLM read the user's natural-language request together with the function definitions a developer supplies (name, description, parameter schema), and then produce the arguments needed to call that function as structured data in a fixed JSON format. For example, when a user types "tell me the weather in Paris," instead of replying in free text the model outputs JSON indicating that it should call the get_weather function with the argument {"location": "Paris, France"}.

The most important point here is that the model does not execute the function itself. Both OpenAI's and Google's official docs make this clear: the model does not run the function, it only generates the arguments. Taking those generated arguments, running the actual code (an API call, a database lookup, and so on), and returning the result to the model are entirely the application's responsibility. In other words, function calling is the concept focused on the step where an LLM translates natural language into a structured call specification.

Relationship to Tool Use

In practice, "function calling" and "tool use" are used to mean essentially the same thing. Anthropic's official docs state plainly that "Tool use is also known as function calling, and the two terms are interchangeable." The emphasis differs subtly, though. Tool use is the broader concept covering the whole loop: defining tools, generating arguments, executing, returning results, and producing a final answer. Function calling is closer to the mechanism within that loop where the LLM generates the arguments needed for the call.

How It Works

The standard flow, described almost identically across all three providers' docs, is as follows.

1. Pass the tool (function) definitions: Along with the user message, send the model a list of callable functions, each with its name, description, and parameter schema (JSON Schema).
2. The model decides and generates arguments: The model compares the request against each function description, and if it judges a tool would help, it outputs structured JSON specifying which function to call with which arguments instead of a free-text answer.
3. The application executes: The application parses that JSON and runs the actual function or API. (This step is performed by developer code, not by the model.)
4. Return the result: Pass the execution result back to the model. Anthropic does this with a tool_result block, while OpenAI and Gemini return a function output message, and Gemini recommends matching the id assigned to each call when returning the result.
5. Generate the final response: The model incorporates the function result to produce a final answer for the user, or, if needed, continues with additional function calls.

With Anthropic, when the model decides to call a tool, the response's stop_reason becomes "tool_use" and one or more tool_use blocks are returned. You can also control the calling behavior with tool_choice: under the default {"type": "auto"} the model decides on its own each turn whether to call a tool or answer directly, while specifying any or a particular tool forces a call.

Schema and Code Examples

At the heart of a function definition is the JSON Schema the model reads. An OpenAI function definition consists of the type, name, description, and parameters fields, and turning on strict: true guarantees that the generated arguments match the schema exactly (which requires additionalProperties: false).

{
  "type": "function",
  "name": "get_weather",
  "description": "Get the current weather for a given location.",
  "parameters": {
    "type": "object",
    "properties": {
      "location": { "type": "string", "description": "City and country, e.g. Paris, France" },
      "unit": { "type": "string", "enum": ["celsius", "fahrenheit"] }
    },
    "required": ["location"],
    "additionalProperties": false
  },
  "strict": true
}

When the user asks for "the weather in Paris," the model generates only the arguments that fit the schema above rather than executing the function. In OpenAI, the following structured arguments are returned.

{ "location": "Paris, France" }

Anthropic's Claude expresses the same intent as a tool_use block. Below is the example from the official docs, where the arguments the model generated are carried in the input field.

{
  "type": "tool_use",
  "id": "toolu_01A09q90qw90lq917835lq9",
  "name": "get_weather",
  "input": { "location": "New York, NY", "unit": "fahrenheit" }
}

Google Gemini works the same way: function declarations are defined as a subset of OpenAPI-compatible JSON Schema, and the model responds with structured JSON containing the function name, arguments, and a unique id. Across all three providers, the underlying mechanism is the same: the LLM produces argument JSON that conforms to the schema.

How the Providers Describe It

OpenAI's official function calling guide explains function calling as a five-step flow and states explicitly that the model does not execute the function but generates arguments in JSON format matching the schema. It also notes that Structured Outputs via strict: true guarantees the generated arguments match the JSON Schema you provided exactly.

Anthropic's official documentation (Tool use with Claude) states that tool use is also known as function calling and the two terms are interchangeable, and explains that for client tools the model returns stop_reason: "tool_use" and a tool_use block, after which developer code executes and replies with a tool_result.

Google's official documentation (Function calling with the Gemini API) states that the model does not execute the function directly and that handling the response is the application's responsibility, and notes that function declarations use a subset of the OpenAPI schema. Recent Gemini models assign a unique id to every function call.

Sources

• OpenAI — Function calling guide
• Anthropic — Tool use with Claude (overview)
• Google — Function calling with the Gemini API