What Is Tool Calling (Function Calling)?

Tool calling, also called function calling, is the mechanism that lets a model invoke external functions, APIs, databases, retrievers, code execution environments, or other systems. You describe the available tools to the model, the model decides which one to call and with what arguments, your code executes the call, and the result goes back into the context for the next model call.

One thing to be clear about: the model never executes anything. It emits a structured request. Everything after that is your code, which means the security boundary, the validation, and the blame for a bad call all sit on your side. Tool calling is why a model can act on the world rather than only describe it, and why an agent can take a wrong action rather than only say a wrong thing.

Evaluation has to separate two problems that arrive looking identical. Choosing the right tool is one. Passing valid, safe, intent-aligned arguments is another. Both should be visible in traces and scored independently when they matter.

Key takeaways

• Tool calling is a four-step cycle: you supply schemas, the model emits a structured call, your code executes it, the result returns to the context. The model only does step two.
• The schema is the interface you are designing for the model. Names, descriptions, enums, and required fields do more for accuracy than instructions about being careful.
• The expensive failures are not error responses. They are a valid call with a fabricated identifier, or the right tool invoked at the wrong point in the task.
• Score selection and argument correctness separately, since a combined accuracy number cannot tell you whether to rewrite a description or tighten a schema.
• More tools means worse selection. Overlapping descriptions produce wrong-tool failures that get misread as model weakness.

How a tool call actually works

1. You give the model the tool schemas. Each request carries a list of tool definitions: a name, a description, and a JSON Schema for the parameters. These are tokens in the context like anything else, so twenty tools cost real budget on every call.

2. The model emits a structured call. Instead of prose, the response contains a tool_calls entry naming a tool and carrying an arguments object, signalled by something like finish_reason: tool_calls. Providers constrain decoding against the schema, so the arguments are usually valid JSON of the right shape. Valid against the schema is not the same as correct.

3. Your code executes it. Look up the handler, validate the arguments beyond what the schema can express, check permissions, and run it. Nothing forces you to execute what the model asked for, and for anything that writes data or spends money, a confirmation belongs here.

4. The result returns to the context. The output is appended as a tool-role message tied to the call ID, and the model is invoked again with it. Repeat that cycle and you have the agent loop behind what makes an agent an agent rather than a single generation.

Models can also emit several independent calls in one turn, which your executor may run in parallel. If tool B needs tool A’s output, the schema and description have to make that dependency explicit.

Designing the tools the model sees

Accuracy is mostly determined before the model runs.

• Name for disambiguation. get_order_status and cancel_order are hard to confuse. orders and order_lookup are not.
• Write the description for the caller, not the maintainer. Say what the tool does, when to use it, and when not to. The negative case is the sentence most often missing.
• Constrain the type system. Use enums for closed sets, formats for dates and IDs, and required for what is actually required.
• Keep the surface small. If two tools overlap, merge them or add a parameter. If a tool is rarely correct, remove it and see whether anything degrades.
• Return errors the model can act on. A short typed message such as INVALID_DATE_FORMAT, expected YYYY-MM-DD produces a correction. A raw stack trace invites the model to narrate the error as content.

Failure modes

These are the ones worth instrumenting, roughly in order of how hard they are to notice.

Hallucinated tool names. Return a typed error listing valid tools when an unknown one is requested.

Malformed arguments. Constrained decoding removes much of this class.

Valid-looking but wrong identifiers. Validate IDs against a lookup before executing.

The right tool at the wrong time. Each call looks correct alone while the sequence is wrong.

The call that never happened. Check whether claims in the answer are supported by a call that ran. Tool-side timeouts are a different problem, covered by tests built for how agents actually fail.

Evaluating tool calls

Score the pieces separately, because they have different fixes.

Selection. Given this request and this tool set, was the chosen tool correct? Gradable against a labeled set, and the confusion pairs are the useful output.

Argument correctness. Were the parameters valid, complete, and faithful to the intent? Schema validity is checkable in code for free. Intent alignment needs a reference or a judge.

Sequence and outcome. Did the run call the tools it needed, in a workable order, and did the task get done? Outcome is what a user cares about, and it hides which step went wrong, so it is reported alongside the per-call measures. Assembling those layers into something that runs continuously is the subject of evaluating and optimizing agent skills with tracing and evals.

FAQ

Is tool calling the same as function calling?

Yes. Function calling was the original provider term and tool calling is now more common, partly because tools are not always functions in your codebase. Some APIs still use functions field names for backward compatibility while documenting the feature as tools. Treat them as one concept.

How do I stop the model from inventing tool names or IDs?

For names, keep the tool list short, make the names distinct, and return a typed error listing valid tools when an unknown one is requested. For identifiers, validate every ID against a lookup before the call executes, and prefer a flow where the agent obtains identifiers from a search tool rather than composing them, since a model given a format will produce something in that format whether or not the record exists.

How is tool call accuracy measured?

There is no single number, and reporting one usually hides the problem. Measure selection accuracy against labeled requests, argument validity from the schema in code, argument intent alignment with a judge or a reference, and task completion at the end of the run. Track them per tool, since one badly described tool will drag an aggregate down while the rest of the surface is fine.

How many tools can a model handle?

Fewer than the limit suggests. Selection quality degrades well before the provider’s maximum, especially where descriptions overlap. If a model needs many capabilities, use a router that narrows the set before the call, or subagents that each own a small surface.