31 tools· updated sep 2026

What is function calling? The structured request a model returns instead of running code

Marek.

  • glossary
  • agent-tools
  • mcp

What is function calling, in one line: the model does not run your function, it asks for it. You describe the functions it may use. The model answers with a structured request that names one of them and fills in the arguments. Your code executes the call and sends the result back, and the model writes its answer with that result in front of it. The rest is the loop, what it costs, and how it relates to MCP.

  • The plain definition. A tool is three fields: a name, a description, and a JSON schema for the input. The model reads that text and decides when to call.
  • Who runs what. For a tool you define, the model returns a tool_use block with the name and the arguments. Your application runs the function. The model never touches your code.
  • The loop. One request with the tool list. One response that stops on tool_use. One tool_result from you, one more request, then the answer.
  • What it costs. Every definition is tokens on every request, plus a tool-use system prompt of a few hundred tokens that the API adds on its own.
  • The honest limit. Given a required argument nobody supplied, the model can guess it. The docs say so. The schema bounds the shape, not the judgment.

When the model runs that loop by itself, tool after tool until a stop rule says done, it is an agent: what an AI agent is.

The plain definition

Anthropic's documentation puts it in one sentence: "Tool use (also called function calling) lets Claude call functions that you define or that Anthropic provides." The next two sentences carry the whole mechanism. Claude "determines when to call a tool based on the user's request and the tool's description. It then returns a structured call that your application executes (client tools) or that Anthropic executes (server tools)."

OpenAI's guide says the same thing in its own vocabulary. A function call "refers to a special kind of response we can get from the model if it examines a prompt, and then determines that in order to follow the instructions in the prompt, it needs to call one of the tools we made available to it." Two vendors, one shape: the model produces a request, something else performs it.

A tool definition needs three fields: name, description, and input_schema, a JSON Schema for the arguments. Optional ones exist too, including input_examples, which the API puts in the prompt next to your schema. What the model never gets is your code. It reads the definition and picks.

What does it mean when you call a function?

In programming, calling a function means jumping into code you wrote elsewhere and getting a return value back. In a language model, "calling" is a request, not a jump. The model emits the function name and the arguments as structured output, and a program outside the model performs the jump. Same vocabulary, different actor.

What it means in practice

The round trip has four steps. You send the conversation plus a tools list. The model answers with stop_reason: "tool_use" and one or more tool_use blocks, each carrying an id, the name of the tool, and the input it chose. Your code runs the function and sends back a tool_result block whose tool_use_id matches that id. The model reads the result and answers the original question.

Whether to call at all is a setting. With the default tool_choice of auto, the model "calls a tool when the request maps to that tool's described capability and the answer isn't already in context." You can force a call on models that support it, cap the model at one call per turn with disable_parallel_tool_use on tool_choice, or set strict: true on a definition so the call always matches the schema. Server tools such as web_search run on Anthropic's side, and you get the result without writing a handler, unless Claude calls one in the same batch of parallel calls as a tool of yours.

For the September 2026 changes to forced tool choice, see the Opus 5.5, GPT-6 Sol and Luna launch guide.

The cost is easy to miss because nothing errors. Tool use requests are priced first on "the total number of input tokens sent to the model (including in the tools parameter)", so every definition rides along on every request in the session, called or not, although prompt caching can keep them cached across requests. On top of that, the API adds a tool-use system prompt of its own: for Claude Opus 5 the table lists 286 tokens with auto or none and 406 with any or tool. Fourteen definitions on every turn is a line item, and I say that as someone who runs exactly fourteen.

What is an example of a function call?

The documentation's example is get_weather with one required argument, location. Asked "What's the weather in San Francisco?", the model returns a tool_use block naming get_weather with {"location": "San Francisco, CA"}. The application looks the weather up, sends the text back, and the model writes: "The current weather in San Francisco is 15 degrees Celsius with partly cloudy skies."

The same page shows the failure in that example. Ask "What's the weather?" with no city and the model may answer with "location": "New York, NY" and a unit you never mentioned. The docs are direct about it: Claude Opus "is much more likely to recognize that a parameter is missing and ask for it", while Sonnet "might ask" and "might also infer a reasonable value". A required field in the schema means the call will carry a value. It does not mean the value came from the user.

Function calling vs MCP

People search for this pair as if it were a choice. It is a step and a delivery layer. Function calling is the step: a request from the model, executed outside it. MCP delivers the definitions. An MCP server hands the host application a list of tools. Each one carries the same three fields as above: name, description, schema. The host puts them into the tools list, the model picks one by its description, and the host routes the call to the server that offered it. With Claude on the other end, an MCP tool that the host loaded into the tools list comes back as an ordinary tool_use block. Called through Anthropic's own MCP connector, a beta feature where the API reaches the server for you, the same call comes back as mcp_tool_use.

I wrote two of those servers myself. The small one wraps a published calendar feed behind two tools. The larger one sits in front of an ad platform, exposes fourteen, and four of them move budget. It runs to 781 lines, and the part that took longest was not the code but the text in the descriptions. The account is in writing your own MCP server.

The other pairings people search for are simpler. "Function calling in C" is the programming sense from above, a jump into code. "Function calling in Python" splits both ways, because the SDK tutorials use the same words for the LLM step. "Function calling vs tool use" is no comparison at all: the Anthropic page treats the two names as one thing in its first line.

What people get wrong

People sayWhat is true
The model runs my functionIt returns a name and arguments in a tool_use block; your code runs the function. Server tools such as web_search are the exception
Function calling is deterministicThe model chooses whether and what to call, and may guess a missing argument. strict: true bounds the shape, not the judgment
Tool descriptions are documentationThey are the interface. The model picks from the name, the description and the schema, plus the conversation and your system prompt. It never sees the code behind them
MCP replaces function callingMCP delivers the definitions. Each call is still a structured request executed outside the model, by your host in the usual setup or by the API's own connector
More tools, more capabilityEvery definition is input tokens on every request, called or not. The list is a menu, not a library, and I stopped adding at fourteen

One example from my own work

The parameter that taught me the interface was the aggregation one on my ad platform server. Its first description was a single word: granularity. The agent guessed, because "granularity" gives a model no way to know that the accepted values are a short fixed list. I rewrote the description to list the values inline, and the guessing stopped. The fix was a sentence, not a feature.

The second lesson is about what the model may do. Four of those fourteen tools write to a live ad account, and nothing in the protocol treats a create differently from a read. So the restraint lives in the handler: nothing those tools make is live when it lands, and the switch that makes it live is not wired to the agent at all. Function calling gives the model a way to ask. What the answer is allowed to do is decided in your code, before the first call.

The smallest example is the session that produced this post. A browser extension exposes tools to the agent, among them find and read_page, each with a one-paragraph description. Asked for one link's address, the agent chose find to locate the element and read_page to read it, without being told which to use. Two descriptions and a schema did the routing.

Where to go deeper

The loop that keeps calling until a stop condition holds is what an AI agent is. The text the model reads to choose a tool is prompt text, covered in what a prompt in AI is. For the delivery layer, start with what an MCP server is, then the servers I keep connected.

Sources: Anthropic, Tool use with Claude; OpenAI, Function calling. Both read on 4 September 2026.