Function and Tool Calling Across Claude, GPT, and Gemini

Core Concepts and Execution Boundaries

Function calling, also referred to as tool calling, allows large language models to interface with external software systems. Instead of producing unstructured text, the model inspects developer-provided schemas, determines when external data or actions are necessary, and returns a structured payload containing function names and validated arguments. The hosting application or platform then executes the function and returns the result to the model to complete the request.

While the high-level pattern is universal, each major model family establishes distinct boundaries regarding where execution occurs and how APIs organize the dialogue:

• Anthropic Claude separates tooling into client tools and server tools. Client tools run inside the developer’s application when Claude emits a stop reason of tool_use. Server tools, such as web_search_20260209, web_fetch, code_execution, and tool_search, run directly on Anthropic infrastructure without requiring client-side execution.
• OpenAI provides function tools governed by JSON Schema, custom tools using unstructured text inputs and outputs, and platform-managed built-in tools for web search, code interpretation, and MCP server connections. OpenAI requires the Responses API for newer models like gpt-6-astra and gpt-6.1-sol, while older implementations used Chat Completions.
• Google Gemini frames tool use across three primary operational categories: taking actions in external software, augmenting knowledge through external databases or APIs, and extending capabilities through external computation tools like calculators or charting engines.

Declaring Schemas: Request Formats Across Providers

Every provider expects tools declared as an array in the request body, but the naming conventions and validation properties vary. Anthropic uses an input_schema property, OpenAI uses parameters under a function container, and Gemini uses a parameters object directly inside the function declaration.

Anthropic defines tools using the input_schema key. Claude accepts tools alongside standard user messages in the Messages API:

{
  "model": "claude-opus-5-5",
  "max_tokens": 1024,
  "tools": [
    {
      "name": "get_weather",
      "description": "Get the current weather for a given location.",
      "input_schema": {
        "type": "object",
        "properties": {
          "location": {"type": "string", "description": "City and state, e.g. San Francisco, CA"}
        },
        "required": ["location"]
      }
    }
  ],
  "messages": [{"role": "user", "content": "What's the weather in San Francisco?"}]
}

OpenAI uses a function wrapper containing parameters. In the Responses API, developers can also supply namespaces to organize collections of tools (such as CRM or billing suites) and mark functions with defer_loading: true for discovery through tool_search on gpt-5.4 and later models:

{
  "model": "gpt-6-astra",
  "tools": [
    {
      "type": "function",
      "name": "get_weather",
      "description": "Retrieves current weather for the given location.",
      "parameters": {
        "type": "object",
        "properties": {
          "location": {"type": "string", "description": "City and country e.g. Bogotá, Colombia"},
          "units": {"type": "string", "enum": ["celsius", "fahrenheit"]}
        },
        "required": ["location", "units"],
        "additionalProperties": false
      },
      "strict": true
    }
  ],
  "input": [{"role": "user", "content": "What is the weather in Paris?"}]
}

