Function Calling (Tool Use): Getting AI from Talking to Doing

Large models can chat, but they can’t check the weather, place an order, or query a database by themselves. Function calling teaches the model to ask for tools: it decides which to call and what parameters to fill, while the real work is executed by external code — AI moves from talking to doing.

What function calling is

A traditional chat model only emits text. Function calling lets it embed a structured instruction in its answer: I want to call this function, with these parameters. External code reads that instruction, executes it, and feeds the result back to the model. In one sentence, the model goes from talking to directing: it doesn’t query the database or change the order itself, but it can command the tools that do. This step is AI’s leap from chatting to executing.

How it differs from a normal text reply

A normal reply is for humans; a function call is for programs. The former is natural language and loose; the latter is strict structure, parseable. The model has to learn when to talk and when to call. The distinction relies on convention: the model’s output carries the calling part in a specific format, and your code recognizes and executes it from that. With a clear format, humans and programs don’t fight over interpretation.

How the typical flow goes

The user asks; the model decides whether a tool is needed; if so, it outputs a call instruction; your code executes and gets the result; the result goes back to the model; the model composes the final answer based on it. One round or several, until the answer is done. It’s like the model being the dispatcher and code being the hands and feet. The model handles understanding and decisions; code handles reliable execution. This division of labor — both smart and stable — is the skeleton of tool use.

How to write tool schemas

Each tool has to tell the model: what it’s called, what it does, what parameters it needs, and each one’s type. This description is the schema; the clearer it is, the more correctly the model calls it. A vague schema earns randomly filled parameters. Writing a schema is like writing a product manual: parameter meaning, whether required, and value ranges all spelled out. The model works from the manual, and manual quality directly determines call quality. Don’t skip this effort.

Parameter validation can’t be skipped

The model’s parameters can be wrong — wrong types, missing required fields, absurd values. Validate before executing; reject non-compliant ones and have the model refill or prompt the user, rather than running them directly and blowing up the system. Validation is the safety net: it guards against the model’s slip-ups and against malicious construction. Treat validation as a standard part of the interface, not an option. The more a tool can change reality (placing orders, deleting data), the stricter validation must be.

How to pick among multiple tools

When you attach several tools to the model, it has to pick the right one. It distinguishes them by the functional description in the schema — if the description says clearly when to use me, the model can choose correctly among similar tools. Too many tools also confuse it, like handing a person a long row of buttons with no obvious meaning. Mount as needed, name clearly, describe thoroughly, and the model won’t call the wrong one. The tool set is also something to design; more isn’t always better.

Failure and retry

Tool execution can fail — the interface is down, the parameters get rejected. You need retry and fallback: retry first; if it still fails, tell the model it failed so the model can try another way or hand off to a human, instead of getting stuck. Also structure the failure information into language the model can understand, so it can adjust accordingly. How well you handle failure decides whether the system is fragile or robust. Especially in production.

The relationship with agents

The essence of an agent is a model plus a pile of tools plus a loop: the model keeps deciding which tool to call, looking at the result, then deciding the next step, until the task is done. Function calling is the agent’s engine. Understand this layer and you’ll see why an agent’s capability ceiling is constrained by the model: the better the model dispatches, the smarter the agent. Function-call quality is nearly synonymous with agent quality.

Security risks

Function calling lets the model trigger real actions, so risk jumps: wrong calls, over-calls, and being induced by injection to call dangerous tools. Minimize permissions, add confirmation for write operations, and don’t expose sensitive interfaces for the model to call freely. Also guard against prompt injection abusing function calls to do harm — like tricking the model into dropping a database. Treat function calling as an attackable entry point when defending; permissions and review are both essential.

Connection with MCP

When there are many tools spread across systems, wiring each one individually gets expensive. Protocols like MCP standardize how tools are exposed and called, letting the model use tools from various providers through a unified way. Function calling is the capability; MCP is the connection standard. Understand this layer and you won’t settle for hand-writing a few tools. When tools come from multiple services, protocol-based integration makes expansion cheap, and the agent’s toolbox becomes a real system.

Three common pitfalls

Pitfall one: a vague schema, so the model fills parameters randomly. Pitfall two: no validation, executing directly and blowing up the system. Pitfall three: permissions too broad, letting the model be induced into dangerous actions. All three are solved by writing clear schemas, validating before execution, and least privilege. Function calling is powerful, and the guardrails have to match.

How to start debugging

Function calling is hard to debug because you need to see why the model called that way. The approach: log every round’s model output, execution result, and fed-back content, and review where its judgment went off. Also craft edge cases — missing parameters, tool conflicts, ambiguous intent — and watch how the model responds. Debugging function calls is half tuning the model, half tuning the schemas and flow.

How to evaluate the results

Test with a real task set: whether the model called the right tool, whether the parameters were right, and how well the final answer came out. Don’t just look at whether it can call — look at whether it calls correctly and answers accurately. Break the metrics apart: call accuracy, parameter accuracy, task completion rate. Only by looking at all three together do you know whether function calling truly stands, or just puts on a show on simple samples.

Selection and rollout rhythm

Start with one tool to get the loop of judgment, calling, execution, and feed-back running, validate the experience, then gradually add tools, multi-round, and permission controls. Small scope means low cost of making mistakes. Get schemas, validation, logging, and permissions all in place before scaling. Function calling is the key leap from chat to execution; once the foundation is solid, the agent goes far.