OpenAI vs Anthropic Tool Calling APIs: Conversation vs Execution Trajectory Abstractions Compared

1. OpenAI Tool Calling APIs

OpenAI provides two distinct APIs for tool calling: the legacy Chat Completions API and the newer Responses API. Both follow the same core loop — declare tools, model decides to call, caller executes, results are fed back — but differ in their abstraction level.

1.1 Chat Completions Example

First round: define functions + model decides to call

Request includes model, messages (user query), and tools array where each tool has type (fixed to "function"), name, description, parameters (JSON Schema), and optional strict flag. The author notes the old design is verbose, nesting the function definition inside an extra function object.

{ "model": "deepseek-chat", "messages": [ { "role": "user", "content": "北京今天的天气怎么样？" } ], "tools": [ { "type": "function", "function": { "name": "get_weather", "description": "查询某个城市的天气", "parameters": { "type": "object", "properties": { "city": { "type": "string" } }, "required": ["city"] } } } ] }

Response returns choices[].message with a new tool_calls field containing id, type ("function"), and function with name and stringified arguments. finish_reason is "tool_calls".

Second round: manually stitch function result back

The caller must manually assemble the full messages history: user message, assistant message with tool_calls, then a tool role message with tool_call_id and content as the function result string. The model then produces the final answer with finish_reason "stop".

1.2 Responses API Example

First round: define functions + model decides to call

Request uses input (array of messages) and tools with a cleaner structure — no extra function nesting. Response returns an output array where function_call appears as a top-level element with id, type ("function_call"), status, arguments, call_id, name. The response object includes many metadata fields: status, background, billing, parallel_tool_calls, store, previous_response_id, etc.

{ "model": "gpt-4.1", "input": [ { "role": "user", "content": "北京今天的天气怎么样？" } ], "tools": [ { "type": "function", "name": "get_weather", "description": "查询某个城市的天气", "parameters": { "type": "object", "properties": { "city": { "type": "string" } }, "required": ["city"] } } ] }

Second round: stitch execution trajectory

Instead of messages, the caller submits the full execution trajectory: user input, the function_call object returned previously, and a function_call_output object with call_id and output. The response returns a message type in output with structured content array.

1.3 Built-in Tools

Responses API unifies tools under a type discriminator, enabling server-side built-in tools:

Web Search ( web_search) — search the web for real-time info

File Search ( file_search) — search uploaded files, often with vector DB

Function Calling ( function) — custom functions

Remote MCP Servers ( mcp) — connect third-party services via MCP

Image Generation ( image_generation) — GPT image generation

Code Interpreter ( code_interpreter) — run Python code

Computer Use / Shell ( shell / computer_use_preview) — execute shell commands in sandbox

A web_search example shows the response includes a web_search_call in output with action.queries and the final message with citations in annotations.

1.4 Key Difference: Abstraction Level

The author identifies the fundamental difference: Chat Completions abstracts conversation (directly maps to Transformer I/O, stitching messages is hand-crafting prompts), while Responses abstracts execution trajectory (interactions include message, function_call, function_call_output; submitting a trajectory turns the LLM into a trajectory interpreter). This enables server-side state management and built-in tools.

2. Anthropic Tool Calling API

Anthropic's Messages API resembles Chat Completions (conversation abstraction) but with more structured content. Recently added three beta features for large-scale agent tooling.

2.1 Basic Flow

First round: Request includes model, max_tokens, tools (each with name, description, input_schema as JSON Schema), and messages. Response returns content as an array of blocks: text and tool_use (with id, name, input object). stop_reason is "tool_use".

{ "model": "claude-sonnet-4-5", "max_tokens": 1024, "tools": [ { "name": "get_weather", "description": "Get the current weather in a given location", "input_schema": { "type": "object", "properties": { "location": { "type": "string", "description": "The city and state, e.g. San Francisco, CA" } }, "required": ["location"] } } ], "messages": [ { "role": "user", "content": "北京今天的天气怎么样？" } ] }

Second round: Caller manually assembles messages: user, assistant with tool_use block, then user with tool_result block containing tool_use_id and content. Response returns final text with stop_reason "end_turn".

2.2 Advanced Features (Nov 2025 Beta)

Tool Search Tool: On-demand tool discovery

Problem: Hundreds of MCP servers cause token explosion (up to 134K tokens just for tool definitions) and increased mis-selection.

Solution: Lazy loading + dynamic search. Claude calls tool_search_tool_regex to search tool names (e.g., "github"), only matched tool definitions are loaded into context.

Programmatic Tool Calling: Code-based orchestration

Problems: (1) Intermediate results pollute context (e.g., 10MB logs fully embedded even if only error stats needed; multi-table queries accumulate all rows). (2) High reasoning overhead — each tool call requires a full inference round.

Solution: Claude generates Python code that calls tools, processes results, handles loops/conditionals, and returns only the final result to its own context.

Tool Use Examples: Teaching correct usage beyond JSON Schema

Problem: JSON Schema cannot express format conventions (date formats, ID patterns), when optional fields should be filled, or cross-parameter dependencies (e.g., priority: "critical" requires certain fields).

Solution: Embed concrete examples directly in tool definitions. Examples teach format habits (YYYY-MM-DD, USR-XXXXX, kebab-case), contextual associations (critical bug needs full contact + escalation; feature request needs minimal info), and when optional fields apply.

These three features reflect Anthropic's systematic thinking on agent-tool collaboration at scale: not piling parameters, but reconstructing tool calling across discovery, orchestration, and learning dimensions. Unlike OpenAI's "change the abstraction layer," Anthropic patches within the conversation model but with high engineering value.

3. Comparison Summary

3.1 Common Core Loop

All three share the same minimal loop: (1) Declare tools (name, purpose, input schema). (2) Model selects calls (structured tool calls). (3) Caller executes tools (including built-ins). (4) Results fed back per protocol; model generates final answer or plans next step. Core value: model outputs a verifiable, parsable, executable action description, connecting LLM to system capabilities.

3.2 Abstraction Divide: Conversation vs Execution Trajectory

OpenAI Chat Completions: Conversation abstraction. Request/response organized around messages; tool_calls is just a field on assistant message. Stitching messages = hand-crafting prompt.

Anthropic Messages: Conversation abstraction with structured content. messages but content explicitly split into text blocks + tool blocks; tool results appear as tool_result blocks. Earlier treated tool use as part of content sequence, not an attached field.

OpenAI Responses: Execution trajectory abstraction. function_call / function_call_output are top-level structured elements, emphasizing submission of an already-occurred trajectory. Leads naturally to agent runtimes: message is one event type among many, easier to extend with built-in tools and richer event types.

In short: Chat Completions / Anthropic stuff tools into conversation; Responses stuffs conversation into execution trajectory.

3.3 Built-in Tools & Platform Orientation

OpenAI Responses: Platformization route — unify tools via multiple type values, server-side built-in capabilities, client submits trajectory.

Anthropic: Protocolization route — standardize tool use rigorously, but avoid a full API rewrite of the interaction model.

Philosophy difference: Platformization = developer convenience but tighter coupling to platform boundaries; Protocolization = more developer control but requires building more runtime infrastructure (tool routing, caching, observability, permissions, sandboxes).