Tool Use (Function Calling) is a capability that lets AI models invoke external functions or APIs during a conversation to fetch data, take actions, or interact with systems beyond their training data.
What tool use is
Tool use, also called function calling, is the capability that lets an AI model interrupt its own text generation to call an external function. The model outputs a structured request: “I want to call this tool with these arguments.” The host application runs the tool, gets a result, and feeds the result back as new context. The model continues from there.
Without tool use, a language model can only answer from its training data. With tool use, it can fetch live information, query databases, search the web, send emails, or do anything else the host exposes.
This is the capability that turns a chatbot into something that can actually act on the world.
How a tool call actually works
A typical tool-use exchange looks like this.
The host sends the model a list of available tools, each with a name, description, and JSON schema for its arguments. The user sends a message. The model decides whether the message can be answered directly or whether it needs a tool. If a tool is needed, the model returns a structured response specifying tool name and arguments instead of normal text.
The host parses that response, runs the tool, and sends the result back as a new message in the conversation. The model continues, either with another tool call or with a final answer to the user. The whole exchange is a loop.
The user often never sees the tool calls happening. They just see “I asked Claude about my bookmarks and it answered.” Behind the scenes, Claude called a search_bookmarks tool, got back a list of saves, and synthesised the answer.
Why this matters
Three things tool use unlocks.
Live data. Models have a knowledge cutoff. Tool use lets them fetch current data from APIs, databases, or the web at query time.
Private data. Models don’t know your data. Tool use lets them query your systems (your bookmarks, your calendar, your codebase) without that data being in the training set.
Actions. Beyond reading, tools can write. Send an email, schedule a meeting, file a ticket, deploy a build. Tool use is what makes AI agents possible.
The relationship to MCP
Model Context Protocol is the standard for how tools are described and exposed. Tool use is the model’s ability to call them.
Before MCP, every AI host had its own way of registering tools. Claude Desktop had one format. Cursor had another. Each integration was custom. MCP standardizes the supply side: any MCP server can be plugged into any MCP-aware host without rewriting the integration. Tool use, on the model side, was already standardized by each frontier provider.
The combination is powerful. Build one MCP server, expose it to any AI client. The model already knows how to call tools. The host already knows how to discover them.
Common patterns
Three patterns dominate tool use today.
Retrieval tools. The model asks “I need information about X.” A tool fetches it. This is how RAG is implemented in agentic systems: rather than embedding retrieval into the prompt, retrieval becomes a tool the model decides when to call.
Action tools. The model says “I want to do X.” A tool does it. Send messages, run code, modify files, hit a webhook. Action tools require careful design around confirmation and permission.
Computational tools. The model says “I need to compute X.” A tool does the math. Useful because language models are bad at arithmetic and good at deciding when to delegate it.
Limitations to know about
Tool use isn’t free. Each tool call adds latency: the round-trip to the tool, plus the model parsing the result. Long agent loops with many tool calls can be slow and expensive.
Models also make tool-call mistakes. Wrong arguments. Tools called when they shouldn’t be. Tools not called when they should. The error rate goes down with model quality but doesn’t reach zero. Production systems need retry logic, validation, and fallbacks.
The other quiet limitation: tools must be described well. A poorly named tool with vague descriptions gets misused. Most engineering effort in tool-using systems goes into clear tool descriptions and good schema design, not into the model itself.