Tool calling (also called function calling) is a feature of large language model APIs that lets the model respond with a structured request to run a function, rather than plain text. You describe the available tools; the model picks one and fills in its arguments as JSON; your application runs it and sends the result back so the model can finish the answer. Anthropic's tool use overview puts it this way: "Tool use (also called function calling) lets Claude call functions that you define or that Anthropic provides."
Tool calling is what turns a chatbot into something that can check today's weather, query a database, open a pull request or edit a file. Every coding agent and every MCP integration runs on it.
How does tool calling work, step by step?
The key point is that the model never runs anything. Anthropic's How tool use works page says: "The model never runs anything on its own. It emits a structured request, your code (or Anthropic's servers) runs the operation, and the result flows back into the conversation." Google's Gemini function calling docs say the same: "The model doesn't execute the function itself."
OpenAI's function calling guide lists the flow in five steps:
- "Make a request to the model with tools it could call"
- "Receive a tool call from the model"
- "Execute code on the application side with input from the tool call"
- "Make a second request to the model with the tool output"
- "Receive a final response from the model (or more tool calls)"
Step 5 is where agents come from. If the model asks for another tool, you run it and go round again. Anthropic describes this as a loop: while the response's stop_reason is "tool_use", run the tools and continue the conversation. The loop ends when the model produces a final answer or stops for another reason.
What does a tool definition look like?
A tool is a name, a description and a JSON Schema for its input. Here is the example from Anthropic's Define tools page:
{
"name": "get_weather",
"description": "Get the current weather in a given location",
"input_schema": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "The city and state, e.g. San Francisco, CA"
},
"unit": {
"type": "string",
"enum": ["celsius", "fahrenheit"],
"description": "The unit of temperature, either 'celsius' or 'fahrenheit'"
}
},
"required": ["location"]
}
}
The providers use slightly different field names for the same ideas:
| Anthropic (Claude) | OpenAI (Responses API) | Google (Gemini) | |
|---|---|---|---|
| Schema field | input_schema |
parameters, with type: "function" |
parameters, with type: "function" |
| Model's call | tool_use block with id, name, input |
function_call item with call_id, name, arguments |
function_call step with id, name, arguments |
| Your result | tool_result block with tool_use_id |
function_call_output with call_id |
function_result with call_id |
The ID ties each result to the call that asked for it, which matters when the model asks for several tools at once.
What does a tool call look like in practice?
Suppose a user asks "What's the weather in San Francisco?" with the get_weather tool available. Claude's response contains a block like this one from Anthropic's docs:
{
"type": "tool_use",
"id": "toolu_01A09q90qw90lq917835lq9",
"name": "get_weather",
"input": { "location": "San Francisco, CA" }
}
Your code reads name and input, calls a real weather service, and sends the answer back in the next request:
{
"type": "tool_result",
"tool_use_id": "toolu_01A09q90qw90lq917835lq9",
"content": "15 degrees Celsius, partly cloudy"
}
The model then writes the reply the user sees. In Anthropic's example, that is "The current weather in San Francisco is 15 degrees Celsius with partly cloudy skies."
The model only ever sees the schema and the result. As Anthropic notes, "Claude never receives your implementation."
How does the model decide when to call a tool?
Mostly from the description. Anthropic's guidance calls detailed descriptions "by far the most important factor in tool performance" and asks for at least three to four sentences per tool, covering what it does, when to use it and when not to, what each parameter means, and what it does not return. OpenAI's guide likewise describes the description field as details on when and how to use the function.
With default settings, Anthropic says Claude "calls a tool when the request maps to that tool's described capability and the answer isn't already in context," and answers directly for stable knowledge, creative tasks and conversation. You can push this either way in the system prompt; Anthropic suggests a line such as "Use the tools to investigate before responding." to increase tool use.
One quirk to plan for: when a required argument is missing, a model may guess. Anthropic's docs show Claude filling in "New York, NY" for a weather request that named no city, and note that Claude Opus is "much more likely to recognize that a parameter is missing and ask for it." Validate arguments before acting on them.
How do you control tool use?
Every major API has a tool_choice setting:
| Behavior | Anthropic | OpenAI | Gemini |
|---|---|---|---|
| Model decides (default) | auto |
auto |
auto |
| Must call some tool | any |
required |
any |
| Must call one named tool | tool |
forced function | allowed_tools with mode any and one tool |
| No tool calls | none |
none |
none |
OpenAI also offers allowed tools, which restrict calls "to a subset of the tools available to the model," and Gemini has a validated mode in which the "Model ensures function schema adherence."
Not every model supports forcing. Anthropic's docs note that on some current Claude models, including Claude Opus 5.5 and Claude Sonnet 5.5, any and tool return an error, and recommend auto combined with strict tool use instead.
Strict mode makes the arguments match your schema exactly. Anthropic's docs say adding strict: true ensures "Claude's tool calls always match your schema exactly." OpenAI's say it "will ensure function calls reliably adhere to the function schema, instead of being best effort," with the requirement that objects set additionalProperties to false and list every property as required.
Parallel calls let the model request several independent tools in one turn. OpenAI lets you switch this off with parallel_tool_calls: false; Anthropic uses disable_parallel_tool_use inside tool_choice.
What are client tools and server tools?
Tools differ by where the code runs. In Anthropic's terms, client tools run in your application: tools you define, plus tools with Anthropic-defined schemas such as bash and text_editor. Server tools such as web_search, web_fetch and code_execution run on Anthropic's infrastructure, so "you see the results directly without handling execution."
The trade-off is control versus effort. Client tools can reach your private systems but you write the loop. Server tools need no handler code but can add usage-based charges, such as a fee per web search.
How do tool calling, MCP and agents fit together?
They stack:
- Tool calling is the model-level mechanism: the model asks, your app runs.
- MCP is a standard for where tools come from. The MCP architecture docs explain that an app gathers tools from its connected servers into "a unified tool registry that the language model can access," then routes each tool call to the right server. See what is MCP and how to build an MCP server.
- Agents are tool calling in a loop with a goal. A coding agent like Claude Code or Codex is a model with file, shell and search tools, calling them repeatedly until the task is done. See what is an AI coding agent.
Anthropic's docs offer a handy test for when you need tools at all: "if you're writing a regex to extract a decision from model output, that decision should have been a tool call."
How much does tool calling cost?
Tool definitions are part of the prompt, so you pay for them on every request. Anthropic's overview says the extra tokens come from the tools parameter (names, descriptions and schemas), tool_use blocks and tool_result blocks, plus a tool use system prompt whose size is listed per model. OpenAI's guide says "callable function definitions count against the model's context limit and are billed as input tokens."
Practical effects: dozens of large tool schemas can crowd the context window, and every loop iteration resends the conversation. Keep descriptions precise rather than padded, return only the fields the model needs, and load rarely used tools on demand where your provider supports a tool search feature. Google's Gemini docs suggest you "Keep active set to 10-20 tools maximum." LLM tokens explained covers how context fills up.
What are the risks of tool calling?
Tools let a model act, so mistakes have consequences.
- Wrong or guessed arguments. Validate inputs in your code, and use strict mode where available.
- Consequential actions. Ask a human before tools that send, buy, delete or deploy. OpenAI's MCP docs advise: "Keep approval enabled for tools that can modify data or take other consequential actions."
- Prompt injection. A tool result can carry hostile instructions, such as a web page or issue that tells the model to leak data. Treat tool output as untrusted input. Our guide to prompt injection in coding agents covers defenses.
- Least privilege. Give each tool the narrowest credentials that work, so a misused call cannot do much damage.
Where should you keep tool-using prompts?
The system prompts and instructions that steer tool use, such as "check the order status tool before answering any shipping question," take real tuning. Kipt stores prompts like these as Markdown in a private GitHub repo you own, with {{name:default}} blanks for the parts that change, so the version that works stays easy to find.
What should you read next?
Read what is MCP to see how tools are shared across apps, then how to build an MCP server to expose your own. The system prompt guide covers where tool-use instructions usually go.