Sources

The OpenAI guide documents the full request and response shape for tool-enabled chat completions. Tool definitions are an array of { type: "function", function: { name, description, parameters } } objects. The model's structured call comes back as a tool_calls[] array on the assistant message, where arguments is a stringified JSON object that the runtime must parse before validation. Multiple parallel calls in the same response are the default behavior.

OpenAI's structured-outputs mode applies token-level constraints during decoding so that the model can only emit JSON that conforms to a supplied schema. Setting strict: true on a tool definition raises that tool's reliability close to 100% syntactically, at the cost of some flexibility (additional fields are rejected, optional fields are not really optional in the same way). The article's claim that tool-call reliability is "high" for OpenAI assumes strict mode is available.

Anthropic's tool-use docs detail the request and response shape for Claude. Tool definitions live at tools[].input_schema rather than under a function.parameters nesting, and tool calls return as tool_use content blocks inside the assistant message's content[] array, with arguments already parsed as an object (no JSON.parse needed). Tool results are returned via a user-role message containing a tool_result content block with the matching tool_use_id; there is no separate tool role. The strict alternation of user and assistant roles makes some logging and replay simpler than the OpenAI shape.

The Gemini API wraps function declarations inside a tools[].function_declarations[] structure and uses the OpenAPI 3.0 schema dialect rather than vanilla JSON Schema, which means a few field names and capitalizations differ. Tool calls come back as functionCall objects inside the response's parts[] arrays. The assistant role is named model rather than assistant, which is a small but persistent source of bugs when porting code between providers.

The Converse API normalizes function calling across the model families Bedrock hosts (Claude, Llama, Mistral, Cohere, Titan). Tool definitions live at toolConfig.tools[].toolSpec with the JSON Schema wrapped in an inputSchema.json envelope. Tool calls come back as toolUse content blocks. The wrapping is what makes Bedrock useful for multi-model deployments: you swap the modelId string and the request and response shape stay constant. The reliability of the underlying model is unchanged by the wrapper, which is why the article rates Bedrock reliability as inheriting from the underlying model.

Ollama exposes an OpenAI-compatible Chat Completions endpoint at http://localhost:11434/v1. The wire format is identical to OpenAI's, which means existing OpenAI SDK code can target a local Llama or Qwen model with only the model name and base URL changed. The compatibility is wire-only; the underlying model's tool-use behavior is whatever that model's training produced. The article's reliability column for Ollama (variable, model-dependent) traces directly to this point.

vLLM's tool-calling docs cover the OpenAI-compatible endpoint and the guided-decoding features (Outlines, JSON Schema, CFG grammars) that constrain output at the token level. The article's claim that constrained decoding fixes the syntax of a tool call but cannot fix the semantics is the central operational lesson here: a model that does not understand when to call the tool will still call it at the wrong time, just with valid JSON.

BFCL is the standard public benchmark for cross-model tool-use reliability. It evaluates simple calls, multiple tools, parallel calls, function relevance (correctly choosing not to call), and live executable scenarios. The article's reliability ratings track BFCL's general findings: provider-native frontier models score in the high 90s on simple cases, open-weights models trail by 5 to 15 percentage points, and the gap narrows on each major open-weights release. The 5% reliability gap mentioned in the article corresponds to BFCL's "live" and "irrelevance" categories, which are the failure modes users actually see.

LiteLLM's docs describe how the wrapper accepts the OpenAI request shape and translates it to whatever provider you target, returning the OpenAI response shape regardless of where the call actually went. The article's "what leaks through" observations (provider-specific error codes, rate-limit shapes, dropped parameters like Anthropic's prompt caching or Gemini's grounding) are documented limitations, not edge cases. The 80/20 framing in the article (LiteLLM removes 80% of the boilerplate and concentrates the remaining 20% into failure moments) is consistent with the docs' own positioning.