Tool Call Argument Formatting Demonstration Prompt

This prompt is for agent developers who need a model to construct well-formed function call arguments reliably. It uses worked examples to teach correct tool selection, argument typing, optional parameter handling, and error-recovery patterns. Use this when abstract tool descriptions produce inconsistent argument structures, when the model hallucinates parameter names, or when you need to demonstrate the exact JSON schema for each tool call. This prompt belongs in the agent control loop after tool schemas are defined but before execution. It assumes you already have a validated tool registry and need the model to populate call signatures correctly.

Deploy this prompt when you observe specific failure modes: the model selects the wrong tool from a multi-tool registry, omits required parameters, invents parameter names not present in the schema, or passes arguments with incorrect types (e.g., a string where an integer is required). It is also appropriate when optional parameters are consistently mishandled—either included when they should be omitted or omitted when the task context clearly requires them. The demonstration format works best when you have 3-8 representative examples covering the most common tool call patterns in your application. Each example should show the full input context, the correct tool selection, and the exact argument payload. Include at least one example where no tool should be called and one where an error-recovery pattern is demonstrated, such as requesting clarification when required information is missing.

Do not use this prompt when a simple schema description in the system message already produces reliable results. If your model consistently generates correct function calls from JSON Schema definitions alone, adding demonstrations adds token cost without benefit. Similarly, avoid this approach when your tool registry changes frequently—maintaining synchronized examples across tool updates creates a maintenance burden that may outweigh the reliability gain. For high-risk domains such as financial transactions or healthcare actions, always pair this prompt with a validation harness that checks argument schemas before execution, and require human approval for write operations. After deploying, monitor for argument hallucination rate and tool selection accuracy as your primary eval metrics.

This template teaches the model to select the correct tool and populate its arguments accurately by showing worked examples rather than relying solely on abstract tool descriptions. The demonstration block pairs user requests with annotated tool calls, highlighting argument types, optional parameter handling, and error-recovery patterns. Replace the square-bracket placeholders with your actual tool definitions, examples, and validation rules before use.

codeCopy
You are an agent that selects and calls tools based on user requests. You have access to the following tools:

[TOOLS]

When a user makes a request, you must:
1. Select the most appropriate tool from the available list.
2. Construct a valid function call with correctly typed arguments.
3. Handle optional parameters appropriately—omit them when not needed, include them when specified.
4. If the request is ambiguous or missing required parameters, ask a clarifying question instead of guessing.
5. If no tool matches the request, respond with a plain-text explanation of what you cannot do.

Here are examples of correct tool call formatting:

[EXAMPLES]

Now, respond to the following user request by selecting the correct tool and constructing the appropriate arguments. Output only the function call in valid JSON format matching the tool's parameter schema.

User request: [INPUT]

Adaptation notes: Replace [TOOLS] with your actual function definitions in JSON Schema format, including parameter names, types, required fields, and descriptions. Populate [EXAMPLES] with 3-5 annotated input-output pairs showing correct tool selection, argument typing, optional parameter handling, and at least one error-recovery case where the model asks for clarification. The examples should use a consistent delimiter pattern (e.g., ### Example N ### with clear User: and Assistant: role markers) to prevent parsing ambiguity. Before deploying, validate that the prompt produces schema-conformant outputs by running it against a test harness that checks argument types, required field presence, and hallucinated parameter detection. For high-stakes production use, add a post-generation validation layer that rejects calls with unknown parameters or type mismatches before execution.

This prompt is not a standalone artifact; it is a component inside an agent's tool-use control loop. The prompt's job is to teach the model how to select the correct tool and format its arguments by providing worked examples of valid calls, optional parameter handling, and error-recovery patterns. The surrounding harness must validate the model's output against the actual tool schemas, retry on failure, and log every attempt for debugging and evaluation. Without this harness, even a well-crafted demonstration prompt will silently produce hallucinated parameter names, type mismatches, or calls to non-existent tools in production.

To integrate this prompt, wrap it in a function that assembles the full model request: system instructions, the demonstration prompt with [TOOLS] and [EXAMPLES] placeholders populated from your live tool registry, and the current user [INPUT]. After receiving the model's response, parse the proposed tool call and validate it against the JSON Schema for the selected tool. Check that all required parameters are present, no extra parameters are hallucinated, and all types match. If validation fails, construct a retry prompt that includes the original request, the invalid output, and the specific validation error message. Limit retries to a fixed number (typically 2-3) before escalating to a human or falling back to a safe default. Log every attempt—including the raw model output, validation result, and retry count—to your observability platform for trace analysis and prompt debugging.

For high-stakes tool calls such as database writes, financial transactions, or customer-facing actions, insert a human approval step after successful validation but before execution. Present the validated tool call arguments in a review UI with a clear summary of the action and its parameters. Do not execute the tool until approval is received. For lower-risk read-only operations, you can skip the approval gate but should still log the call for audit purposes. Avoid wiring this prompt directly to tool execution without validation; the demonstration format teaches the model the pattern, but it does not guarantee correctness on every invocation.