Out of the box, Claude knows only two things: what was in its training data and what you put in the prompt. It cannot see your order database, your ticketing system, or today's inventory. Tool use (sometimes called function calling) closes that gap. You describe the functions your application offers — "look up an order," "search the policy wiki," "create a ticket" — and Claude decides when to ask for them, with what inputs. Your code does the actual work. It is the single most important building block in enterprise LLM applications, and it is available on all four third-party platforms: Amazon Bedrock, Google Vertex AI, Microsoft Foundry, and Claude Platform on AWS.
What tool use actually is
The name misleads people. Claude never connects to your systems, holds credentials, or executes anything. Tool use is a structured conversation protocol. You send a request that includes, alongside the user's message, a list of tool definitions: each one has a name, a plain-English description, and a schema describing its inputs. If Claude decides a tool would help answer the question, it does not reply with prose — it replies with a structured request: "call get_order_status with order_id: A-1042."
Your application receives that request, runs whatever real code it maps to — a SQL query, an internal API call, a search — and sends the result back as the next message in the conversation. Claude then reads the result and writes its answer. The model proposes; your code disposes. Every side effect happens in code you wrote, deployed, and can audit.
A minimal example
Here is the shape of a tool-use request on Bedrock. The only platform-specific parts are the client class and the anthropic. model ID prefix; on Vertex AI, Foundry, or Claude Platform on AWS the tool definition is identical.
from anthropic import AnthropicBedrockMantle
client = AnthropicBedrockMantle(aws_region="us-east-1")
tools = [{
"name": "get_order_status",
"description": "Look up the current status of a customer order.",
"input_schema": {
"type": "object",
"properties": {"order_id": {"type": "string"}},
"required": ["order_id"],
},
}]
response = client.messages.create(
model="anthropic.claude-sonnet-5", max_tokens=1024, tools=tools,
messages=[{"role": "user", "content": "Where is order A-1042?"}],
)If the model chooses the tool, response contains a tool-use block instead of a final answer. Your code runs the lookup, appends the result to the message list, and calls the API again. That request–execute–respond loop, repeated until Claude produces a text answer, is the whole pattern.
Why it is the foundation of useful apps
Almost every business use case on this site is tool use underneath. A support assistant calls tools to fetch account details and open tickets. A data-analysis assistant calls a tool that runs vetted SQL. A document pipeline uses a tool schema to force clean, parseable output. Even retrieval-augmented generation is often implemented as a "search" tool. Once your team is comfortable with the loop, new capabilities become a matter of adding tool definitions rather than rebuilding the application.
Tool use also solves the reliability problem that plagues prompt-only designs. Instead of hoping the model formats an answer your parser can read, you get typed, schema-validated inputs and a clear boundary between "the model's judgment" and "your system's actions."
Pitfalls to avoid
Trusting the model as a security boundary. A prompt that says "only look up the current user's orders" is a suggestion, not a control. The tool implementation must check that the requested order belongs to the authenticated user.
Vague descriptions. Claude chooses tools based on the descriptions you write. "Gets data" invites wrong calls; "Look up the current status of a customer order by its ID" gets used correctly. Description quality is prompt engineering.
Too many tools at once. Ten focused tools with crisp names beat forty overlapping ones. Start with the two or three your use case genuinely needs.
Confusing your tools with built-in tools. The pattern above — tools you define and execute — works on all four platforms. Anthropic's server-side built-ins are a different story: the code execution and web fetch tools are not available on Bedrock or Vertex AI, and web search is absent on Bedrock with only a basic variant on Vertex AI. If your design leans on built-ins, check the feature matrix first.
Where to go next
Tool use pairs naturally with structured outputs, which use the same schema mechanism to get parseable JSON, and it is the dividing line in agents vs. workflows — how much freedom you give the model to chain tool calls. For platform setup, start with the quickstart.