Tool use lets Claude ask for an action to be performed, and then use the result in its answer.

Tool use is sometimes called function calling. In simple terms, a tool is a capability that is described to Claude: its name, what it does, and what information it needs. When Claude decides that a tool would help with your request, it produces a structured request to use that tool. The tool runs, and the result is handed back to Claude, which then uses it to write the final reply.

Anthropic’s documentation explains that Claude decides when to call a tool based on the user’s request and the tool’s description. The important idea is that Claude requests the action, and something else carries it out. Claude does not directly reach out and touch your database or your calendar. It asks, and a controlled mechanism does the work.

A language model alone has real limits, and tools fill the gaps.

Without tools, Claude works only from what it learned in training and what is in the conversation. That means it does not know what happened after its training cutoff, cannot see your private files, cannot reliably do heavy arithmetic, and cannot do anything in the world. Tools address each limit.

You may meet tool use as a user, or as a developer building something.

In the Claude apps, tools appear as features you can switch on or that Claude uses when appropriate. Examples include web search, creating and analyzing files, connectors to services such as email or documents, and tools for working with a computer in some products. You see Claude using them, often as a visible step in the conversation, and you usually control which are enabled.

In the Claude API, developers define tools themselves, or use tools that Anthropic provides, and write the code that handles the loop. This is where most of the technical vocabulary comes from. This guide uses plain words for both settings, because the ideas are the same: describe the tool, let Claude decide, run it, and return the result.

Almost every use of tools follows the same simple round trip.

Anthropic’s documentation describes the pattern in a few steps. First, the tools are provided along with the user’s question. Second, Claude decides whether a tool is needed and, if so, returns a request naming the tool and the information to give it. Third, the tool is executed. Fourth, the result is sent back to Claude. Fifth, Claude uses the result to write its final answer. If the job needs more than one lookup, the cycle can repeat several times.

