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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
These two terms are closely related and often used interchangeably, but there is a meaningful distinction worth understanding.
| Tool calling | Function calling | |
|---|---|---|
| Scope | Broad capability that includes APIs, databases, code execution, external services, and any callable resource | Specific mechanism where the model generates arguments for a predefined function |
| Context | Used in agentic AI frameworks where models orchestrate multi-step workflows across multiple tools | Originally introduced by OpenAI in 2023 to describe structured output generation for function invocation |
| Relationship | The umbrella concept | A subset of tool calling |
| Industry usage | The term the industry has converged on as AI agents have become more capable | Still 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.
Tool calling is already operating in production across industries. Here are concrete examples of how organizations use it.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.