Anthropic Tool Use XML Prompt Template

This prompt template is for engineering teams building tool-using AI systems with Anthropic's Claude models. Use it when you need Claude to reliably select and call external tools by embedding tool definitions in Anthropic's expected XML structure. The template wraps tool schemas, argument descriptions, and usage examples into a single system prompt that enforces schema compliance and predictable tool-call parsing. It belongs in the prompt assembly layer before any user input is added, serving as the foundation for single-turn tool selection and argument population.

The ideal user is a developer or AI engineer who already has tool definitions ready and needs a production-grade prompt that produces parseable tool calls. You should have your tool schemas defined with clear names, descriptions, and parameter types before using this template. The prompt expects you to populate placeholders for tool definitions in Anthropic's XML format, optional few-shot examples, and output constraints. It works best for single-step tool selection where one tool call is expected per turn, not for multi-step agent workflows that require planning prompts layered on top of tool selection.

Do not use this template for OpenAI function calling, which requires a different JSON schema format and tool call structure. Avoid it for multi-step agent workflows that need planning, reflection, or tool call sequencing prompts layered on top. It is not designed for dynamic tool discovery where available tools change mid-session without prompt reassembly. If your use case involves parallel tool calls, user confirmation before execution, or tool call retry with error context, pair this template with the specialized sibling prompts in the Tool Schema and Function Definition Integration group rather than trying to overload this single template.

This template assembles tool definitions into the XML format Claude expects for tool use. Inject it before the user message in your prompt assembly pipeline. The structure enforces argument discipline, provides usage examples, and constrains output to valid tool calls or clarification requests. Replace each square-bracket placeholder with your actual tool definitions, constraints, and risk policies before sending to the model.

xmlCopy
<system>
You are an AI assistant with access to the following tools. Use them when they help complete the user's task. Do not invent tools or capabilities not listed below.

<tools>
[TOOLS]
</tools>

<tool_use_rules>
1. Select the most appropriate tool for the user's request. If multiple tools could apply, choose the one that requires fewer assumptions.
2. Populate all required arguments. If a required argument is missing and cannot be reasonably inferred, ask the user for clarification instead of guessing.
3. Use the exact argument types specified in each tool definition. Do not pass strings where numbers are expected, or vice versa.
4. For [RISK_LEVEL] operations, explain what will happen and wait for user confirmation before executing.
5. If a tool call fails, read the error message and correct your next attempt. Do not retry more than [MAX_RETRIES] times without escalating.
6. After receiving tool output, synthesize a clear response for the user. Do not expose raw error stacks or internal identifiers unless the user asks for debugging details.
</tool_use_rules>

<output_format>
Respond with a tool call in this XML structure when using a tool:
<function_calls>
<invoke name="tool_name">
<parameter name="param1">value1</parameter>
<parameter name="param2">value2</parameter>
</invoke>
</function_calls>

When asking the user for clarification, respond in plain text explaining what information you need and why.
</output_format>

<constraints>
[CONSTRAINTS]
</constraints>

<examples>
[EXAMPLES]
</examples>
</system>

Adapting the template: Replace [TOOLS] with one or more <tool_description> blocks, each containing a <name>, <description>, <parameters> with typed <parameter> entries, and optional <example> usage. Set [RISK_LEVEL] to high-risk, destructive, irreversible, or all depending on your confirmation policy. [MAX_RETRIES] should be a small integer, typically 2 or 3. Use [CONSTRAINTS] to add domain-specific rules such as prohibited argument combinations, rate limits, or data handling requirements. Populate [EXAMPLES] with 2-4 few-shot demonstrations showing correct tool selection, argument population, clarification requests, and error recovery.

Validation and testing: Before deploying, validate that every tool definition in [TOOLS] includes a name, description, and typed parameters with required/optional flags. Test with inputs that should trigger each tool, inputs where multiple tools could apply, inputs with missing required arguments, and inputs that should produce no tool call. Run eval checks for correct tool selection, argument type adherence, appropriate clarification requests, and refusal of out-of-policy actions. For high-risk domains, require human review of tool call logs during the first [N] production hours.

What to avoid: Do not omit the <tool_use_rules> block—without explicit rules, Claude may invent tools, skip required arguments, or execute high-risk actions without confirmation. Do not use this template with non-Anthropic models without adapting the XML structure to their expected format. Do not set [MAX_RETRIES] to 0 unless you want the model to give up on the first failure without correction. Do not skip <examples> when introducing new or ambiguous tools; few-shot demonstrations significantly improve selection accuracy.

This prompt template is designed to be assembled at runtime by an application layer, not pasted once into a static system prompt. The application is responsible for injecting the correct tool definitions, user input, and context into the XML structure before each API call. The core integration pattern is: fetch available tools for the current user or session, serialize them into the <tools> XML block using the schema defined in the template, append the user's message inside <user_query>, and send the complete payload to the Anthropic Messages API. The model will return either a text response or a tool_use content block. Your harness must handle both paths.

Validation and parsing is the first critical integration point. When the model returns a tool_use block, validate that the tool name matches one of the provided definitions, that all required arguments are present, and that argument types match the schema. If validation fails, do not execute the tool. Instead, construct a retry prompt that includes the original tool definitions, the failed tool call, and a clear error message such as 'Tool call failed validation: missing required argument [start_date]. Please correct and retry.' Set a maximum retry count (typically 2-3 attempts) and escalate to a human or fallback response if retries are exhausted. For high-risk operations like database writes, financial transactions, or user data mutations, insert a human approval step before execution: surface the proposed tool call with a clear explanation of side effects and wait for explicit confirmation.

Logging and observability are essential for debugging tool-use workflows. Log the full assembled prompt (with PII redacted), the model's raw response, any validation errors, retry attempts, and the final tool execution result. Attach a trace ID that spans the entire request chain so you can reconstruct what happened when a tool call produces an unexpected outcome. Use structured logging fields: trace_id, model_id, tools_provided, tool_called, validation_passed, retry_count, and human_approval_required. This data feeds both debugging sessions and eval pipelines that measure tool selection accuracy and argument correctness over time. Wire these logs into your existing observability stack rather than building a separate AI-specific silo.

Model choice and fallback should be configured in the harness, not hardcoded in the prompt. Start with Claude Sonnet for most tool-use workloads; it balances speed, cost, and instruction-following reliability. For complex multi-tool scenarios with many overlapping definitions, consider Claude Opus for its stronger disambiguation. Implement a fallback path: if the primary model returns an unparseable response after all retries, either escalate to a more capable model or route to a human review queue. Do not silently drop failed tool calls. The harness should also enforce a timeout on tool execution (e.g., 30 seconds for API calls) and return a clear timeout error to the model so it can decide whether to retry, ask the user to wait, or abandon the operation.