Function Calling
A model requesting a tool in a fixed, structured form
- Function calling is how a model hands off something it can't do on its own to an outside program, as a written request.
- The model never runs the tool itself. It only writes down which one to call and with what values.
- So every tool needs a name and its required values spelled out ahead of time before a model can pick it.
- Once the result comes back, the model reads it and finishes the answer. More than one round trip can happen in a single turn.
- It sometimes calls the wrong tool or invents a value, so a check before anything actually runs is needed.
Contents
1The analogy
A doctor doesn't draw blood and peer into a microscope personally. Instead, a lab request slip gets filled out — which test, on what sample, under what conditions, each written into its own field, then sent to the lab. Running the machine is the lab's job, and a report comes back a while later. Only once the doctor has that number in hand does the conversation continue.
Function calling is that same slip. When something comes up a model can't handle on its own — today's exchange rate, a calculation with too many digits — instead of making up an answer, the model writes a request naming which tool to call and with what values. An outside program does the running, and only once the result is back does the model finish the answer.
A slip with fields filled in carelessly gets bounced back by the lab. That's exactly why the request has a fixed form set ahead of time too.
2In detail
A model's job stops at writing the request
A language model is a text-continuation machine — it has no hands to reach the internet or save a file. Function calling isn't a way of bolting hands on. It's a way of asking a program that already has hands to run an errand.
What a model produces is still just text. Instead of a sentence meant for the user, though, it produces a short request with a tool name and values slotted into fixed fields. The program wrapping the model is what actually reads that request and runs it for real.
So what's allowed to run, and what gets blocked, is entirely up to the program. However convincing a request the model writes, nothing happens unless the program actually hands it that tool.
Tool manuals get handed over ahead of time
A model has no way of knowing on its own what tools exist in the world. So a list of tools gets included at the start of the conversation — a short manual with each tool's name, what it does, and which values it needs or doesn't.
That description is the instruction manual. Write "give a city name and get back today's weather there," and the model reaches for that tool when a weather question comes up. A vague description gets it called in the wrong situation; missing the value format leads to the model filling it in however it likes. Half of getting a tool used well is polishing that description.
Pinning down the shape of each value matters too. What order a date goes in, what language a city name should be in — leave that unspecified and the program can't make sense of what comes back.
The result comes back and gets folded into the answer
Whatever result the program gets from running the tool gets folded back into the conversation. To the model, it looks like a fresh piece of information just arrived. It reads that value and continues the answer, or writes another request if one more is needed.
Plenty of tasks don't finish in one pass. Call a search tool to find candidates, pick one and call a lookup tool for details, then wrap it all up in an answer — that kind of thing. This back-and-forth of requests and results, repeated as many times as it takes to finish, is the backbone of an AI agent.
Wrong calls happen too
A model picks which tool to call based on probability, so mistakes happen. It calls a tool when there was no need to, skips calling one when there was, or fills a value in wrong. A word resembling a tool's name sitting somewhere in the conversation can pull it toward calling that tool too.
That's why a program double-checks whether a value matches the expected format and sends it back to be rewritten if it doesn't. For anything irreversible — sending an email, a payment, a delete — the program asks a person before it runs. A sentence hidden inside a document or a webpage can also trick a model into calling the wrong tool, which is exactly why a dangerous tool should be handed a narrow set of permissions.
3More precisely
What a model produces in function calling is a short block of structured data — a tool name and its values. Which tools are available gets handed to the model as a list in a fixed format ahead of time; running the tool and returning the result are entirely the outside program's job.
The analogy breaks down somewhere. A doctor knows the lab genuinely exists before writing a request slip; a model only has the description sitting in that list to go on. It can imagine a tool that was never in the list and call it anyway, and it can take a strange result at face value and carry it straight into the answer. There's no separate set of eyes checking the result. And picking a tool isn't a careful, deliberate review the way a person does it — it's closer to producing whatever request looks most likely to come next, given the conversation so far. That's why the same question sometimes calls a tool and sometimes just answers plainly, with no consistent line between the two. Writing a tool's description clearly, together with guidance on exactly when to call it, makes the outcome far steadier. Function calling is the fixed form that request takes — a narrower idea sitting underneath the wider judgment of tool use, which decides whether and when to reach for a tool at all.
4Try it yourself
5Common misconceptions
It's easy to think turning on function calling means the AI runs the program itself, but actually it only writes the request — an outside program does the running.
It's easy to think attaching a tool makes wrong answers disappear, but actually skipping a call it needed, or misreading a result it got, still leads straight to a wrong answer.
It's easy to think more tools attached is always better, but actually a longer set of descriptions makes picking harder, and the wrong tool gets chosen more often.
7One-line summary
In shortFunction calling hands off what a model can't do to an outside program as a request in a fixed form, then folds the returned result back in to finish the answer.
Spotted an error or have a better analogy? Suggest an edit · Last updated2026-09-02