What Is Tool Use (Function Calling)?

How it works

Tool use follows a simple loop between the language model and the application around it:

1. Define the tools. Developers describe each tool with a name, a plain-language description of what it does, and the inputs it accepts, often written as a schema (a structured template listing each input and its format).
2. The model decides. When a request comes in, the model usually judges whether a tool would help and which one, though developers can also require or block tool use.
3. The model requests a call. Instead of, or alongside, a normal reply, it returns structured output, such as lookup_order with an order number as the input. It can sometimes request several calls at once.
4. The application runs it. Your code checks the request, confirms the user is allowed to do this, runs the function (often by calling another system’s API), and sends back the result.
5. The model responds. It uses the result to answer, or requests another tool if the task needs more steps.

The key point: the model only proposes. The software around the model (your application, the AI platform, or a connected tool server) holds the credentials, enforces permissions, and decides what actually happens.

Why it matters and how tools get connected

On its own, a language model can only work with what it learned in training and what you put in the conversation. It cannot see today’s inventory, your calendar, or a customer’s account. Tool use is one of the main ways an assistant can read live information and take actions inside the systems you already use, within whatever limits you build into each tool.

Common uses include:

• Looking up order status, account details, or availability
• Booking, rescheduling, or canceling appointments
• Creating or updating records in a CRM (customer relationship management system) or help desk
• Pulling figures from a database or spreadsheet
• Saving a draft email or ticket in your email or help desk system for a person to review

You will also hear about the Model Context Protocol (MCP), an open standard that lets a tool be connected once and then used by many AI apps that support it. A connected tool can read or change whatever its credentials allow, so connect only tools you trust and give each the narrowest access that works.

Tool use vs. APIs and AI agents

These three terms often appear together, but they sit at different levels.

An API is the interface a software system offers so other software can use it. APIs long predate today’s AI assistants. A tool you give a model is often a thin wrapper around an API call: the model picks the tool, and the tool calls the API.

Tool use is the model’s part: choosing a tool and filling in its inputs in a format the application can check and run.

An AI agent is the larger system. It combines a model, a set of tools, instructions, and often memory, then repeats the request, run, and review loop until the task is done, it reaches a set limit, or it hands back to a person. Tool use is one capability inside an agent, not the agent itself. A simple assistant can use a tool for a single lookup without being an agent at all.

Limitations and safety

Tool use connects a model to real systems, so mistakes have real effects. Models can pick the wrong tool, send inputs that don’t fit the expected format, or fill in a value they guessed, such as an order number that was never mentioned. Some platforms can enforce the format, but none can guarantee the values are correct. Content the model reads, like an email, a web page, a tool result, or a third-party tool’s description, can also contain instructions meant to steer it into misusing a tool. This is known as prompt injection (more precisely, indirect prompt injection).

Practical safeguards:

• Least privilege. Offer only the tools a task needs, scope them to the current user, and prefer read-only access where possible.
• Confirmation for consequential actions. Require a person to approve payments, refunds, deletions, and messages sent outside the company. This is a common human-in-the-loop pattern.
• Validate in code. Check every requested call against your business rules before running it. Do not rely on the model to enforce them.
• Log every call. Keep a record of what was requested, what ran, and what came back.
• Write clear tool descriptions. Vague names and descriptions can lead to wrong tool choices.

Further reading

• AI ImplementationRelevant if you want to connect AI to your existing systems as part of redesigning and automating a process.
• Claude 201 WorkshopUseful if you want hands-on practice with Claude connectors, which link Claude to other apps, in a 90-minute workshop.