Skip to main content

What is Tool Calling?

Tool calling is the process of invoking an external tool to complete a task. Explore each step, from selecting a tool to processing its response.

by Databricks Staff

  • Tool calling is the mechanism that allows AI models to interact with external tools, APIs, and systems, transforming basic chatbots into capable AI agents that can take real-world action.
  • The process follows a structured loop: the model recognizes when a tool is needed, selects the right one, builds a request, processes the response, and delivers a result to the user.
  • Databricks Agent Bricks provides a governed platform for building tool-calling agents grounded in enterprise data, with native support for the Model Context Protocol (MCP) and Unity Catalog governance.

Tool calling is the ability of an AI model to interact with external tools, APIs, or systems to perform actions and retrieve information beyond what the model can do on its own. Rather than relying solely on the knowledge baked into its training data, a model with tool-calling capabilities can recognize when a user's request requires outside help, select the appropriate tool, and structure a request to get the job done.

This is the capability that separates a static chatbot from a functional AI agent. Without tool calling, a large language model can only generate text based on patterns it learned during training. With it, the same model can check live inventory, query a database, send an email, execute code, or call a third-party API. Tool calling gives AI models hands.

Why tool calling matters for AI agents

AI agents are systems that can perceive their environment, make decisions, and take action to accomplish goals. Tool calling is what makes the "take action" part possible. An agent that cannot call tools is limited to conversation. An agent that can call tools becomes a worker.

The shift from generative to agentic AI

Generative AI produces text, images, and code. Agentic AI goes further by planning multi-step workflows, using tools to execute each step, and adapting based on results. Tool calling is the bridge between these two paradigms. It is the mechanism through which an AI model stops describing what could be done and starts doing it.

Why enterprises are paying attention

The business case is straightforward. According to Gartner, 40% of enterprise applications will embed task-specific AI agents by the end of 2026, up from less than 5% in 2025. That growth depends on reliable tool calling. If an agent cannot dependably query a CRM, update a record, or trigger a downstream workflow, it cannot deliver production-grade value.

Tool calling also changes how teams think about automation. Instead of building rigid, rule-based integrations for every possible workflow, organizations can deploy AI agents that dynamically select and invoke the right tools based on context. This makes systems more flexible and reduces the engineering overhead of maintaining brittle point-to-point connections.

How does AI tool calling work?

Tool calling follows a structured loop. The model does not execute tools directly. Instead, it generates structured requests that an application layer fulfills, then incorporates the results into its response. Here is how the process works step by step.

Step 1. Recognizing when a tool is needed

The process begins when a user sends a request that the model cannot answer from its training data alone. If a user asks "What is the capital of France?" the model answers directly. If a user asks "What were our Q2 sales numbers?" the model recognizes it needs to query an external data source.

This recognition depends on the model's training. Models that support tool calling have been fine-tuned to identify when a query falls outside their knowledge boundary and when an available tool could help. The model evaluates the user's intent against the list of tools it has been given access to.

Step 2. Choosing the right tool

Once the model determines that a tool is needed, it selects the most appropriate one from its available set. Each tool is described to the model using a schema that includes the tool's name, what it does, and what parameters it accepts. The model matches the user's request against these descriptions to pick the right tool.

For example, if an agent has access to both a weather API and a database query tool, and the user asks about tomorrow's forecast, the model selects the weather API. If the user asks about last month's revenue, it selects the database query tool.

Step 3. Building and sending the request

After selecting a tool, the model generates a structured output, typically in JSON, that specifies which tool to call and what arguments to pass. The model does not execute this call itself. It produces the request, and the application layer handles execution.

Step 4. Receiving and processing the response

The external tool executes the request and returns a result. This could be a data payload from a database, a confirmation that an action was completed, an error message, or any other structured response. The application layer passes this result back to the model as context for generating its final answer.

Step 5. Delivering the answer or executing an action

With the tool's response in hand, the model synthesizes a natural-language answer for the user. If the user asked for Q2 sales numbers, the model might respond: "North American Q2 2026 sales totaled $14.3 million, up 12% from Q1." The model combines the raw data from the tool with its language capabilities to produce a clear, contextual response.

