Tool Calling (Function Calling)

Tool calling, which OpenAI calls function calling, is how a language model asks your code to do something: look up an order, search a knowledge base, file a ticket, send an email. You describe the tools available. The model reads the request, decides a tool applies, and returns the tool's name and its arguments as structured data instead of prose. Your application checks that request, runs the real function, and hands the result back, and the model continues with it in context. Every production AI agent is this exchange repeated in a loop.

The model never executes anything. Its output is a request to call a tool and never itself an action. That rule shaped the tool layer we built for AVOX, an insurance voice agent, and the rest of this page depends on it.

A tool is a typed contract#

Each tool is described to the model by a name, a plain-language description and a JSON Schema for its inputs. A get_order tool might require an order_id string and accept an optional include_items flag. On Solarpunk, the desktop chief-of-staff agent we built, every tool is a typed contract with declared inputs, declared outputs and declared side effects. That makes the set of actions the agent can take a list you can read, so the limits on what it may do are enforced by the system rather than requested in a prompt.

The schema says what a valid call looks like. It cannot say when to call the tool or which combinations of arguments make sense. The description does that, and the model reasons over it when choosing, so write it the way you would brief a new engineer: what the tool does, when to use it and when not to, and what each argument means.

As of October 2026, both major APIs can enforce the schema while the model writes. OpenAI's guide says "We recommend always enabling strict mode." Anthropic's strict: true on a tool definition guarantees the arguments match, with a limit of 20 strict tools per request. Turn it on for any tool whose arguments reach a system that changes state.

The round trip#

You ask "where is order 4471?" The model cannot know that, but it sees get_order, so it returns a tool call: on Claude, a response with stop_reason: "tool_use" and a tool_use block; on OpenAI's Responses API, an output item of type function_call. Your code validates the arguments, runs the lookup, and sends the output back as a tool result. The model then writes the answer or asks for another call.

Send failures back as results too. "Unknown order id, did you mean 4417?" lets the model correct itself on the next turn, and a crash strands the conversation. Bound the retries, though. On Solarpunk, an agent that retries indefinitely against a broken vendor was worse than one that stops, because it burns cost and time while looking busy.

Models can request several independent calls in one turn. Run them concurrently and return the results together, so the wait is the slowest call rather than the sum. Keep dependent or destructive calls one at a time: OpenAI's parallel_tool_calls: false and Claude's disable_parallel_tool_use exist for that.

One provider change catches teams who used tools to get JSON. Claude Opus 5.5 rejects forced tool use: tool_choice set to any or to a named tool returns a 400 error. If you defined a fake tool and forced it to get a clean object out of the model, move that schema to structured output, which is the feature that job needed.

Tool selection breaks before the context fills#

Teams usually worry about the token cost of a long tool list. On Solarpunk, putting every tool in the system prompt worked until roughly 30 tools, and then the model began choosing plausible but wrong tools with nothing in the output to show it. The context cost was the visible symptom and the wrong choice was the expensive one. OpenAI's own guidance is to aim for fewer than 20 functions at the start of a turn, which it calls a soft suggestion.

We changed the design so the model does not get the whole registry, the list of every registered tool. It queries that list, and chooses among a handful of relevant contracts instead of a hundred competing ones, which took the same product past 100 registered tools. Both major APIs now offer a tool search of their own. Where that point falls depends on the set: tools that overlap confuse a model sooner than tools that are clearly distinct.

Authorize every call in code#

A tool call is untrusted input. The model can be steered by any text it reads, including text an attacker planted in a page, a document or an email, which is how prompt injection turns an inbox tool into a way to forward confidential mail. So the checks belong in code, on every call.

Check arguments against the schema and the business rules on the server. Enforce permissions with the end user's identity, never with a line in the system prompt. On Skionis, the DevOps agent we built on a live AWS account, the only actions available are purpose-built tools wrapping the provider's APIs, with no general shell and no path by which a plan step becomes an arbitrary API call. On Solarpunk, credentials are added by the code that calls the vendor, at the moment it runs, and never enter the prompt, so the agent drives a session without ever learning a password. On AVOX, required disclosures sat in the tool contract: a payment could not run until its disclosure had been given. Gate anything irreversible behind a person, and log every call with its arguments and result. Our guide to AI SRE agents applies the same limits to an agent that answers production alerts: scoped tools, and a person approves before anything in production changes.

Where MCP fits#

Tool calling is a feature of each model API. The Model Context Protocol standardises how tools are packaged and discovered, so one server can offer its tools to any compatible client. Underneath, the model still emits the same kind of call, and your code still decides whether it runs. Our guide on MCP tool design covers how to shape the tools a server exposes, and MCP authorization covers where the permission check has to sit. A procedure can live in a skill the host loads into context while the MCP server keeps the access; our guide to skills vs MCP covers where each belongs.