Function calling is how a language model reaches outside its own text and gets things done. On its own a model can only produce words; with function calling it can say, in a structured way, "call get_weather with city = Denver," and your code runs that function and hands the result back. The model never executes anything itself. It proposes; your application disposes. That single mechanism is what turns a chatbot into something that can look up live data, book a meeting, or run a workflow.
What changed in 2026
- Parallel tool calls became standard. Models now routinely request several functions in one turn, so a well-designed app runs independent calls concurrently instead of one at a time.
- The Model Context Protocol gained traction. A shared way to expose tools to any model reduced the per-vendor glue code teams used to write.
- Structured output got more reliable. Constrained decoding means the arguments a model emits now validate against your schema far more often than they did a couple of years ago.
How function calling works
The loop is simple once you see it:
- You define tools. Each has a name, a plain-language description, and a typed parameter schema, usually JSON Schema.
- You send the tools with the prompt. The model sees what is available and what each does.
- The model decides. It either answers directly or returns a structured request to call one or more tools with specific arguments.
- Your code executes. You validate the arguments, run the real function, and capture the result.
- You return the result. The model reads it and either answers or calls another tool. The cycle repeats until it is done.
The critical point is step four: the model's request is just text shaped like a function call. Nothing runs until your code chooses to run it, which is exactly where validation and permission checks belong.
Function calling vs alternatives
Teams sometimes reach for function calling when a simpler approach fits, or the reverse.
| Approach |
What it is |
Best for |
| Function calling |
Model requests typed tool calls |
Actions, live data, agents |
| Plain structured output |
Model returns JSON matching a schema |
Extraction, classification, no side effects |
| Retrieval (RAG) |
Fetch documents into the prompt |
Grounding answers in your data |
| Fine-tuning |
Bake behavior into the model |
Fixed style or format at scale |
If you only need the model to return clean structured data with no external action, plain structured output is lighter than the full tool loop.
When to use it
Use function calling whenever the model needs current information, needs to take an action, or needs a computation it cannot do reliably in its head, such as math or database lookups. It is the backbone of agents, and it pairs naturally with memory so an agent can act across many steps. See AI agent memory for how those steps persist. Do not use it for tasks a single well-crafted prompt already handles; the extra round trips add latency and cost.
Common pitfalls
- Too many tools. Accuracy drops as the tool list grows. Keep it small, or route to a subset before calling the model.
- Vague descriptions. The model chooses tools from their descriptions. A fuzzy description produces wrong choices. Write them like documentation.
- Trusting arguments blindly. Models hallucinate arguments and occasionally call the wrong tool. Validate types, ranges, and permissions before executing.
- No error path. When a tool fails, return a clear error message the model can read and recover from, rather than crashing the whole turn.
FAQ
Is function calling the same as an AI agent?
No, but it is the core enabling piece. An agent is a loop that plans and acts over many steps; function calling is the mechanism it uses to act. See AI agent orchestration for the loop around it.
Does the model run my code?
Never. The model only produces a structured request. Your application decides whether and how to execute it, which is what keeps it safe.
What format are the arguments in?
Almost always JSON that conforms to a schema you provide. Modern models use constrained decoding to make that JSON valid far more consistently than free-form generation.
How is this related to the Model Context Protocol?
Function calling is the model-side ability to request tools; the Model Context Protocol is a standard way to expose those tools so many models and clients can share them.
Where to go next