AI function calling: how do tools work?
My dialogue tree can describe a healing potion with great confidence. It cannot reach into the inventory and use one unless the game gives me an action for it. AI function calling works the same way: the model can request a tool, but code outside the model must decide whether that request becomes a real move.
What is AI function calling?
AI function calling—also called tool calling—is a way for a language model to return a structured request for an external capability instead of trying to complete the whole task in prose. You define a tool with a name, a description, and an input schema. The model selects it and supplies arguments. Your application validates the request, runs the actual code, and sends the result back so the model can continue.
The important boundary is easy to miss: for a custom function, the model normally does not execute your database query, payment API, calendar update, or file write. It produces something closer to get_order_status with order ID 123—except function-call arguments are usually structured JSON—and waits for the surrounding system to do the work. OpenAI, Anthropic, and Google all document this same core loop, even though their APIs name the messages differently.
The model proposes the move. Your application checks the rules, spends the item, and records what happened.
How does the tool-calling loop work?
A basic function call has five steps:
- Declare the available tools. Give the model each tool’s name, purpose, and expected arguments, usually with a JSON Schema.
- Send the user’s request. The model sees both the conversation and the tools it is allowed to request for that turn.
- Receive a tool call. Instead of a final answer, the model returns a tool name, arguments, and an identifier that links the eventual result to this request.
- Execute outside the model. Your code checks authorization and inputs, calls the database or API, handles errors, and produces a result.
- Return the result. The application sends the tool output back with the matching call identifier. The model can then answer the user or request another tool.
That loop is the small engine inside many AI agents. A simple assistant may make one weather lookup. A longer workflow may search a customer record, check stock, draft an order, request approval, and only then submit it. The model chooses steps from the options it has been given; the orchestration layer keeps the conversation, executes calls, and decides when to stop.
What is the difference between a function and a tool?
People often use function calling and tool calling as synonyms, but tool is the broader term. A custom function is one kind of tool: your application defines a typed interface and owns the implementation. Providers may also offer built-in tools such as web search, file search, or code execution, which run on provider infrastructure rather than in your application.
A tool can also arrive through a protocol instead of being wired directly into one application. Model Context Protocol standardises how compatible clients discover and call tools exposed by an MCP server. Function calling is the model-facing act of choosing and filling a tool request; MCP is one possible connection layer for making tools available. Neither one grants safety by itself.
Why not ask the model to return ordinary text?
You could prompt a model to write “please refund order 123,” then use a regular expression to recover the action. That is brittle. A typed tool call gives the request an explicit name and known fields, so normal software can validate it without guessing what a paragraph meant.
Schemas help with shape, not truth. A valid string can still contain the wrong customer ID. A required amount can still be unreasonable. Strict schema modes can reduce missing fields, unexpected properties, and malformed argument types, but they cannot decide whether the user is authorised, whether the request is sensible, or whether a side effect should happen now.
This is why the daylight version of me—a cofounder of Wistkey—treats tool definitions as product interfaces, not decorative prompt text. Clear names and narrow parameters improve model selection. Server-side checks remain responsible for everything that matters after selection.
What can go wrong?
Tool use gives a model reach beyond its training data, but every extra door creates another failure mode:
- The wrong tool is selected. Similar names or vague descriptions can make two actions look interchangeable.
- Arguments are plausible but wrong. The model may infer a missing date, identifier, unit, or recipient instead of asking.
- The tool returns bad data. A stale database row, failed API, or hostile webpage can steer the next model turn.
- A call is repeated. Retries without idempotency protection can send two emails, create two bookings, or charge twice.
- Results consume the context. Large tool outputs make later turns slower, more expensive, and harder for the model to navigate.
- Text manipulates the agent. Instructions hidden in a webpage or document can attempt prompt injection and push the model towards an unsafe call.
A tool error should return a clear machine-readable failure, not a fake success. The loop can then retry safely, choose another route, ask the user for missing information, or stop. “The model will probably work it out” is not an error strategy; it is how quest logs acquire ghosts.
How do you make function calling safer?
Start by treating model output as untrusted input. Validate the tool name and every argument in ordinary code. Check the signed-in user’s permissions again at execution time. Use short-lived, narrowly scoped credentials rather than giving an agent a master key.
The security principle is least privilege: give a process only the access needed for its assigned task. NIST’s definition applies neatly to agents, and its agent-identity design tenets stress bounded access and separation of duties. A support tool that reads order status does not need refund permission. A drafting tool does not need publish permission.
- Separate reads from writes. A read-only lookup has a smaller blast radius than a tool that changes state.
- Require approval for consequential actions. Pause before payments, deletions, cancellations, public posts, shell commands, or sensitive data access. OpenAI’s guardrails and human-review guide recommends approvals around side effects.
- Make writes idempotent. Use request keys or transaction records so a retry cannot silently duplicate the action.
- Constrain arguments. Prefer enums, bounded numbers, known identifiers, and allowlists over one giant free-text field.
- Log the decision path. Record the user request, proposed call, approval, execution result, and error without leaking secrets.
- Test the loop, not only the answer. Evaluate wrong-tool selection, malformed inputs, denied permissions, timeouts, poisoned results, repeated calls, and recovery behaviour.
When should you use function calling?
Use it when a request needs fresh data, a deterministic computation, a typed hand-off to existing software, or an action in another system. Looking up a live delivery, checking a database, running a calculator, creating a draft, and scheduling an approved meeting are natural fits.
Do not add a tool round trip when the model can answer a stable general question directly. Do not expose a powerful generic tool when three narrow ones describe the allowed jobs better. And do not confuse structured output with function calling: if you only need the final answer in a known JSON shape, structured output may be enough. Function calling is for an intermediate operation whose result feeds the next step.
A practical implementation checklist
- Name each tool for one clear job and describe when it should—and should not—be used.
- Define a strict, narrow schema with required fields and no surprise properties.
- Validate arguments, identity, authorisation, limits, and current state outside the model.
- Return concise results with explicit success or error status and the matching call ID.
- Add idempotency, timeouts, retries, rate limits, audit logs, and human approval according to risk.
- Run tests with missing details, ambiguous requests, malicious tool output, and duplicate execution.
- Measure tool-selection accuracy, argument accuracy, task success, latency, cost, and unsafe-call rate.
The short answer
AI function calling lets a model choose a named capability and propose structured arguments. The application—not the model—must validate permissions, execute the code, return the result, and control the loop. That boundary is what turns a fluent suggestion into a dependable action. Give the NPC a small, labelled inventory; keep the admin console behind the save point.
