Tool Calling: How an AI Agent Calls External Tools

Without tool calling, a language model can only do one thing: produce text from text. It can't check an up-to-date database, send a message, or trigger an action in a third-party piece of software. Tool calling is the bridge connecting a model to an outside system. It's what turns a model that chats into an AI agent capable of acting, the basic building block behind every autonomous agent.

Detailed definition

Tool calling, also called function calling, refers to a language model's ability to respond to a request not just with text, but with a structured request to execute a specific function, with arguments filled in according to a schema defined in advance. Anthropic's documentation describes the principle this way: the model determines whether it needs to call a tool based on the request and the tool's description, then returns a structured call that the application executes (client-side) or that the provider executes itself (server-side, for certain built-in tools). OpenAI's documentation, which popularized the term function calling in 2023, describes an identical mechanism: the model responds with a machine-readable function call rather than free text, leaving it to the application to execute it.

Both reference providers agree on the underlying definition: a function is described by a name, a natural-language description, and a JSON schema listing its expected parameters. The model relies solely on these three elements to decide whether to call the tool and how to fill in its arguments. There's no significant divergence between the two approaches on this basic principle; the differences lie in implementation details (parallel call formats, tools provided natively by the provider, error handling).

Tool calling is what sets a plain chatbot apart from a system able to act on the real world: querying a database, searching the web, writing to a file, sending a message, triggering a payment. It's also the basic building block that makes the MCP protocol possible, designed to standardize how tools are described and exposed to a model.

How it works

A tool call always follows the same multi-step pattern. First, the application defines a list of tools available to the model, each with its name, description, and argument schema. Next, the model receives the user's request along with that list of tools, and decides, based on context, whether to answer directly in text or request that a tool be executed.

If it chooses to call a tool, the model returns a structured response containing the tool's name and its argument values, without executing anything itself. It's the application that receives this request, actually executes the action (calling an API, reading a database, writing a file), then returns the result to the model in a form it can read. The model then continues its response based on that result, and can chain several successive tool calls if the task requires it.

This split matters for security: the model never runs any code itself, it only proposes a call. It's the application that keeps control over what actually gets executed, and that can refuse a call if the conditions aren't met.

A concrete example from Atako

At Atako, tool calling sits at the core of how an agent works. Every connected integration (Slack, Notion, GitHub, HubSpot, and about forty others) exposes a set of specific actions, such as post_message on Slack or create_issue on GitHub, that the agent can call whenever it judges the task requires it.

But at Atako, a tool call never executes directly. It first passes through a permission check: the platform verifies that a "grant" exists for that agent and that specific connection, that the requested action is indeed on that grant's list of authorized actions, and that the granted scope (read-only or read-write) actually covers the action in question. If any of these conditions isn't met, the call is refused and the failure is logged. This decision path, an agent proposing a call and the platform verifying before executing, is exactly the security logic tool calling makes possible: the model proposes, the infrastructure decides.

Common mistakes

A common mistake is believing the model executes the tool itself. That's never the case: the model produces a structured request, and it's always an application or platform that actually executes the action and that can, at any time, refuse it.

Second mistake: thinking that giving a model access to a tool amounts to giving it total, unlimited access to that service. A well-designed tool calling system precisely limits available actions, with per-action and per-scope permissions, rather than a generic all-or-nothing access.

Third mistake: underestimating the importance of a tool's description. The model only has the name, description, and argument schema to decide when and how to call a tool. A vague or ambiguous description produces poorly chosen calls or incorrect arguments, even with a capable model.

Finally, some people confuse tool calling with MCP. Tool calling is the underlying mechanism, present since 2023 across major model providers. MCP is a more recent protocol that standardizes how tools are described and connected to a model, to avoid rebuilding a different integration for every tool and every provider.