Tool calling (function calling)

What it is

A model on its own can only produce text. With tool calling, the application tells the model which functions exist, each with a name, a description and a JSON Schema for its arguments. When the model decides a function would help, it returns a structured call instead of prose. The application runs the function and sends the result back. OpenAI's documentation calls it function calling; Anthropic's calls it tool use. The idea is the same.

Why it matters

Tool calling is what turns a chat model into an AI agent. It lets the model read live data and take actions: look up an order, create a ticket, send an invoice. It also moves risk. Once a model can call a function that writes, a wrong guess becomes a wrong action in a real system.

How it works

OpenAI's guide describes the loop in five steps:

1. Send the model a request with the tools it may call.
2. Receive a tool call from the model.
3. Run the code in your application with the arguments it chose.
4. Send a second request with the tool's output.
5. Receive the final answer, or more tool calls.

In Anthropic's API the model signals this with stop_reason: "tool_use" and a tool_use block; the application replies with a tool_result. Tools the provider runs itself, such as web search, are called server tools; tools your code runs are client tools. The Model Context Protocol standardises how the application finds those functions on other systems.

Example

Asked "what's the weather in Wellington?", the model returns a call to get_weather with {"location": "Wellington"}. The application calls a weather service and returns "14 degrees, windy". The model answers in a sentence.

Common pitfalls

• Invented arguments. Anthropic's documentation notes that when a required parameter is missing, a model may infer a plausible value rather than ask. Validate on the server.
• Duplicate writes. A retried call after a timeout can run twice. Use an idempotency key.
• Too many tools. Selection accuracy falls as the list grows. See tool overload.
• Policy in the prompt. "Never delete anything" in a system prompt is advice, not a control. See agent permissions.

How actionlake handles it

With actionlake, the server governs step 3, the execution. When an agent calls do, the server validates the arguments against the action's schema, checks the key's scope, reserves against its spending cap, holds the call for approval if a rule says so, deduplicates the write, sends it, and records the outcome in the ledger with the agent's stated intent. Before any of that, check runs the same validation as a free dry run. The platform page shows the full path.