In some cases, the result is not a conversational answer but an executed action, such as a sent email, an updated database record, or a triggered workflow. The model confirms the action to the user.

Step 6. Iterating and refining the result

Tool calling is not always a single pass. Complex requests may require multiple tool calls in sequence. An agent asked to "prepare a summary of last quarter's performance and email it to the leadership team" might first query a database for performance metrics, then call a code execution tool to generate a chart, then invoke an email API to send the summary.

At each step, the model evaluates whether it has enough information to proceed or whether additional tool calls are needed. This iterative loop is what makes agentic AI systems capable of handling multi-step workflows.

Common types of tool calling

Tool calling is not a single pattern. Different use cases require different types of tools, each serving a distinct purpose in an agent's workflow.

Information retrieval and search

The most common type of tool calling involves fetching data the model does not have. This includes querying databases, searching document repositories, calling search APIs, or retrieving real-time information like stock prices, weather data, or news. Retrieval-augmented generation (RAG) is a specific form of this pattern where the model queries a knowledge base to ground its responses in verified data.

Code execution

Some tasks require the model to write and run code rather than simply generate text. Code execution tools allow agents to perform calculations, transform data, generate visualizations, or run analytical scripts. An AI coding agent might write a Python function, execute it in a sandboxed environment, and return the output to the user.

Process automation

Tool calling enables agents to trigger actions in external systems. This includes sending emails, creating tickets in project management tools, updating CRM records, initiating approval workflows, or posting messages to communication platforms. These tools turn agents into participants in business processes rather than passive observers.

Smart devices and IoT monitoring

In industrial and operational contexts, tool calling connects AI agents to physical systems. An agent might query sensor data from manufacturing equipment, adjust thermostat settings in a smart building, or monitor fleet vehicle telemetry. These integrations extend AI capabilities from the digital world into the physical one.

REPORT

The agentic AI playbook for the enterprise

Tool calling vs. function calling

These two terms are closely related and often used interchangeably, but there is a meaningful distinction worth understanding.

Tool callingFunction calling
ScopeBroad capability that includes APIs, databases, code execution, external services, and any callable resourceSpecific mechanism where the model generates arguments for a predefined function
ContextUsed in agentic AI frameworks where models orchestrate multi-step workflows across multiple toolsOriginally introduced by OpenAI in 2023 to describe structured output generation for function invocation
RelationshipThe umbrella conceptA subset of tool calling
Industry usageThe term the industry has converged on as AI agents have become more capableStill used in some API documentation and legacy contexts

Function calling is how tool calling started. When OpenAI first introduced the capability, it was framed as a way for models to generate structured arguments for developer-defined functions. As the ecosystem matured and agents began orchestrating more complex workflows involving multiple external systems, the broader term "tool calling" became standard.

In practice, if you are reading documentation that says "function calling," it is describing the same underlying mechanism. Databricks supports both terms in its documentation and platform capabilities. For a deeper look at how function calling is evaluated in practice, see the Databricks function calling benchmarks.

Real-world examples of AI tool calling in action

Tool calling is already operating in production across industries. Here are concrete examples of how organizations use it.

Customer support agents

A support agent receives a customer message asking about the status of an order. The agent calls a tool to query the order management system, retrieves the tracking information, and responds with a delivery estimate. If the customer wants to change the shipping address, the agent calls an update tool to modify the record. Every tool interaction is governed and auditable through platforms like Unity Catalog, which enforces access controls and maintains lineage from agent actions to source data.

Data analysis workflows

An analyst asks an AI agent to compare this quarter's revenue across regions. The agent calls a SQL query tool to pull data from the lakehouse, calls a code execution tool to calculate growth rates and generate a chart, and returns a formatted summary. What would have taken an analyst 30 minutes of manual querying and spreadsheet work happens in a single conversational exchange.

IT operations and monitoring

