What is tool calling?

Summary slides

Why a model needs this capability at all

A language model’s knowledge comes entirely from its training data, which means it has no way to know today’s weather, a user’s current account balance, or the result of a calculation it hasn’t been specifically trained to compute reliably, and it has no way to change anything in the outside world, sending an email, updating a record, placing an order, purely through generating text. Tool calling exists specifically to bridge this gap, giving a model a structured way to say “I need this specific piece of information” or “this specific action needs to happen” and have that need fulfilled by something outside the model itself.

Without tool calling, a model asked to check current weather or perform a precise calculation has only two options, admit it can’t do that, or, more dangerously, generate a plausible-sounding answer based purely on its training data’s patterns rather than the specific input in front of it, producing a confident, fluent response that happens to be wrong. Tool calling replaces that second, dangerous option with the ability to get the real answer rather than a plausible guess at what the answer might be.

How the mechanism actually works, step by step

Before a conversation begins, the application using the model provides a description of each available tool, its name, what it does, and what arguments it accepts, structured in a format the model has been trained to understand. When the model receives a request that a described tool could help answer, it doesn’t just produce a normal text response, it produces a structured output specifying which tool it wants called and what arguments to call it with, formatted precisely enough that the surrounding application’s code can parse it reliably.

The application receives this structured request, actually executes the corresponding function, whatever code or API call that function represents, and takes the result of that execution and feeds it back into the model as part of the ongoing conversation. The model then continues generating its response with that new information available, either producing a final answer incorporating the tool’s result, or in more complex cases, requesting another tool call based on what the first one returned. This loop, model requests a tool, application executes it, result feeds back, can repeat several times within a single exchange for tasks that need multiple pieces of information or multiple actions completed in sequence.

Why the model itself never actually executes anything

A detail that matters considerably more than it might initially seem is that the model producing a tool call request has no ability to actually execute that request itself, it can only ask, the surrounding application decides whether to comply. This separation isn’t an incidental implementation detail, it’s what makes tool calling safe enough to use at all, since it means every single action a model wants to take passes through a checkpoint where the application can validate the request, check permissions, or refuse to execute it before anything actually happens in the outside world.

This connects directly to the broader discussion of agent permissions and tool-calling security covered elsewhere in this collection, an application that blindly executes every tool call a model requests without any validation has given up the exact safety boundary this separation was designed to provide, while an application that treats each tool call request as something to evaluate before executing keeps a meaningful layer of control between a model’s judgment and real, consequential effects in the outside world.

What makes a tool description effective versus one that leads a model astray

The quality of a tool’s description has an outsized effect on whether a model uses that tool correctly, since the model’s entire understanding of what a tool does, what arguments it needs, and when it’s appropriate to use comes from that description alone, not from any deeper understanding of the actual code behind it. A vague or ambiguous description leaves the model guessing at details it has no other way to know, producing calls with incorrect arguments, calls to the wrong tool for a given situation, or a failure to call an available tool when it actually would have helped.

Writing a clear, precise tool description is closer to writing a clear function signature for another engineer than it is to writing marketing copy, the model needs exact, unambiguous information about what each argument means, what format it expects, and what the tool returns, and any gap between what a description implies and what the tool does becomes a source of confusing, hard-to-diagnose failures once the model starts relying on that inaccurate understanding in practice.

How tool calling scales from a single function to many available tools

A model choosing between one or two available tools faces a comparatively simple decision, but a system with dozens or hundreds of available tools introduces a genuinely harder problem, the model has to correctly identify which tool, out of a large set of options, fits a given request, and descriptions that were perfectly clear in isolation can become confusingly similar or overlapping once placed alongside many others. This connects directly to the discussion of curated tool selection covered throughout this collection’s broader agent design discussions, since giving a model access to every available tool at all times tends to produce worse tool selection than giving it a smaller, more relevant, more carefully curated set for the specific task at hand.

This is part of why systems built around a large number of possible tools often invest in some layer of tool discovery or filtering that narrows down which tools are actually presented to the model for a given request, rather than presenting the model with an enormous, undifferentiated list every single time and hoping it picks correctly regardless of how large or how similar that list becomes.

Where tool calling connects to the broader protocol layer

Tool calling is the model-level capability, the ability to request a function call and receive a result back, while the Model Context Protocol, covered in its own dedicated article elsewhere in this collection, is a standardized way to expose those callable tools across different applications without custom integration work for every pairing. The two sit at different layers of the same overall system, tool calling is what a model does, MCP is one standardized way an application can supply the tools a model calls, and understanding this distinction matters because it’s possible to build tool calling into an application entirely without MCP, using custom, application-specific tool definitions instead, MCP simply offers a more standardized, more broadly interoperable way to supply those same tools.

Why validating a tool call’s arguments still matters even with a well-described tool

Even with a carefully written tool description, a model can still produce a tool call with incorrect, malformed, or unexpected arguments, since the model is generating that structured request based on its own interpretation of the conversation, not through any guaranteed, mechanical process that ensures correctness. A well-built application validates the arguments in a requested tool call before actually executing the underlying function, checking that required fields are present, that values fall within expected ranges, and that the call as a whole makes sense before letting it proceed.

Skipping this validation and trusting every tool call’s arguments blindly is a common source of the kind of confusing, hard-to-diagnose failures covered in this collection’s discussion of AI native debugging, a malformed argument that passes through unchecked can cause a downstream error that has nothing obviously to do with the model’s original request, making the actual root cause considerably harder to trace back to where it actually originated.

Common mistakes teams make around tool calling

1. Writing vague or ambiguous tool descriptions and then being surprised when the model calls the wrong tool or supplies incorrect arguments, when the description itself was the actual source of the confusion.

2. Executing every tool call a model produces without validation, giving up the checkpoint that tool calling’s separation between requesting and executing was specifically designed to provide.

3. Exposing a large, undifferentiated set of tools to a model for every request, rather than curating a smaller, more relevant set that makes correct tool selection considerably more likely.

4. Confusing tool calling itself with the Model Context Protocol, treating MCP as required for tool calling to work rather than recognizing it as one standardized way among several to supply tools.

5. Trusting a tool call’s arguments as automatically correct simply because the tool’s description was clear, missing that the model’s interpretation can still introduce errors even with well-written descriptions.

What connects these mistakes is underestimating how much of tool calling’s actual reliability depends on the surrounding application’s own discipline, clear descriptions, careful validation, thoughtful curation, rather than on the model’s raw capability alone, the mechanism gives a model the ability to request real actions, but it’s the application wrapped around that mechanism that determines whether those requests get handled safely and correctly.

The deeper point about tool calling is that it’s the specific mechanism that turns a language model from something that only produces text into something that can meaningfully interact with the world beyond its own training data, and the quality of that interaction, how accurately the model chooses and uses the tools available to it, depends as much on how thoughtfully those tools are described and governed as it does on the model’s own underlying reasoning capability.