Function Calling APIs: Provider Comparison

Decision brief

TL;DR

Who this comparison is for

Use this guide if you are selecting a provider, migrating an existing agent, or building one orchestration layer across multiple models. It assumes you can make API requests, define JSON Schema, and execute tools in a trusted backend.

Start with one canonical tool contract

The durable unit is not a provider payload. It is a provider-neutral definition, a normalized call, and a normalized result. Store the provider call ID separately so the adapter can reconstruct the required reply.

type ToolDefinition = {
  name: string;
  description: string;
  inputSchema: JsonSchema;
  sideEffect: "read" | "write";
};

type ToolCall = {
  provider: "openai" | "anthropic" | "google";
  providerCallId: string;
  name: string;
  arguments: unknown;
  raw: unknown;
};

type ToolResult = {
  providerCallId: string;
  ok: boolean;
  content: unknown;
  evidence?: { source: string; retrievedAt: string }[];
};

OpenAI vs Anthropic vs Google: protocol comparison

OpenAI implementation: correlate with call_id

Send function tools with the request. When the model emits a function_call, parse its arguments, execute the approved tool, then append a function_call_output carrying the same call_id. Use tool_choice deliberately instead of forcing tools by default.

const first = await client.responses.create({
  model, input: userInput,
  tools: [{ type: "function", name: "get_quote", description,
    parameters: quoteSchema, strict: true }]
});

const call = first.output.find(x => x.type === "function_call");
const result = await executeSafely(call.name, JSON.parse(call.arguments));

const final = await client.responses.create({
  model, previous_response_id: first.id,
  input: [{ type: "function_call_output", call_id: call.call_id,
    output: JSON.stringify(result) }]
});

Anthropic implementation: preserve tool_use ordering

Claude returns one or more tool_use blocks, commonly with stop_reason: tool_use. The next user message must contain corresponding tool_result blocks. Put result blocks before any additional user text and mark execution failures with is_error: true.

const calls = response.content.filter(x => x.type === "tool_use");
const toolResults = await Promise.all(calls.map(async call => ({
  type: "tool_result",
  tool_use_id: call.id,
  content: JSON.stringify(await executeSafely(call.name, call.input))
})));

messages.push({ role: "assistant", content: response.content });
messages.push({ role: "user", content: toolResults });

Google implementation: preserve state and signatures

In the Interactions API, a function call is a step with id, name, and arguments; return a function_result referencing its call ID. Stateful continuation uses previous_interaction_id. In stateless flows, replay prior steps exactly, including required thought/signature metadata.

const call = interaction.outputs.find(x => x.type === "function_call");
const result = await executeSafely(call.name, call.arguments);

const next = await client.interactions.create({
  model,
  previous_interaction_id: interaction.id,
  input: [{ type: "function_result", call_id: call.id,
    result }]
});

Build a thin provider adapter

Each adapter should do four things only: serialize definitions, extract calls, serialize results, and preserve provider state. Validation, authorization, execution, retries, and evidence belong to shared infrastructure.

const turn = await adapter.ask({ messages, tools: canonicalTools });
const calls = adapter.extractCalls(turn);

const results = [];
for (const call of calls) {
  const args = validate(call.name, call.arguments);
  await authorize(identity, call.name, args);
  results.push(await executeIdempotently(call, args));
}

const answer = await adapter.continue({
  state: turn.state,
  toolResults: results
});

Schema design that survives all three APIs

• Use small objects with explicit properties and predictable primitive types.
• Keep enums short and explain units, formats, time zones, and defaults in descriptions.
• Avoid deeply recursive schemas, ambiguous unions, and provider-specific extensions in the canonical layer.
• For OpenAI strict mode, objects need additionalProperties: false and required fields; represent optional values explicitly where needed.
• Validate again after decoding. Schema compliance does not prove a ticker exists, a date range is allowed, or a transfer is authorized.

Tool choice, strict mode, and parallel calls

Streaming and multi-turn state

Never execute a tool from an incomplete argument fragment. Buffer deltas until the provider marks the call complete, decode once, validate once, and persist the provider call ID before execution. For stateless continuation, retain every provider-required message item and opaque signature exactly.

Security, cost, and latency controls

Common failure modes and fixes

A provider-neutral validation benchmark

Do not publish a single “accuracy” score from a handful of prompts. Run the same versioned corpus against every provider and report success by failure class.

Migration checklist between providers

1. Freeze a canonical tool registry and version every schema.
2. Map definition fields, tool-choice controls, call IDs, result envelopes, and conversation state.
3. Remove unsupported schema features before translation.
4. Replay production traces in shadow mode without side effects.
5. Compare call selection, argument validity, recovery, latency, and cost.
6. Canary read-only tools first; enable write tools only after idempotency and authorization tests pass.

QVeris implementation pattern

Provider-native function calling controls the model-facing message loop. MCP can standardize how a client discovers and invokes tool servers. QVeris sits at the capability layer: it helps an agent discover, inspect, route, call, and audit real-world tools and data, while your provider adapter preserves the required OpenAI, Anthropic, or Google protocol.

FAQ

Official sources