Function calling: how a language model uses your tools

Function calling, also called tool calling or tool use, is how a language model gets things done outside its own text: it asks your program to run a function you described, with arguments it filled in, and then uses the result to answer. The short version on October 23, 2026: the model never runs anything itself. OpenAI's guide calls tool calling "a multi-step conversation between your application and a model", Google's documentation says "The model doesn't execute the function itself", and Anthropic says Claude returns "a structured call that your application runs". This guide explains the loop, the settings that control it, what it costs and the mistakes to avoid. It is based on the API documentation of OpenAI, Anthropic and Google, read on October 23, 2026; we have not benchmarked how accurately each model picks tools.

How function calling works, step by step

OpenAI's guide describes five steps, and the other two vendors follow the same pattern with different field names:

1. Your application sends the request with tool definitions. Each tool has a name, a description and a JSON Schema for its parameters.
2. The model replies with a tool call instead of text. It names the function and fills in the arguments. In Anthropic's API the response ends with stop_reason: "tool_use" and one or more tool_use blocks.
3. Your code runs the function. It checks the arguments, calls your database or API and gets a result.
4. You send the result back in a second request (Anthropic calls it a tool_result block).
5. The model answers, or asks for more calls. OpenAI notes the flow can continue "for as many tool calls as the task requires".

Anthropic's own example makes it concrete. A get_weather tool takes a location. Asked about the weather in San Francisco, Claude replies with a call to get_weather and the argument {"location": "San Francisco, CA"}, the application looks up the weather, sends "15 degrees Celsius, partly cloudy" back, and Claude writes the final answer. That loop, repeated until a goal is reached, is what turns a chatbot into an agent.

Anthropic also distinguishes client tools, which run in your application, from server tools such as web search, web fetch and code execution, which run on Anthropic's infrastructure and return results in the same response.

The settings that control tool calls

Table: tool call settings in the three APIs (official documentation, checked October 23, 2026)

Strict mode has rules. In OpenAI's API, "additionalProperties must be set to false for each object in the parameters" and "All fields in properties must be marked as required"; an optional field is written as a type that also allows null. Google describes VALIDATED simply as "Model ensures function schema adherence".

What tool calls cost

Tools are not free even when the function itself is. OpenAI states that "callable function definitions count against the model's context limit and are billed as input tokens". Anthropic bills the tools parameter, every tool_use block and every tool_result block as tokens, and adds a hidden system prompt that enables tool use: 286 tokens on Claude Opus 5.5, Sonnet 5.5 and Haiku 5.5 when tool_choice is auto or none, and 406 tokens on Haiku 5.5 when it is any or tool. Server tools such as web search add a charge per use.

The cost that surprises people is repetition. Every step of the loop is a new request that resends the conversation and the tool definitions. As an illustration, 15 tools described in about 150 tokens each add 2,250 tokens to every request; a task that takes six steps sends them six times, 13,500 input tokens before any real content. Our guide to what a token is explains how text turns into billable units, and prompt caching is the standard way to pay less for a long prefix that repeats.

How many tools, and how to describe them

The vendors agree that fewer, clearer tools work better:

• OpenAI: "Aim for fewer than 20 functions available at the start of a turn", which it calls "just a soft suggestion", and "Keep the number of initially available functions small for higher accuracy".
• Google: "Keep active set to 10-20 tools maximum", "Use specific types (integer, string, enum)" and "Validate function calls before executing".
• Anthropic: when a required parameter is missing, Claude Opus "is much more likely to recognize that a parameter is missing and ask for it", while Claude Sonnet "might also infer a reasonable value". Its example shows a guessed "location": "New York, NY" for a question that never mentioned a city. For very large catalogs, Anthropic offers a tool search tool that loads tools on demand.

The practical rules follow: one job per tool, a description that says when to use it and when not to, enums instead of free text where you can, and validation in your code even with strict mode on, because a valid schema does not mean a correct value.

Function calling, MCP and agents

Function calling is the mechanism between your application and one model API. The Model Context Protocol works one level up: it standardizes how tool servers describe and expose their tools, so one server can be used by many applications. Our guide to what MCP is covers that layer, and Anthropic's API can connect to remote MCP servers directly. When you put function calls in a loop with a goal and a stopping rule, you have an agent; how to build an agent walks through a tested example with two tools, a step limit and human approval.

The model proposes, your code decides

Because your application runs every call, the safety controls live there, not in the model. Google's list ends with "Use appropriate authentication for external APIs", and the same logic applies everywhere: give each tool the narrowest permission it needs, check arguments against your own business rules, ask a person to approve anything irreversible or costly, and log every call. Treat what a tool returns, such as a web page or an email, as data rather than instructions, since it can contain text written to mislead the model. Our agents for business guide lists the risks to plan for before you connect a model to real systems.