Anthropic — Tool Use (Function Calling) Overview

Type: official-doc Tier: 1 (Official Doc) Author(s): Anthropic Date: Accessed 2026-06-01 URL: https://platform.claude.com/docs/en/docs/build-with-claude/tool-use/overview Accessed: 2026-06-01

Why This Source Matters

This is the primary source for tool use — the central learning target of Project 06. Tool use is how an LLM stops being a text-in/text-out function and starts acting: reading a file, searching a codebase, calling an API. The mechanism is a structured request/response protocol — the model emits a structured call, your code executes it, you feed the result back, and the model continues. That request→execute→feed-back cycle, run in a loop, is the spine of every coding copilot and every agent (Project 08). The lab calls tools through LiteLLM's OpenAI-style interface (tools / tool_calls), but the conceptual flow below — defined by Anthropic's native API — is identical across providers.

Key Claims

Tools are defined by name, description, and an input schema

• A tool definition has a name, a description, and an input_schema (a JSON Schema describing the parameters). "Claude decides when to call a tool based on the user's request and the tool's description."
• The description is load-bearing: the model chooses tools from the description alone. Good definitions include "example usage, edge cases, input format requirements, and clear boundaries."

The request/response flow (client tools)

• Client tools "run in your application." The cycle:

1. You send messages plus a tools list to the model.
2. If the model decides to use a tool, it responds with stop_reason: "tool_use" and one or more tool_use content blocks. Each tool_use block has an id, a name, and an input object (the arguments, matching your schema). Example:

``json { "type": "tool_use", "id": "toolu_01A09q...", "name": "get_weather", "input": { "location": "New York, NY", "unit": "fahrenheit" } } ``

1. Your code executes the operation and sends the outcome back as a tool_result content block (a user-role message) carrying the matching tool_use_id and the result content.
2. The model reads the result and either calls another tool or returns a final answer with stop_reason: "end_turn".

The agentic loop

• The model may call tools multiple times before producing a final answer: read a file → decide it needs another → search → then answer. The application loops "send → if tool_use, execute + return tool_result → repeat" until the model stops requesting tools (stop_reason is no longer "tool_use"). The loop is the program; the model drives it.
• "Tool access is one of the highest-leverage primitives you can give an agent." On benchmarks like SWE-bench, "adding even basic tools produces outsized capability gains."

Controlling whether the model calls a tool — tool_choice

• Default is tool_choice: {"type": "auto"}: "Claude decides on each turn whether to call a tool or respond directly." It calls a tool "when the request maps to that tool's described capability and the answer isn't already in context."
• For a hard guarantee, tool_choice can force tool use (any = must use some tool; tool = must use a specific named tool; none = no tools). Auto behavior is also steerable via the system prompt ("Use the tools to investigate before responding").

Tools as structured output

• Because a tool_use block is a schema-conforming object, tool use is the mechanism for structured output: define a tool whose input_schema is the shape you want, and the model fills it. strict: true "ensures Claude's tool calls always match your schema exactly."

Missing parameters

• If the prompt lacks enough information to fill a required parameter, more capable models "recognize that a parameter is missing and ask for it," while others "may do its best to infer a reasonable value." Required-parameter design matters.

Relevant To

• concepts: [tool-use, function-calling, tool-schema, agentic-loop, tool-result, structured-output, tool-choice, react]
• projects: [06-ai-coding-copilot, 08-ai-agent]

Notes

• The lab calls tools via LiteLLM (OpenAI-style), not the raw Anthropic API, so it works across Groq/Ollama/Anthropic with one code path. The OpenAI mapping of the same concepts: a tool is {"type":"function","function":{"name","description","parameters":<JSON Schema>}}; the model's request arrives at response.choices[0].message.tool_calls (each has id and function.name + function.arguments as a JSON string); you append the assistant message, then one {"role":"tool","tool_call_id":id,"content":result} message per call; tool_choice="auto". The loop ends when message.tool_calls is empty. (Source: sources/official-docs/litellm-completion.md.)
• arguments is a JSON string in the OpenAI/LiteLLM shape — you must json.loads it before dispatching. Forgetting this is a common first bug.
• The description is the API. The model never sees your function body — only name + description + schema. A vague description = the model picks the wrong tool or fills bad args. This is the "agent-computer interface" point from sources/articles/building-effective-agents.md.
• The loop needs a cap. A model can request tools indefinitely (or get stuck calling the same one). Always bound the loop (max_steps) — see sources/papers/react-paper.md for the reasoning-trace structure that makes loops terminate sensibly.