An operations team deploys an agent that monitors infrastructure health. When a server's CPU usage exceeds a threshold, the agent calls a diagnostics tool to gather system logs, calls an alerting tool to notify the on-call engineer, and calls a remediation tool to scale up resources automatically. The agent handles the first-response workflow without human intervention.

Enterprise search and knowledge management

An employee asks an internal AI assistant about the company's parental leave policy. The agent calls a retrieval tool to search the HR knowledge base, finds the relevant policy document, and returns a concise answer with a link to the full document. This pattern replaces the common experience of searching through an intranet and reading through multiple pages to find a specific answer.

Start building AI agents with tool calling on Databricks

Databricks provides a complete platform for building, deploying, and governing tool-calling agents through Agent Bricks. According to Databricks, organizations have already built over 100,000 agents on the platform, processing more than one quadrillion tokens per year.

How Databricks supports tool calling

Agent Bricks natively supports the Model Context Protocol (MCP), the emerging open standard for tool integration. This gives agents secure access to APIs, databases, and SaaS applications through a standardized interface. MCP tools can be discovered and shared across an organization through a built-in catalog, with every integration visible, permissioned, and auditable through Unity Catalog.

Developers can connect agents to tools in several ways:

  • Managed MCP servers for Databricks data sources
  • External MCP servers registered as governed MCP Services
  • Unity Catalog functions for custom logic and task-specific tools
  • Custom tools built with the Python-based Agent SDK

The Agent SDK handles tool execution, function calling, multi-step workflows, and conversation state management. Developers define what tools the agent can use and how it should behave across multi-turn conversations.

Getting started

For teams exploring tool calling for the first time, the AI Playground provides a no-code sandbox where you can select an LLM, add tools, and test agent behavior before exporting to code. Agent Bricks supports popular agent harnesses including LangGraph, CrewAI, Agno, the Claude Code SDK, and OpenAI Agent SDKs, so teams can build with the frameworks they already know.

Governance is built in from the start. Agent governance and data governance are managed directly in Unity Catalog, with role-based access controls applied to models, tools, and connections. Organization-wide policies for prompt injection prevention, sensitive data detection, and content filtering are configured within a single control plane.

To start building and testing tool-calling agents on your own data, explore Agent Bricks and the Databricks agent tool framework.

Frequently asked questions

What does tool calling mean in AI?

Tool calling is the ability of an AI model to invoke external tools, APIs, or systems to perform tasks beyond text generation. It allows models to retrieve live data, execute code, and trigger actions in external applications.

What is the difference between tool calling and function calling?

Function calling is a subset of tool calling. Function calling refers specifically to a model generating structured arguments for a predefined function. Tool calling is the broader concept that encompasses function calling along with API integrations, database queries, code execution, and other external interactions.

How does tool calling work in LLMs?

An LLM with tool-calling support follows a loop: it recognizes when a user's request requires an external tool, selects the appropriate tool from its available set, generates a structured request with the correct parameters, and then incorporates the tool's response into its final answer. The model does not execute tools directly. It produces structured output that an application layer fulfills.

Which LLM is best for tool calling?

Tool-calling performance varies by model and use case. The Berkeley Function Calling Leaderboard (BFCL) is the most widely referenced benchmark for evaluating tool-calling reliability across models. Databricks supports multiple LLM providers, including models from OpenAI, Anthropic, Google, and Meta, so teams can select and compare models based on their specific requirements.

What is the difference between AI tool calling and MCP?

Tool calling is the capability. MCP (Model Context Protocol) is a standardization layer for how tools are described, discovered, and invoked. MCP provides a consistent interface so that agents can connect to any MCP-compatible tool without custom integration code. Databricks Agent Bricks natively supports MCP for governed tool access.

Why is tool calling important for AI agents?

Without tool calling, AI agents are limited to generating text based on their training data. Tool calling gives agents the ability to act: querying databases, calling APIs, sending messages, executing code, and triggering workflows. It is the core mechanism that transforms a language model into an autonomous AI agent capable of completing real-world tasks.

Get the latest posts in your inbox

Subscribe to our blog and get the latest posts delivered to your inbox.