Function calling lets a large language model request that your code run a defined function and then use the result, turning a text generator into…
Recap how one function call flows between model and code.
Function calling adds one ability: instead of answering in prose, the model can output a structured request to call one of the functions you gave it. The model decides which tool and with what arguments; your code executes it and returns the result; the model then uses that result to answer.
So one tool use spans two model turns — request, then answer — with your code doing the work in between. Everything that follows builds on this loop.
Give the model several well-described tools and let it choose.
Most apps expose several tools, and the model picks which to use based on their descriptions. That makes description quality critical: each tool needs a name and description that clearly say when to use it, and an argument schema (JSON Schema) that constrains inputs. Keep tools distinct — overlapping tools confuse the choice.
Tool-choice settings give you control: usually the model decides whether any tool is needed, but you can force it to use a specific tool, or forbid tools when you want a plain answer. Fewer, sharper tools beat a large, fuzzy set.
[
{ "name": "search_orders",
"description": "Find a customer's orders by email.",
"parameters": { "type": "object",
"properties": { "email": { "type": "string" } },
"required": ["email"] } },
{ "name": "issue_refund",
"description": "Refund an order. Requires human approval.",
"parameters": { "type": "object",
"properties": { "order_id": { "type": "string" } },
"required": ["order_id"] } }
]Two tools with sharp, non-overlapping descriptions so the model knows which fits a request. The schemas force valid arguments, and issue_refund's description flags that it needs approval — a hint the surrounding system enforces, not the model.
Apply the patterns that make tool use fast, robust, and agentic.
When a request needs several independent lookups, modern models can emit parallel tool calls in one turn — check weather and check calendar together — which your code runs concurrently and returns as a batch, cutting latency.
Tools fail, so handle errors as data: return a clear error message to the model rather than crashing, and it can retry with different arguments, try another tool, or explain the problem. Robust tool use treats failures as part of the conversation.
Loop the round trip and you have an agent. After a tool result comes back, the model may decide it needs another tool, and another, chaining calls until the goal is met. A single call answers a one-step question; the loop, with a stop condition, handles multi-step tasks by deciding each next action at run time.
Keep tool use safe and avoid the errors that break it.
Tools give the model real power, so constrain it. Validate arguments before executing — the model can be steered by injected content, so never trust inputs blindly. Require human approval for irreversible actions (refunds, sends, deletes), give each tool the least access it needs, and log every call.
Common non-security mistakes: vague or overlapping tool descriptions (wrong tool chosen); loose schemas that let bad arguments through; too many tools degrading selection; and forgetting to feed tool results back so the model can finish. Keep the set small and sharp, and test the tools the model actually picks.
Function calling lets a model request a defined function that your code executes and returns, spanning two turns. Real systems expose several sharply described tools and let the model choose, use parallel calls for independent lookups, handle tool errors as data the model can react to, and loop calls to become an agent. Keep tools distinct with strict schemas, and secure them: validate arguments, gate irreversible actions behind human approval, apply least privilege, and log calls.
Design the tools for a travel assistant (search flights, book flight, get weather). Write each tool's description and which needs human approval, decide which calls could run in parallel, and name one argument validation you'd add before executing the booking tool.
In function calling, who executes the function the model requests?
The model decides the call; execution is always on your side, which is what lets you validate arguments and control access.
How does the model choose which tool to call?
Selection is driven by tool descriptions; overlapping or vague tools cause wrong choices, and tool-choice settings give you extra control.
What are parallel tool calls?
For independent lookups, parallel tool calls let the model batch work in a single turn, and your code executes them together.
What is a key safety practice for tool use?
Because tools grant real power and models can be manipulated, validating inputs, gating risky actions, and least privilege are essential.