smart_toy Artificial Intelligence › Article

Tool Use (Function Calling): How a Model Requests Actions

Tool use, or function calling, is how a model requests a function in your application. The model decides when; your code runs it and returns the result.

info Quick Definition

Tool use, also called function calling, is the mechanism through which an AI model requests the execution of an external function. The model decides when the tool is needed and returns the name and arguments; the application runs the action and sends the result back to the model.

What does the model actually do?

A language model only produces text. It cannot open a file or query a database. What it does with tool use is produce a structured request: “I want to call the tool lookup_order with this number.” That request does nothing until your code receives it and runs it.

According to the Claude documentation, the model “determines when to call a tool based on the user’s request and the tool’s description”. It then returns the call, your application executes it, and the result goes back to the model in a separate message. With that result, the model answers.

There are two kinds of tools, depending on where the code runs:

Type	Who runs it	Examples in the Claude API
Client tools	Your application	The ones you define, `bash`, `text_editor`
Server tools	The provider	`web_search`, `web_fetch`, `code_execution`

Tool use is the foundation of AI agents: without tools, the model only talks; with them, it can act in a loop. When the tools come from an external server instead of your own code, the open protocol for connecting them is MCP.

How is a tool defined?

A tool you define has three required parts:

Name (name). Short, with a verb and no ambiguity: lookup_order, not process. In the Claude API it only accepts letters, numbers, hyphens and underscores, up to 128 characters.
Description (description). What it does, when to use it and when not to, what each parameter means and what it does not return. Anthropic calls it “by far the most important factor in tool performance” and recommends at least 3 to 4 sentences.
Input schema (input_schema). A JSON Schema that says which parameters exist, their type and which are required.

A fourth part is optional: input_examples, a list of sample inputs that must match the schema. It helps with tools that have complex or format-sensitive parameters.

Compare two descriptions for the same tool. Weak: “Looks up an order.” Useful: “Looks up an order by its number and returns status, shipping date and amount. Use it when the customer asks about a specific order. It cannot search by customer name. The number has the format ORD-000000.” The second one tells the model when it applies, when it does not and what to expect.

Anthropic also recommends grouping similar operations into a single tool with an action parameter, instead of three near-identical ones.

What cycle does a call follow?

Your application sends the conversation and the list of tools.
The model replies with a tool_use block that carries an id, the tool name and its arguments.
Your code validates and runs the function.
You send the result back in a tool_result block with the same identifier (tool_use_id). If something failed, you mark it with is_error: true.
The model answers the user with that result, or requests another tool.

That cycle repeats. Each pass is a turn of the agent loop.

You also control how much freedom the model has through the tool_choice parameter: auto (the model decides; this is the default), any (it must use one), tool (it must use a specific one) and none (it cannot use any). Not every model supports forcing a tool: check the documentation for the model you use.

Why does it matter to a designer?

Because the tools define what the AI can do inside the product, and that is an interaction design decision. A few questions worth asking before you build:

Which actions can the AI trigger without the user seeing them?
What happens when the tool fails? The error message is also UX.
What name and description does the person understand when they see the action on screen?
Which actions need approval before they run?
Which tool should not exist, even though it is technically possible?

A badly described tool produces calls at the wrong moment. A tool with too many permissions produces damage that is hard to undo. And the text a tool returns is content too: if it comes from a web page, an email or a third-party API, Anthropic warns that it may carry hidden instructions that try to redirect the model (indirect prompt injection).

Quick test: open a tool your product or team uses and read its name and description as if you were the model. Would you know when to use it? Would you know which parameter is missing if the call is incomplete? If not, rewrite the description. Then test it with a request that should not trigger it and check that it does not.

When is a tool NOT the right choice?

When the answer comes from general knowledge and does not need current or system data.
When the action is critical and there is no approval step. A person should confirm before it runs.
When a deterministic function (a fixed SQL query, a calculation) solves the case without going through the model.
When you only need a response with a fixed shape and not an action: that is what structured outputs are for.

Anthropic explains that, with tool_choice set to auto, the model decides on each turn whether to call a tool or answer directly, and that this boundary can be steered through the system prompt. Steering is not blocking: to prevent something every time, use a technical control, such as permissions or a hook. In Claude Code, for example, a PreToolUse hook can block a call before it runs.

Example

Illustrative example: a support tool exposes a refund_order function with order_id and amount parameters. The model calls it when the customer asks. A careful design does not let it run directly: the application shows the human agent the order and amount, and runs the call only after confirmation. If the amount exceeds a limit, the tool returns a tool_result with is_error: true and a clear message: “The amount exceeds the automatic refund limit. The case must go to a person.” The model uses that text to tell the customer what happens next.

How do you validate what the model requests?

The model can request a tool with malformed arguments, out-of-range values or values that do not exist. Your code must validate before it runs: types, ranges, real identifiers and the permissions of the person behind the session.

The Claude API has a strict mode: with strict: true in the definition, tool inputs always match the exact schema. That does not replace business validation. The schema can say that amount is a number; only your code knows whether that order exists and whether that amount is reasonable.

If validation fails, return the error as the result. Anthropic’s documentation recommends instructive messages instead of a generic “failed”: what went wrong and what to try next, for example “Rate limit exceeded. Retry after 60 seconds.” According to the same documentation, when a parameter is missing and you say so in the error, Claude usually retries 2 to 3 times with corrections before apologizing to the user.

Common mistakes

Vague descriptions such as “useful for order things.” The model does not know when to use it.
Tools with a single free-text parameter and no types or constraints.
Many near-identical tools competing for the same request.
Relying on the description or the system prompt as the only defense against dangerous actions.
Returning generic errors. The model does not know whether to retry, fix the call or tell the user.
Treating a tool result as trusted text when it comes from external sources.
Giving a tool more permissions than the task needs (see sandboxing and permissions).

Sources

Frequently asked questions

What is tool use or function calling?

It is a mechanism in which the AI model decides to call a function you define, such as looking up an order or reading a file. It returns the function name and its arguments, and your application runs it.

Does the model run the tool by itself?

Not for tools you define. The model only requests the call with a structured block; your application runs the action and returns the result. Some provider tools, such as Anthropic’s web search, do run on the provider’s infrastructure.

What does the model need to use a tool?

A name, a clear description of what it does and when to use it, and a JSON schema with the parameters. Anthropic says the description is the most important factor in how well a tool is used and recommends at least 3 to 4 sentences.

How do you keep a tool from doing something dangerous?

With minimal permissions, parameter validation in your code, human confirmation for critical actions and, when needed, a technical control such as a hook that blocks the call before it runs. The tool description is not a security control.