Function calling (tool use)
Last verified: June 2026· definition
With function calling (also called tool use), you describe available tools to the model; when appropriate, it returns a structured request to call one with specific arguments. Your code runs the tool and feeds the result back, often in a loop.
It’s the mechanism behind agents and most LLM integrations with real systems. MCP builds on top of it by standardizing how those tools are exposed and discovered across clients.
Reliable tool use depends on clear tool descriptions, validated inputs, and graceful error handling so the model can recover when a call fails.
The model requests, your code decides
Function calling does not let a model execute anything. It returns a structured request naming a function and its arguments, and your code chooses whether to run it. That gap is the entire security model: validation, permission checks, and rate limiting all live in your handler, and none of it can be bypassed by the model deciding otherwise. Treating the request as untrusted input rather than as an instruction is the correct posture, particularly when the conversation includes content from elsewhere.
Descriptions are prompts, not documentation
The model chooses between functions using their names, descriptions, and schemas alone. A description explaining what a function does but not when to use it leaves the model guessing at the trigger condition, which produces exactly the intermittent behaviour teams find hardest to debug. Leading with the circumstances in which the function applies, and stating what it does not cover, improves selection more than any amount of instruction elsewhere in the prompt.
Fewer, broader functions select better
Selection accuracy degrades as the number of available functions grows, because descriptions inevitably start to overlap and the model has to discriminate between near-neighbours. A small set of task-shaped functions is chosen more reliably than a large set mirroring individual API endpoints. Where a large surface genuinely must be exposed, grouping related operations behind fewer entry points usually works better than enumerating them all.
Parallel calls and partial failure
Models can return several tool calls in one response, and client code that reads only the first silently drops the rest — a bug that presents as a tool not running even though it was requested correctly. Handling the full set also means deciding what happens when one call succeeds and another fails, since the model will see both results and needs enough information to recover rather than simply retrying the whole sequence.
Errors returned to the model are prompts
Whatever your handler returns on failure becomes context the model reasons over next. A bare error code gives it nothing to act on, so it tends to retry the identical call. An error stating what was wrong, and where possible what would be valid, lets it correct itself on the following turn. Treating error strings as part of the prompt design rather than as logging output is one of the cheapest reliability improvements available.
Common misconceptions
MythFunction calling lets the model run code.
RealityIt produces a structured request. Execution is entirely your code’s decision, which is where validation and authorisation belong.
MythA valid schema means valid arguments.
RealitySchema validation confirms shape, not sense. A well-formed request can still reference records the caller may not access, so authorisation must be checked separately.
MythMore functions make the agent more capable.
RealityPast a point they make it less reliable, because selection accuracy falls as descriptions overlap. Capability is bounded by correct selection, not by the size of the menu.
Frequently asked questions
What is the difference between function calling and MCP?
Function calling is a provider-specific model capability — each vendor has its own format for declaring functions and returning calls. MCP is an open protocol for exposing tools over a standard interface, so one server works with any MCP-capable client. They operate at different layers: MCP servers are commonly surfaced to a model through that model’s own function-calling mechanism. MCP is about portability and reuse; function calling is the underlying model feature.
Why does the model call the wrong function?
Usually because two descriptions overlap enough that the correct choice is genuinely ambiguous from what the model can see. Rewrite descriptions to lead with distinct trigger conditions and state explicitly what each function does not handle. If several functions do similar things, consolidating them is often better than trying to word your way to a distinction that is not really there.
Should I validate function arguments?
Always, and beyond schema validation. Schema checks confirm the shape is right; they do not confirm the values are permitted. Anything the model supplies can be shaped by content it has read, so identifiers, scopes, and record references need authorising against the authenticated session rather than trusted because they parsed cleanly.
Go deeper
What is the Model Context Protocol (MCP)?
The Model Context Protocol (MCP) is an open standard, introduced by Anthropic in late 2024, that defines one uniform way for an LLM application to connect to external tools and data through a client-server protocol built on JSON-RPC.
MCPHow to build an MCP server
An MCP server is a small program that exposes your tools, data, and prompts to an AI client over a standard protocol — the fastest way to give Claude or Cursor safe, structured access to your systems.