Google Gemini handles tool definitions within its Interactions API endpoint (https://generativelanguage.googleapis.com/v1beta/interactions), associating JSON Schema parameters directly with function metadata:

{
  "model": "gemini-3.8-flash",
  "input": "What's the temperature in London?",
  "tools": [
    {
      "type": "function",
      "name": "get_current_temperature",
      "description": "Gets the current temperature for a given location.",
      "parameters": {
        "type": "object",
        "properties": {
          "location": {"type": "string", "description": "The city name, e.g. San Francisco"}
        },
        "required": ["location"]
      }
    }
  ]
}

Execution Flows and Multi-Turn State Handling

Tool calling requires a multi-step conversation loop. When the model determines an action is necessary, it pauses text generation and returns an invocation payload. The client application must parse the response, run the corresponding routine, and supply the output back to the API.

In Anthropic’s Messages API, Claude stops with stop_reason: “tool_use”. The response body contains content blocks where type is tool_use, exposing an id, name, and input object. To resume, the client sends back the entire conversation history, including the assistant’s tool_use block, followed by a user message holding a tool_result block referencing tool_use_id:

{
  "role": "user",
  "content": [
    {
      "type": "tool_result",
      "tool_use_id": "toolu_01A",
      "content": "15 degrees Celsius, partly cloudy"
    }
  ]
}

OpenAI’s Responses API structures tool responses as items in the output array. A function call appears with type: “function_call”, exposing call_id, name, and stringified arguments. The client supplies the result by appending an item with type: “function_call_output”, matching call_id, and referencing the prior interaction using previous_response_id to maintain state. When using reasoning models such as GPT-5 or o4-mini, any reasoning items returned alongside tool calls must also be passed back with the function call outputs.

{
  "model": "gpt-6-astra",
  "previous_response_id": "resp_01B",
  "input": [
    {
      "type": "function_call_output",
      "call_id": "call_01B",
      "output": "Paris: 25C"
    }
  ]
}

In Google Gemini’s Interactions API, function invocations emerge as discrete steps in the interaction.steps array. When step.type equals function_call, the client extracts step.name and step.arguments to invoke local code before returning output into the interaction thread.

Side-by-Side Comparison: APIs, Controls, and Pricing

Each provider balances schema rigor, routing mechanisms, and API endpoints differently. When integrating tools across providers, developers must account for differences in execution architecture and underlying token pricing.

Token pricing directly affects the operational feasibility of high-frequency tool calling pipelines. As verified on 2026-10-01, standard rates per 1M tokens differ significantly between model tiers:

Token Consumption Mechanics and Cost Multipliers

Tool calling introduces significant token overhead compared to single-turn completions. Tool definitions are appended to the input prompt, which means every parameter description, enum value, and required field counts toward input token totals on every request turn.

Furthermore, a single user turn requiring two sequential tool calls results in three round trips: the initial user request with tool schemas, the first tool result appended to the dialogue, and the second tool result appended before the final synthesis. In long sessions, the prompt expands cumulatively. Developers implementing heavy tool loops should review /posts/prompt-caching-explained-claude-gpt-gemini/ to leverage prompt caching, where cached input tokens drop to $0.2 per 1M on claude-sonnet-5.5, $0.1 per 1M on gpt-6.1-sol, and $0.075 per 1M on gemini-3.8-flash.

When structuring complex automation pipelines or selecting models by operational budgets, review /posts/choosing-an-llm-api-model-by-cost-tier/ and simulate multi-turn input-output totals using /tools/llm-api-cost-calculator/.

Implementation Gotchas and Constraints

Deploying tool calling systems into production surfaces several provider-specific operational constraints:

• Anthropic Tool Choice: Claude defaults to parallel tool invocation. If an application requires strictly one tool call per turn, the request must explicitly configure tool_choice with type: “auto” and disable_parallel_tool_use: true.
• OpenAI Responses API Migration: Advanced models like gpt-6-astra and gpt-6.1-sol mandate the Responses API for tool calling. Applications built on legacy Chat Completions (such as those using gpt-5.6-terra) must migrate to continue using newer models.
• Reasoning Token Preservation: When interacting with OpenAI reasoning models such as GPT-5 or o4-mini, the caller must echo all reasoning items returned in intermediate model steps when sending back function call outputs.
• OpenAI Strict Mode: Enabling strict: true guarantees the model adheres to schema constraints, but requires that all object definitions declare additionalProperties: false and list all defined properties in the required array.
• Gemini Step Traversal: In Google GenAI SDKs, function invocations arrive as entries within interaction.steps. Applications must inspect step types specifically to isolate function_call payloads from text output blocks.

Integration and Architectural Checklist

Before deploying function calling workflows to production, verify your system design against this operational checklist:

• Align Tool Definitions with API Conventions: Ensure Anthropic requests use input_schema, while OpenAI and Gemini requests place object definitions under parameters.
• Audit Parameter Descriptions: Provide explicit parameter descriptions, expected formats, and enums to prevent invalid invocations without forcing the model to guess argument structures.
• Enforce Strict Schemas Where Available: Use strict: true and additionalProperties: false on OpenAI tools to eliminate schema drift.
• Implement State Tracking: Ensure tool call identifiers (such as tool_use_id in Claude and call_id in OpenAI) match their corresponding output payloads across turns.
• Preserve Intermediate Context: Forward assistant tool call blocks and any reasoning items returned by models like GPT-5 into subsequent round trips.
• Monitor Cost Growth: Factor recurring schema overhead and intermediate execution turns into operational budgets using /tools/llm-api-pricing/.