Function Calling Deep Dive — OpenAI, Anthropic, Gemini

The shape of a function-calling request depends on the provider. Three examples from 2026 production stacks:

OpenAI Chat Completions / Responses API. You pass tools: [{type: "function", function: {name, description, parameters, strict}}]. The response carries choices[0].message.tool_calls: [{id, type: "function", function: {name, arguments}}], and arguments is a JSON string you have to parse. Strict mode (strict: true) enforces schema compliance with constrained decoding.

Anthropic Messages API. You pass tools: [{name, description, input_schema}]. The response comes back as content: [{type: "text"}, {type: "tool_use", id, name, input}]. input is already an object, not a string. You answer with a new user message holding a {type: "tool_result", tool_use_id, content} block.

Google Gemini API. You pass tools: [{functionDeclarations: [{name, description, parameters}]}], nested under functionDeclarations. The response arrives as candidates[0].content.parts: [{functionCall: {name, args, id}}], where id is unique from Gemini 3 on so parallel calls can be correlated. You answer with {functionResponse: {name, id, response}}.

Same loop, different field names, different nesting, different string-versus-object conventions, different correlation mechanisms. A team that writes a weather agent on OpenAI pays two days to port it to Anthropic and another day for Gemini, and all of it is plumbing.

This lesson builds a translator that turns the three formats into one canonical tool declaration and routes at the edge. Phase 13 · 17 generalizes the same pattern into an LLM gateway.

The common structure

Every provider needs five things:

1. Tool list. Per-tool name, description, and input schema.
2. Tool choice. Force a specific tool, forbid tools, or let the model decide.
3. Call emission. Structured output naming the tool and arguments.
4. Call id. Correlate the response to the right call (matters for parallel).
5. Result injection. A message or block that ties the result back to the call.

Shape diffs, field by field

Limits you will actually hit

• OpenAI. 128 tools per request. Schema depth 5. Argument string <= 8192 bytes. Strict mode requires no $ref, no oneOf/anyOf/allOf with overlap, every property listed in required.
• Anthropic. 64 tools per request. Schema depth effectively unbounded but practical limit 10. No strict-mode flag; schema is a contract and the model tends to comply.
• Gemini. 64 functions per request. Schema types are OpenAPI 3.0 subset (slight divergence from JSON Schema 2020-12). Parallel calls unique-id since Gemini 3.

tool_choice behavior

Three modes everyone supports, named differently.

• Auto. Model picks tool or text. Default.
• Required / Any. Model must call at least one tool.
• None. Model must not call tools.

Plus one mode unique to each provider:

• OpenAI. Force a specific tool by name.
• Anthropic. Force a specific tool by name; disable_parallel_tool_use flag separates single vs multi.
• Gemini. mode: "VALIDATED" routes every response through a schema validator regardless of model intent.

Parallel calls

OpenAI's parallel_tool_calls: true (default) emits multiple calls in one assistant message. You run them all and reply with a batched tool-role message containing one entry per tool_call_id. Anthropic historically did single-call; disable_parallel_tool_use: false (default as of Claude 3.5) enables multi. Gemini 2 allowed parallel calls but did not give stable ids; Gemini 3 adds UUIDs so out-of-order responses correlate cleanly.

Streaming

All three support streamed tool calls. The wire format differs:

• OpenAI. Delta chunks of tool_calls[i].function.arguments arrive incrementally. You accumulate until finish_reason: "tool_calls".
• Anthropic. Block-start / block-delta / block-stop events. input_json_delta chunks carry partial arguments.
• Gemini. streamFunctionCallArguments (new in Gemini 3) emits chunks with a functionCallId so multiple parallel calls can interleave.

Phase 13 · 03 goes deep on parallel + streaming reassembly. This lesson focuses on the declaration and single-call shapes.

Errors and repair

Invalid-argument errors look different too.

• OpenAI (non-strict). Model returns arguments: "{bad json}", your JSON parse fails, you inject an error message and re-call.
• OpenAI (strict). Validation happens during decoding; invalid JSON is impossible but refusal can appear.
• Anthropic. input may contain unexpected fields; schema is advisory. Validate server-side.
• Gemini. OpenAPI 3.0 quirk: enum on object fields silently ignored; validate yourself.

The translator pattern

A canonical tool declaration in your code looks like this (you pick the shape):

Tool(
    name="get_weather",
    description="Use when ...",
    input_schema={"type": "object", "properties": {...}, "required": [...]},
    strict=True,
)

Three small functions translate it to the three provider shapes. code/main.py does exactly this, then parses a hand-written response in each provider's shape back into one Call object. No network is involved, because the point is the shapes and not the HTTP.

Production teams wrap this translator in AbstractToolset (Pydantic AI), UniversalToolNode (LangGraph), or BaseTool (LlamaIndex). Phase 13 · 17 ships a gateway that exposes an OpenAI-shaped API in front of any of the three.

code/main.py defines one canonical Tool dataclass and three translators (to_openai, to_anthropic, to_gemini) that emit each provider's declaration JSON. It also converts a canonical ToolChoice into each provider's tool-choice shape (tool_choice for OpenAI and Anthropic, function_calling_config for Gemini). Then it parses a hand-written response in each provider's format into the same Call object (parse_openai, parse_anthropic, parse_gemini), which shows the semantics match underneath. Run it and compare the three declarations side by side.

What to look at:

• The three declarations differ only in envelope and field names. The Gemini one also uppercases the schema type values and drops additionalProperties.
• The three responses differ in where the call lives: tool_calls on the message, a tool_use entry in content[], or a functionCall entry in parts[].
• The final equivalence check confirms all three parse to the same name and the same args.

This lesson produces outputs/skill-provider-portability-audit.md. Point it at a function-calling integration written for one provider and it returns a portability audit: which provider limits the code relies on, which fields need renaming, and what breaks on each of the other two.

1. Run code/main.py and verify that the three provider declaration JSONs all serialize the same underlying Tool object. Modify the canonical tool to add an enum parameter and confirm only the Gemini translator needs to handle the OpenAPI quirk.

2. Add a ListToolsResponse parser for each provider that extracts the tool list a model returns after a list_tools or discovery call. OpenAI does not have one natively; note this asymmetry.

3. Implement tool_choice conversion: map a canonical ToolChoice(mode="force", tool_name="x") into all three provider shapes. Then map mode="any" and mode="none". Check the shape-diff table in The Concept.

4. Pick one of the three providers and read its function-calling guide end to end. Find one field in its schema spec that the other two do not support. Candidates: OpenAI strict, Anthropic disable_parallel_tool_use, Gemini function_calling_config.allowed_function_names.

5. Write a test vector: a tool call whose arguments violate the declared schema. Run it through each provider's validator (the stdlib one in Lesson 01 will do as a proxy) and record which errors fire. Document which provider you would use in production for strictness.

• OpenAI: Function calling guide: canonical reference including strict mode and parallel calls
• Anthropic: Tool use overview: tool_use and tool_result block semantics
• Google: Gemini function calling: parallel calls, unique ids, and the OpenAPI subset
• Vertex AI: Function calling reference: Gemini's enterprise surface
• OpenAI: Structured outputs: strict-mode schema enforcement details