Insight · October 20, 2026
The model
makes the call.
A language model cannot check a price, run a query, or send a message on its own. Tool calling is how it reaches past its own text and acts.
01 · The short answer
Tool calling is how a model acts on the world.
Tool calling is how a language model uses something outside itself. You describe a function to the model. When a request needs it, the model does not answer in prose. It returns a structured call that names the function and the arguments to run it with. Your code runs that call and hands the result back.
Anthropic's own documentation puts it plainly. Tool use, also called function calling, lets a model call functions that you define or that the vendor provides. The model decides when a tool fits based on the request and the tool's description, then returns a structured call your application executes. The model never runs the code. It only decides what to run.
02 · Why it exists
A model produces text. That is all it does.
A language model is a text engine. Give it words, it returns words. It cannot read today's price, query your database, send an email, or check whether a file exists. Left alone, it can only describe doing those things, confidently and sometimes wrongly.
Tool calling closes that gap. It gives the model a short list of actions it is allowed to take and a strict shape for taking them. The model stops guessing at facts it cannot know and starts asking for them. The answer it gives is grounded in a real result, not a plausible sentence.
This is the base layer under every AI agent. An agent plans and acts across many steps, but each single act it takes is a tool call. Remove tool calling and an agent has nothing to do but talk.
The one line to keep
“The model picks the call. Your code makes it. That split is the whole idea.”
03 · The round trip
One tool call is five steps, every time.
01
Describe
You hand the model a tool as a name, a description, and a schema for its inputs. The description is what teaches the model when to reach for it.
02
Decide
The model reads the request against the tool list. If a tool fits, it stops writing prose and marks the turn as a call instead of an answer.
03
Call
The model returns a structured block naming the tool and the arguments, shaped to the schema you gave it. Anthropic calls this the tool_use block.
04
Execute
Your code runs the actual function while the model waits. Credentials, rate limits, and access all stay on your side, never the model side.
05
Return
You send the result back as a tool_result. The model reads it and writes the final answer, now grounded in something real rather than guessed.
04 · Tool calling vs function calling
Tool calling and function calling are the same thing.
The two terms trip up buyers constantly. They describe one mechanism. OpenAI ships it under the name function calling. Anthropic calls it tool use. The Claude documentation settles the overlap in a single line, defining tool use as, also called function calling.
The differences are naming, not substance. One vendor labels the schema field parameters, another labels it input_schema. The shape is the same in every case: a name, a description, and a JSON schema for the inputs. And in every version the rule holds that the model does not execute anything. OpenAI's own cookbook states that the API will not actually execute any function calls, and that it is up to developers to execute them using the model's output.
If there is a useful distinction, it is scope. A function is one piece of code you own. A tool can be that, or it can be a service the vendor runs for you, such as web search or code execution. Tool is the broader word. Function calling is the older one.
05 · One call, start to finish
What a single call looks like.
Here is the pattern stripped to its bones, using the weather example from Anthropic's documentation. You define one tool. You ask a question that needs it. The model answers with a call, not a sentence.
// 1 · You describe the tool once.
{
"name": "get_weather",
"description": "Get the current weather for a given location.",
"input_schema": {
"type": "object",
"properties": { "location": { "type": "string" } },
"required": ["location"]
}
}
// 2 · You ask: "What is the weather in San Francisco?"
// The model does not answer. It returns a call:
{ "type": "tool_use", "name": "get_weather",
"input": { "location": "San Francisco, CA" } }
// 3 · Your code runs get_weather, then sends back:
{ "type": "tool_result", "content": "..." }
// 4 · Now, reading a real result, the model answers in words.A client tool · the model names the call, your code runs it
Nothing here is magic. The model never touched a weather service. It read your schema, decided the request needed that tool, and produced a clean, typed request for your code to run. The second time it speaks, it is reading a real result.
You are not stuck with whatever the model chooses, either. OpenAI's API lets you force a specific function with the tool_choice setting, or forbid any call by setting it to none. When a call does happen, the response is flagged as a call rather than a finished answer, so your code can tell the two apart before it runs anything. The model proposes. Your side stays in control of what actually fires.
06 · The layer above
One model, many tools, one protocol.
Tool calling solves one model talking to one set of tools you wired up by hand. The moment you have many models and many tools, every pair needs its own integration, and the wiring does not scale.
That is the problem the Model Context Protocol was built for. Anthropic introduced MCP in November 2024 as a universal, open standard for connecting AI systems to data sources, replacing fragmented integrations with a single protocol. A tool exposed once over MCP can be reached by any model that speaks it. The launch shipped with prebuilt servers for everyday systems like Google Drive, Slack, GitHub, Git, and Postgres.
Under the hood it is still tool calling. MCP standardizes how a tool is described and reached, so the same server works across models instead of being rebuilt for each one. The protocol schema is published openly as JSON Schema for anyone to implement.
The standard did not launch as a document alone. Anthropic shipped it with its specification and software kits, local server support in the Claude desktop apps, and an open repository of servers to start from. That is why a developer can connect a dataset to a range of tools quickly rather than writing a new bridge for each one.
07 · What makes it reliable
A model that can act can act wrongly.
Tool calling moves a model from talking to doing, and doing has consequences. A bad call can read the wrong record, spend real money, or send a message you cannot unsend. The discipline that contains it is the same one you would use for any junior operator with system access.
Three things carry most of the weight. Clear tool descriptions, because the description is what the model uses to decide, and a vague one invites the wrong call. Tight schemas, so a malformed request fails fast instead of running. And a human on anything irreversible, so the model proposes and a person approves.
This is where interface work earns its keep. In the systems we build at Bttr., tool calling sits inside the layer where models, workflows, agents, and humans actually meet, and the job is making every call legible before it runs.
Closing
A model with tools stops talking about the work.
Start with one tool and one clear job. Describe it well, keep the schema tight, and watch the first real call go out. That is the moment a model stops being a better search box and starts being something that can act.
Written by · October 20, 2026
Donny Smith · ECD, Founder, Bttr.
Over the past 15 years, he has led creative teams and contributed to products used by millions of people worldwide, working with companies including Apple, Opendoor, JP Morgan, GE Aerospace, Pepsi, and Alterra Mountain Company.
LinkedInShare this perspective
More insights
Adjacent perspectives.
Bttr. Field Brief
The brief Bttr. writes for senior buyers.
Monthly. One signal worth your time on Brand Operating Systems, AI search visibility, and the infrastructure buildout. No filler.