Function calling / Tool use

What is function calling?

Function calling — also called tool calling or tool use — is the mechanism that lets a large language model (LLM) request that external software run on its behalf. Instead of generating a final answer from its training data alone, the model outputs a structured message — typically a function name plus arguments in JSON — that the surrounding application interprets, executes, and feeds back. The model never runs the tool itself; it only decides when to call it and what to pass in [1].

How it works

The typical function-calling loop has five steps:

1. Define tools. The developer describes each available function — its name, purpose, and the parameters it accepts — in a structured schema (usually JSON Schema). This description is sent to the model alongside the user’s message [1].
2. Model decides. The LLM reads the tool descriptions and the conversation context. If it determines that calling one or more tools would help answer the request, it returns a structured tool call — a function name and a set of arguments — instead of (or before) a final text response [2].
3. Application executes. The surrounding application receives the tool call, runs the actual function code — an API call, a database query, a calculation, a file operation — and captures the result. The model never touches the external system directly [3].
4. Result fed back. The application sends the function’s output back to the model as a tool result message in the conversation.
5. Model responds. The LLM incorporates the tool result into its reasoning and produces a final, user-facing answer — or, if the task requires it, issues additional tool calls, chaining multiple steps together [1].

This loop can repeat across multiple turns, allowing the model to gather information incrementally before responding.

Client tools vs. server tools

Function-calling implementations typically distinguish two categories:

• Client tools run in the developer’s application — custom APIs, databases, business logic. The developer controls the code and its permissions.
• Server tools run on the model provider’s infrastructure — web search, code execution, file retrieval. The provider controls availability and behavior [2].

Most agentic systems combine both: a core set of server-provided capabilities augmented by domain-specific client tools.

Why function calling matters for AI agents

Without function calling, an LLM is limited to generating text from its training data. With it, the model becomes the reasoning layer of a system that can act on the world — reading live data, triggering workflows, making purchases, sending messages. This is the bridge between a chatbot and an AI agent [3].

Function calling is also the foundation for multi-agent coordination: one agent’s tool call can invoke another agent, enabling delegation chains across complex tasks.

Security: the excessive agency problem

The power to act on the world introduces risk. OWASP LLM07:2025 identifies “Excessive Agency” as a top-10 vulnerability for LLM applications [4]. It arises from three kinds of excess:

• Excessive functionality — too many tools available to the agent, expanding the attack surface.
• Excessive permissions — tools granted broader access than the task requires.
• Excessive autonomy — insufficient human oversight for high-impact or irreversible actions.

If a prompt injection or hallucination causes the model to issue an unintended tool call — deleting records, exfiltrating data, authorizing a payment — the consequences depend on how well the application constrains what the tools can do. Function calling is a capability, not a safety mechanism. The guardrails around it determine whether it is useful or dangerous.

Best practices

• Narrow scope. Only expose tools the agent actually needs for the current task. Avoid open-ended capabilities like unrestricted shell access.
• Least privilege. Each tool should have the minimum permissions required. A weather lookup tool does not need write access to a database.
• Input validation. Sanitize and constrain the parameters the model sends. Do not pass raw model output directly to sensitive APIs.
• Human-in-the-loop. Require human approval for high-impact, irreversible, or sensitive actions — payments, deletions, external communications [4].
• Error handling. Gracefully manage tool failures, timeouts, and unexpected outputs. The model should not see raw stack traces as tool results.
• Logging. Record every tool call — name, arguments, result, timestamp — for auditability and debugging.

Function calling across providers

All major LLM providers support function calling, though terminology and API details vary:

• OpenAI uses the tools parameter in its Chat Completions and Responses APIs, with support for parallel tool calls and strict schema enforcement [1].
• Anthropic (Claude) supports client tools (developer-executed) and server tools (Anthropic-executed, including web search and code execution) via its Messages API [2].
• Google (Gemini) supports function declarations via JSON Schema, parallel and compositional function calling, and connection to remote MCP servers for external tool ecosystems [3].

The Model Context Protocol (MCP) is an emerging open standard that aims to make tool definitions portable across providers, reducing the need to re-implement the same tools for different APIs.

Common reader questions

Does the LLM actually run the function?

No. The model generates a structured request — a function name and arguments — but the surrounding application executes the actual code. The model decides what to call and with what inputs; the application decides whether to run it and handles the execution. This separation is a deliberate design choice that keeps the model isolated from direct system access.

How does the model know when to call a tool?

The model reads the tool descriptions provided in the request and decides based on context whether calling a tool would help answer the user’s question. If the user asks “What’s the weather in Tokyo?” and a weather tool is available, the model will typically call it. If the same question is asked without any weather tool defined, the model will answer from its training data or say it cannot check live weather. The quality of the tool description directly affects whether the model calls the right tool at the right time.

What happens if the model calls the wrong tool or passes bad arguments?

The application receives the tool call and can validate it before execution — checking that the function name is valid, the arguments are well-formed, and the action is permitted. Well-designed systems reject invalid calls and return an error message to the model, which can then adjust. This is why input validation and least-privilege permissions are critical: they limit the damage from incorrect tool calls.

Is function calling the same as agentic AI?

Function calling is a capability that enables agentic behavior, but it is not the same thing. An agent is a system that uses function calling (among other techniques) to pursue goals autonomously over multiple steps. A single function call to look up a stock price is not agentic; a system that plans a multi-step research task, calls several tools in sequence, checks its own work, and reports back is. Function calling is one of the building blocks; agency is the architectural pattern built on top of it.