flowchart TD
    A["You ask a question"] --> B["Claude sees the question
and the list of tools"]
    B --> C{"Does Claude need a tool?"}
    C -- "No" --> F["Claude answers directly"]
    C -- "Yes" --> D["Claude requests a tool
with the needed details"]
    D --> E["The tool runs
and returns a result"]
    E --> B2["Claude reads the result"]
    B2 --> C
    B2 --> F2["Claude writes the final answer"]
        

Tools differ mainly by where the work happens.

Anthropic’s documentation divides tools into two broad groups. Client tools run in the developer’s own application. Claude asks for the action, the application performs it, and the application returns the result. This is the type used for your own databases, your own systems, and anything private. Server tools run on Anthropic’s infrastructure. Web search, web fetching, and code execution are examples. For these, the developer enables the tool and Anthropic handles the running, so there is no extra code to write for the execution.

A handful of tool types cover most everyday needs.

Every tool is described to Claude in three parts.

When a developer defines a tool, they describe it to Claude with a name, a description, and a list of the inputs it needs. The description is written in plain language, and it is how Claude decides whether the tool fits a request. The inputs are described along with their types, such as a piece of text or a number, and which ones are required.

Anthropic’s guidance treats the description as the most important factor in how well a tool works.

Because Claude decides which tool to use largely by reading the description, vague descriptions lead to wrong or missed calls. Anthropic’s documentation recommends detailed descriptions that explain what the tool does, when it should and should not be used, what each input means, and what the tool returns. Third-party guides summarize this as writing the description the way you would explain a new tool to a new teammate.

Claude judges from the request and the descriptions, and you can nudge it.

By default, Claude decides for itself whether a tool is needed. If your question can be answered directly, it may simply answer. If it needs fresh information or a calculation, it is more likely to call a tool. Anthropic’s documentation notes that if Claude is not calling tools when you expect, a light instruction such as asking it to use the tools to investigate before responding increases tool use, and a stronger instruction pushes further.

You can also steer in the other direction. If you do not want a tool used, say so, or leave it switched off. Clear requests help too. Saying “look this up online and cite your sources” gives a stronger signal than a vague question.

Developers can control how freely Claude may use tools.

Anthropic’s documentation describes a setting that governs tool choice. In the default mode, Claude decides on its own. In another mode, Claude must use at least one tool. In another, it must use a particular named tool. And in the last, it must not use tools at all. Forcing a choice is useful when you need a structured result every time, and the automatic mode is the best fit when you want Claude to use judgment.

Independent lookups can happen together, and dependent ones must wait.

Anthropic’s documentation notes that Claude may request several tools in one go when the jobs do not depend on each other. For example, it might look up a customer’s profile, their recent orders, and a stock level at the same time. This saves time because the lookups run in parallel. Some jobs must happen in sequence, because the second needs the answer of the first. Developers can also switch off parallel calls when they want exactly one at a time.

flowchart LR
    Q["A question needing three facts"] --> P1["Look up profile"]
    Q --> P2["Look up recent orders"]
    Q --> P3["Check stock level"]
    P1 --> R["Combine the results"]
    P2 --> R
    P3 --> R
    R --> A["Final answer"]
        

Repeating the loop lets Claude work through a larger task.

When the basic loop repeats, with Claude using a tool, reading the result, deciding what to do next, and using another tool, it is often called an agentic loop. This is how Claude can research a topic across many searches, analyze a data file step by step, or complete a multi-part task. Each step is informed by the results of the previous one.

Because loops can run for many steps, they need limits and supervision. Anthropic’s documentation notes, for example, that server tools have a default cap on how many iterations they run within one request, after which the response signals a pause so the work can be continued. Developers should also set their own limits, and for important work, a person should be able to review progress and stop the process.

Tools need exact inputs, and missing ones cause trouble.

Suppose a weather tool needs a location, and the user only says “What’s the weather?” Claude has two choices: ask for the location, or guess. Anthropic’s documentation notes that some models may ask, while others may infer a reasonable value, and that guessing can lead to wrong results. For tools that matter, such as booking, sending, or deleting, guessing is risky.

You can reduce the risk by telling Claude to ask when a required detail is missing, by making required inputs clear in the tool description, and by giving the details in your request. For actions with real consequences, require a confirmation step before the tool runs.

Failures are normal, so they should be visible and handled.

Tools can fail for many reasons: a service is down, a request is invalid, a permission is missing, or the input was wrong. The recommended approach in Anthropic’s and others’ guidance is to send the error back to Claude as a result, marked as an error, instead of hiding it or crashing. Claude can then adapt: try again with different inputs, use another tool, or explain the problem to the user.

A common mistake is silent failure, where a tool breaks but the process carries on as if nothing happened. This is dangerous, because Claude may then produce a confident answer built on missing information. Errors should always be reported back, and certain errors, such as permission problems, should be escalated to a person instead of retried.

Whatever comes back from a tool should be treated as information to examine.

Tool results can contain errors, out-of-date facts, or even text that tries to give instructions. A web page might include a hidden line that says, “Ignore your previous instructions and do something else.” This kind of attack is called prompt injection. The safe rule is that the content of tool results, such as web pages, documents, and emails, is data for Claude to read, not a command to obey. Instructions come from the actual user and the application’s own rules.

Anthropic’s guidance and other practitioner guides note that Claude may flag suspicious content in tool results. Developers should design systems so that untrusted content cannot trigger sensitive actions without a person’s approval. Users should be cautious when a tool result suddenly asks for an unusual action.

The right level of approval depends on what the tool can do.

Not all tools carry the same risk. A tool that reads public information is low risk. A tool that reads your private data needs more care. A tool that sends, changes, spends, or deletes needs the most. A good design uses the least access that gets the job done and adds approval steps for actions that cannot be undone. In the Claude apps, you see this as permission prompts and drafts that wait for you. For developers, it means building confirmation steps into the loop.

Tools add effort, and effort has a price.

Anthropic’s documentation explains that tool use adds to the number of tokens in a request: the tool definitions, the tool requests, and the tool results all count as part of the input and output. Server tools can also have their own usage-based charges, for example a charge per search. Each extra round trip adds time too. This is why concise tool descriptions, short results, and sensible limits on loops matter in real products.

A common standard makes it easier to connect many tools.

Anthropic’s documentation refers to the Model Context Protocol, often shortened to MCP, as a standard way for tools and data sources to be offered to AI systems. Instead of each tool needing a custom connection, a service can expose its capabilities in a common form, and any compatible application can use them. In the Claude apps, many connectors follow this idea. For developers, the documentation describes ways to use MCP servers with Claude.

The benefit is variety and reuse. The risk is the same as with any tool: a connector can reach real data and actions, so it should come from a source you trust and be given only the access it needs.

Familiar jobs show how the ideas fit together.

Tools make Claude far more capable, and they add responsibilities.

These habits cause most problems with tools.

Follow these steps for almost any tool-based task.

A few popular beliefs about tool use are only partly true.

Quick answers to the questions beginners ask most.

It is the ability for Claude to request actions, such as searches or lookups, that are carried out by tools, and then to use the results in its answer. It is also called function calling.

Claude asks for the tool to be used. For client tools, the developer’s application runs it, and for server tools such as web search, Anthropic’s infrastructure runs it.

It reads your request and the tool descriptions, and judges which tool fits. Clear descriptions and clear requests make better choices.

Developers can set tool choice so that Claude decides automatically, must use some tool, must use a named tool, or must use none.

Yes, for independent jobs it may request several together. Developers can switch this off when they want one call at a time.

The error should be returned to Claude, which can retry with different inputs, use another tool, or explain the problem. Permission errors should be escalated to a person.

It is an attempt to hide instructions inside content, such as a web page or document, so that an AI follows them. Treat tool results as data, and require approval for sensitive actions.

Tool definitions, requests, and results add tokens, and some server tools have usage-based charges. Check Anthropic’s current pricing documentation.

The Model Context Protocol is a standard way for tools and data sources to be offered to AI systems, so one connection can work across many compatible applications.

Use the least access, require approval for sending, spending, and deleting, treat results as data, set limits on loops, and verify important outputs.

In Anthropic’s official documentation on tool use, which lists the available tools, options, and pricing and is updated as features change.

Tool use connects Claude to the outside world. Claude reads your request and the tool descriptions, asks for a tool to be used, receives the result, and writes a better answer, repeating the loop when more steps are needed. Client tools run in the developer’s own application, and server tools such as web search and code execution run on Anthropic’s infrastructure. Clear descriptions, focused tools, and the right tool choice setting improve results. Missing details should be asked for, errors should be reported back, and results should be treated as data, not orders, to resist prompt injection. Apply least access, approvals for risky actions, limits on loops, and verification of outputs, and recheck Anthropic’s documentation for current options and pricing.