What Is Function Calling?

Function calling — also called tool calling, or tool use — is the mechanism that lets a language model do something other than produce text.

The single most important thing to understand about it is also the most commonly misstated: the model does not call the function. It cannot. It has no runtime, no network access, and no ability to execute anything. What it produces is a structured request — a function name and a set of arguments — and your code decides whether to honour it.

Everything that matters about designing, debugging and securing this follows from that one fact.

The loop

1. You send the model a prompt and a list of available tools, each with a name, a description, and a JSON Schema for its parameters.
2. The model responds either with ordinary text or with a tool call: a structured object naming one of your tools and supplying arguments.
3. Your application detects the tool call, validates it, and executes the corresponding function.
4. You append the result to the conversation and send it back.
5. The model reads the result and either produces a final answer or calls another tool.

Repeat until it stops or you stop it. That loop is the whole of agentic behaviour — see the agentic loop explained.

The naming differs by vendor and the mechanism does not. OpenAI and Google say function calling; Anthropic says tool use. Same thing.

What the model is actually doing

It is a specialised case of structured output. The model has been trained so that, given tool schemas in context, it can emit a token sequence that parses as a valid call against one of them.

Two consequences people miss:

The tool descriptions are prompt. They are not documentation sitting in a registry somewhere; they are text in the context window, read by the model on every call, and they are the only basis on which it chooses. If two tools could plausibly serve the same request, the model will pick between them badly and consistently. Descriptions should say what the tool does, when to use it, and when not to. How to design tools your AI agent can actually use is the detailed version.

Schemas cost context and attention. Every tool contributes its full schema to every request. Twenty tools is a meaningful slice of your context window consumed before the user says anything — and it makes selection harder at the same time. Expose the handful of workflows people actually need, not your whole API surface.

Where it goes wrong

Calling the wrong tool. Almost always a description problem, not a model problem. Two overlapping descriptions produce a coin flip.

Hallucinated arguments. The model fills in a required parameter it was never given. If your prompt does not contain a customer ID and the schema demands one, something will appear in that field. Make optional things optional, validate server-side, and never trust an argument because it type-checks.

Not calling a tool when it should. Usually because nothing in the description matches how the user phrased it, or because the system prompt did not establish that tools should be preferred over recall.

Loops. The model calls a tool, dislikes the result, calls it again with a trivial variation, forever. Cap iterations. Always.

Result formats the model cannot use. Returning a raw API payload with forty null fields and opaque enum codes wastes context and invites misreading. Return a trimmed, labelled subset. And return errors as informative text — no customer found with that ID; ask the user to check it — because the model is your error handler and a stack trace tells it nothing actionable.

Parallel calls, and why order matters

Most current models can request several tool calls at once when the calls are independent — fetch three records, or check weather in four cities. Executing those concurrently is a genuine latency win.

The trap is dependence. If call B needs call A's result, they must be sequential, and a model that requests both in parallel has misunderstood the task. That is usually fixable in the tool descriptions by stating the dependency explicitly.

Security: this is the boundary

Function calling is where a language model stops being a text generator and starts having effects. Treat the tool layer as your security perimeter, because it is.

Every tool result is untrusted input. Whatever your function returns lands directly in the model's context. If it fetched a web page, read an email, or queried a table users can write to, an attacker just contributed to your prompt. This is prompt injection, and function calling is its main delivery route.

Authorisation belongs in your code, not the model's judgement. The model produces a request. Your handler decides whether this user may perform this action on this record. Never infer permission from the fact that the model asked.

Scope tools to least privilege. Read-only where possible. A path-scoped file reader rather than a file reader. Per-tool rate and spend limits.

Gate the irreversible ones with a human. Sending, publishing, paying, deleting, granting access. Not everything — approval fatigue trains people to click through — just the ones you cannot undo.

Guardrails and safety for AI agents covers the layered version.

Function calling and MCP

They are different layers and frequently conflated.

Function calling is the model capability: emitting a structured request against a schema. MCP is a protocol for how an application discovers and connects to tool providers, so the same server works across hosts without bespoke integration.

An MCP server exposes tools; the host presents them to the model; the model function-calls them. MCP does not replace function calling — it standardises where the tools come from. See what is MCP and why it matters and how to build an MCP server.

The short version

The model proposes; your code disposes. Tool descriptions are prompts and deserve prompt-level care. Schemas cost context. Results are untrusted. Authorisation is yours. Cap the loop.

Whether you need this at all — versus a single call with a well-designed prompt — is the question in AI agent vs workflow vs single call and what is an AI agent. More in the AI development pack.

Sources

• Anthropic, Building Effective Agents, 19 December 2024 — the tool-use loop, and the recommendation to find the simplest solution before adding agentic complexity
• Model Context Protocol, Architecture overview — the distinction between a protocol for exposing tools and the model capability that invokes them; tool definition shape (name, title, description, inputSchema) and the tools/call request
• OWASP GenAI Security Project, LLM01:2025 Prompt Injection — why tool results constitute untrusted input, and the case for privilege control and human approval on high-risk actions