"Tool use" (also called function calling) means you describe functions to Claude in your request; when Claude decides one is needed, it responds with a structured tool_use block instead of prose. Your code runs the actual function and sends the result back, and Claude continues with that information. On Microsoft Foundry, core tool use is GA on both hosting versions — it is one of the features Anthropic's availability table marks as fully supported rather than beta. Microsoft additionally documents Anthropic's predefined client-executed tools (bash, text editor, computer use, and memory) for Foundry deployments.
The request/response cycle
Because Foundry exposes the standard Claude Messages API, the tool-use loop is identical to the first-party API. Define tools with a name, description, and JSON Schema for inputs; check the response's stop_reason; execute; return a tool_result.
from anthropic import AnthropicFoundry
client = AnthropicFoundry(api_key="...", resource="example-resource")
tools = [{
"name": "get_order_status",
"description": "Look up an order's shipping status by order ID.",
"input_schema": {
"type": "object",
"properties": {"order_id": {"type": "string"}},
"required": ["order_id"],
},
}]
msg = client.messages.create(
model="claude-opus-4-8", max_tokens=1024, tools=tools,
messages=[{"role": "user", "content": "Where is order A-1042?"}],
)
if msg.stop_reason == "tool_use":
... # run the tool, append a tool_result message, call again
When stop_reason is "tool_use", iterate over msg.content to find blocks of type tool_use; each carries an id, the tool name, and parsed input. Append the assistant message to your conversation, then add a user message containing a tool_result block that references the same tool_use_id, and call the API again. One model-specific wrinkle: on models that preserve thinking blocks, you must return any thinking block that accompanied the tool request unmodified — the blocks are signature-verified, and altered ones are rejected.
What works on Foundry — and on which hosting version
Foundry offers Claude in two hosting versions, and tool support differs between them. This is the single most common source of confusion.
| Tool category | Hosted on Azure | Hosted on Anthropic |
|---|---|---|
| Custom tools (your functions) | Yes — GA | Yes — GA |
| Predefined client tools (bash, text editor, computer use, memory) | Documented by Microsoft (client tools beta per Anthropic's table) | Documented by Microsoft |
| Server-side tools (web search, web fetch, code execution, tool search) | No — returns 400 Bad Request by design | Beta |
| MCP connector, programmatic tool calling, Agent Skills | No — returns 400 | Beta |
In plain terms: if your code executes the tool, you are fine on any Foundry deployment. If you want Anthropic's servers to execute the tool (web search, code execution), you need a "Hosted on Anthropic infrastructure" deployment, and the feature is beta even there. A request that includes server-side tools against an Azure-hosted deployment fails with 400 Bad Request — that is intentional behavior, not an outage.
Practical notes for production
- Streaming works with tools. Fine-grained tool streaming — which streams tool input JSON as it is generated — is GA on Foundry; Microsoft documents it with the beta header
fine-grained-tool-streaming-2025-05-14. - Tool definitions cost tokens. Every tool schema is injected into the prompt and counts as input tokens against both your bill and your ITPM rate limit, so keep schemas tight and consider prompt caching for large tool sets.
- Validate tool inputs server-side. Claude produces well-formed JSON matching your schema, but your tool implementations should still validate values (IDs exist, ranges are sane) before touching real systems.
- Errors are tool results too. If your tool fails, return the error text in the
tool_result(withis_error) so Claude can recover or explain, rather than aborting the whole conversation.
Governance angle: tools are your control surface
For security and platform teams, client-executed tool use has a governance benefit that is easy to miss: every action Claude "takes" is actually taken by your code, running under your identity, inside your network boundary. On an Azure-hosted Foundry deployment, prompts and outputs are processed on Azure infrastructure, and the tools themselves execute wherever your application runs — so existing controls (managed identities, network rules, audit logging on the systems the tools touch) apply unchanged. Review tool implementations the way you would review any service endpoint: least-privilege credentials, input validation, and audit logs on sensitive operations. The model proposes; your code disposes.
Where to go next
If you need schema-shaped output rather than actions, read getting structured JSON from Claude on Foundry. For the conceptual grounding, see tool use 101, and check Foundry feature parity for the full availability picture.