How does AI tool calling actually work?

The model is given a menu, not a keyboard

Before a request is sent, the application describes the tools available to the model: a name, a description of what each one does, and a schema for the arguments it expects. The model does not receive working code or a live connection to anything — it receives a description, the same way a person reads a menu without having access to the kitchen.

The model never executes anything itself

When a model decides a tool would help, it produces a structured output — typically a tool name and a set of arguments — and stops there. Nothing has been searched, called, or changed yet. The application that sent the request reads that structured output, decides whether to act on it, and if so, runs the real function or API call on its own infrastructure.

A full exchange is a loop, not a single step

The typical sequence is: the application sends a prompt plus the list of available tools; the model responds with either an answer or a proposed tool call; if it is a tool call, the application executes it and sends the result back as part of the conversation; the model then continues, often producing a final answer that uses that result. Multi-step tasks can repeat this loop several times before a response reaches the user.

A proposed call is a plausible guess, not a guaranteed correct one

A model can propose the wrong tool, invent an argument that was never in the schema, or call a tool when nothing needed calling at all — the same probabilistic generation that produces any other output produces a tool call. Nothing about the mechanism makes a proposed call inherently safe to run. An application that executes arguments without validating them against the schema, and without authorizing what the call is actually allowed to touch, is trusting a guess with real access.

The schema is the only interface the model actually sees

A tool’s name, description and argument schema are the entire specification the model has to work from — it has no other way to learn what a tool does or how to fill in its parameters correctly. The same underlying function described clearly and narrowly tends to get called correctly far more often than one described vaguely or bundled with unrelated options, because the model is choosing and filling arguments from that description alone.

Why this is different from asking a model to write code

Asking a model to produce a working script and asking it to call a predefined tool are not the same request. A tool call is constrained to a name and arguments your application already knows how to handle safely; free-form generated code can attempt to do anything the environment running it allows, which is a much larger and different problem to secure. Tool calling narrows what a model can ask for to a fixed, inspectable set of options.

Questions people ask

Does the model run the tool itself?

No. The model outputs a structured request naming a tool and its arguments. The application that sent the request decides whether to execute it, and the actual function or API call runs on the application’s own infrastructure, not inside the model.

Can a model call a tool with made-up arguments?

Yes. A model can supply a value that was never part of the schema, or that does not make sense for the tool, because the call is generated the same way any other output is. Validating arguments before executing anything real is the application’s responsibility, not something the model guarantees.

What happens if the model calls the wrong tool?

That depends entirely on how the application is built. A well-built one checks whether the call makes sense before executing it and can return an error or a clarifying result back to the model rather than acting on a mismatched request; a poorly built one executes whatever it receives.

Is tool calling the same thing as an AI agent?

No, but agents are usually built on top of it. Tool calling is the underlying request-response mechanism; an agent typically repeats that loop multiple times, with additional logic deciding what to try next based on each result.