Tool Call and Function Argument Schema Validation Prompt

This prompt is designed for agent platform teams who need to programmatically verify that LLM-generated function calls conform to a tool's strict parameter schema before execution. The primary job-to-be-done is automated, argument-level auditing that catches type mismatches, missing required parameters, out-of-set enum values, and structural JSON errors in tool call payloads. The ideal user is an AI engineer or platform developer building a gating mechanism between the LLM's function-calling output and the actual API or tool execution layer. Required context includes the full tool schema (parameters, types, required fields, enums) and the raw LLM-generated function call payload.

Use this prompt when you need a structured, machine-readable audit report that can trigger automatic retries, fallback logic, or human review queues. It is specifically designed for single-step tool call validation, not for evaluating multi-step agent trajectories or the semantic correctness of arguments. The prompt expects a JSON Schema-like tool definition and a candidate function call as input, and it produces a field-level pass/fail report with specific error locations. This is a validation gate, not a repair prompt—pair it with a separate repair or retry prompt if you need to fix malformed calls.

Do not use this prompt for evaluating whether the correct tool was selected for a user's intent; that is a tool-selection evaluation problem covered by the Tool-Use and Function Call Evaluation Prompts pillar. Avoid this prompt when you need to validate the business-logic correctness of argument values (e.g., whether a date is in the future) rather than their schema conformance. For high-stakes production systems where a bad tool call could trigger destructive actions, always combine this automated validation with a human approval step before execution, not after.

This prompt template is designed to be dropped into an evaluation harness that receives a raw tool call payload and a reference schema. It produces a structured, argument-level audit report that flags type mismatches, missing required parameters, out-of-set enum values, and structural JSON errors. Use it when your agent platform needs automated, model-graded validation of function calls before they are executed against live APIs or databases. The template uses square-bracket placeholders so you can inject the specific tool schema, the generated call, and any additional constraints at runtime.

textCopy
You are a strict schema validator for LLM-generated tool calls. Your task is to audit the provided function call arguments against the reference parameter schema and produce a structured validation report.

## INPUTS
- Tool Schema: [TOOL_SCHEMA]
- Generated Tool Call: [TOOL_CALL_PAYLOAD]
- Additional Constraints: [CONSTRAINTS]

## VALIDATION RULES
1. Check that all required parameters from the schema are present in the generated call.
2. For each present parameter, verify the value type matches the schema's expected type (string, number, boolean, array, object).
3. If a parameter has an 'enum' constraint, verify the value is one of the allowed options.
4. Verify the top-level JSON structure is valid and parseable.
5. Flag any parameters present in the call that are not defined in the schema (hallucinated parameters).
6. If the tool name is provided, verify it matches the expected tool name in [TOOL_SCHEMA].

## OUTPUT FORMAT
Return a JSON object with the following structure:
{
  "overall_valid": boolean,
  "tool_name_match": boolean | null,
  "errors": [
    {
      "parameter_path": string,
      "error_type": "missing_required" | "type_mismatch" | "invalid_enum" | "hallucinated_parameter" | "parse_error" | "wrong_tool",
      "expected": string,
      "actual": string,
      "message": string
    }
  ],
  "warnings": [
    {
      "parameter_path": string,
      "message": string
    }
  ]
}

## INSTRUCTIONS
- Be precise about parameter paths using dot notation (e.g., 'user.address.city').
- If the entire payload is unparseable, set overall_valid to false and include a single parse_error entry.
- Do not hallucinate errors. Only report violations you can clearly identify against the schema.
- If no errors are found, return an empty errors array and set overall_valid to true.

To adapt this prompt for your own pipeline, replace the square-bracket placeholders with your actual data. [TOOL_SCHEMA] should contain the full JSON Schema or a simplified parameter definition including types, required flags, and enum values. [TOOL_CALL_PAYLOAD] is the raw string or object the LLM produced. [CONSTRAINTS] can include additional rules like 'disallow null for required fields' or 'permit extra fields if optional'. For high-risk production systems, always pair this prompt with a deterministic JSON Schema validator as a secondary check—the LLM judge provides rich error messages, but a code-based validator provides a hard guarantee. Before shipping, run this prompt against a golden dataset of known valid and invalid tool calls to measure false-positive and false-negative rates.

This prompt is designed to sit after the LLM generates a function call and before that call is executed against a live API, database, or internal service. It acts as a schema-aware gate that audits the generated tool call payload against the tool's parameter schema. The harness should intercept the model's raw output, parse the function call arguments, and pass both the arguments and the tool's JSON Schema definition into this validation prompt. The prompt returns a structured audit report—not just a pass/fail boolean—so your harness can decide whether to block execution, retry with feedback, or escalate for human review.

Integration pattern: In a typical agent loop, the model outputs a message with tool_calls. Your harness extracts the function name and arguments string. It then looks up the tool's parameter schema from your tool registry. The validation prompt receives [TOOL_SCHEMA] (the expected JSON Schema for the function's parameters) and [GENERATED_ARGUMENTS] (the model's parsed arguments object). The prompt returns a JSON report with fields like valid, errors[], warnings[], and hallucinated_parameters[]. Your harness reads valid. If false, the harness can either: (1) inject the error report into the next model turn as a tool response message asking for correction, (2) attempt a programmatic repair if the errors are simple type coercions, or (3) halt the agent and escalate to a human operator if the failure involves hallucinated parameters or wrong tool selection—both of which indicate the model's reasoning is unreliable for this step.

Retry logic and model choice: For cost-sensitive pipelines, use a smaller, faster model for this validation step (e.g., a lightweight JSON-mode model) rather than consuming the primary agent model's context window. Set a maximum retry budget—typically 2 correction attempts—before escalating. Log every validation failure with the full audit report, the tool name, the model that generated the call, and the final disposition (passed, repaired, escalated). This log becomes your evaluation dataset for measuring tool-call accuracy over time. For high-risk actions (write operations, financial transactions, patient data access), configure the harness to always require human approval when the validation report contains any error severity finding, even if a repair is possible. Never silently execute a tool call that failed schema validation—the cost of a malformed API call to a production system is far higher than the latency of a validation check.

What to build next: Wire the validation report into your observability stack so you can track tool-call failure rates by model version, tool, and error type. Use the hallucinated_parameters field to detect when a model is inventing parameters that don't exist in the schema—this is a leading indicator of prompt drift or model regression. If you see hallucinated parameters appearing across multiple tools, revisit your system prompt's tool descriptions and consider adding explicit negative examples. Finally, build a periodic human review of escalated cases to identify patterns that automated retries can't fix, such as consistently wrong tool selection for ambiguous user requests.