Argument Range and Constraint Check Prompt Template

This prompt is a pre-execution guardrail for backend engineers and platform teams who need to validate LLM-generated tool call arguments before they hit an API, database, or internal service. It checks numeric ranges, string lengths, and array sizes against a provided constraint specification and returns a structured pass/fail report. Use it when out-of-bounds arguments would cause downstream 4xx errors, silent data corruption, or expensive retry loops. This prompt belongs in the validation layer between tool call generation and tool call dispatch. It does not repair arguments; pair it with an argument repair prompt if you need automated correction.

The ideal user is a platform engineer or backend developer integrating LLM tool-calling into a production system where argument validation cannot be deferred to the downstream API. You need this prompt when your tool execution layer lacks robust input validation, when downstream services have strict numeric or size constraints that are not fully expressed in the tool's JSON Schema, or when you want a structured, auditable validation report before any side effects occur. Required context includes the tool call arguments to validate and a constraint specification defining acceptable ranges, lengths, and sizes. The prompt expects both inputs to be provided in a structured format so it can produce a deterministic pass/fail decision per field.

Do not use this prompt as a replacement for proper API-level input validation or JSON Schema enforcement. It is a supplementary guardrail, not a primary defense. Avoid using it for complex business-rule validation that requires cross-field logic, database lookups, or user-permission checks—those scenarios require dedicated business-rule validation prompts. This prompt also does not handle type coercion, enum enforcement, or injection detection; pair it with specialized validation prompts from the Tool Call Validation and Pre-Execution Guardrails category when you need a complete validation pipeline. If you need automated correction after a failure, chain this prompt's output into an argument repair prompt rather than expecting the constraint checker to fix the arguments itself.

This template is designed to be dropped directly into your tool-call validation pipeline. It accepts a set of arguments and a constraint specification, then returns a structured JSON report indicating whether each argument falls within its defined bounds. The prompt does not modify or repair the arguments—it only validates and reports. This separation of concerns keeps the validation step auditable and prevents silent corrections that could mask upstream bugs in argument construction.

textCopy
You are a strict argument validation engine. Your only job is to check whether the provided tool call arguments conform to the constraint specification below. Do not modify, repair, or suggest corrections for any argument. Do not call any tools. Return only the validation report JSON.

## TOOL CALL ARGUMENTS
```json
[ARGUMENTS]

CONSTRAINT SPECIFICATION

jsonCopy
[CONSTRAINTS]

VALIDATION RULES

1. For each field in the constraint specification, locate the corresponding field in the tool call arguments. If the field is absent and the constraint specifies required: true, mark it as status: "FAIL" with violation: "MISSING_REQUIRED".
2. For numeric fields, check min, max, exclusiveMin, exclusiveMax as specified. Report the actual value and the violated bound.
3. For string fields, check minLength, maxLength. Report the actual length and the violated bound.
4. For array fields, check minItems, maxItems. Report the actual item count and the violated bound.
5. If a field passes all applicable constraints, mark it as status: "PASS".
6. After evaluating all fields, set overall_decision to "REJECT" if any field has status: "FAIL". Otherwise, set it to "ALLOW".

OUTPUT FORMAT

Return ONLY a JSON object with this exact structure:

jsonCopy
{
  "validation_report": {
    "overall_decision": "ALLOW" | "REJECT",
    "fields": [
      {
        "field_name": "string",
        "status": "PASS" | "FAIL",
        "actual_value": "the value from arguments or null if missing",
        "violation": "NONE" | "BELOW_MIN" | "ABOVE_MAX" | "BELOW_MIN_LENGTH" | "ABOVE_MAX_LENGTH" | "BELOW_MIN_ITEMS" | "ABOVE_MAX_ITEMS" | "MISSING_REQUIRED",
        "constraint_broken": "description of the specific bound that was violated, or null if passed",
        "message": "human-readable summary of the check"
      }
    ]
  }
}

EXAMPLE

Input Arguments

jsonCopy
{"page_size": 200, "query": "", "tags": []}

Constraints

jsonCopy
{
  "page_size": {"type": "integer", "min": 1, "max": 100, "required": true},
  "query": {"type": "string", "minLength": 1, "required": false},
  "tags": {"type": "array", "minItems": 1, "required": false}
}

Expected Output

jsonCopy
{
  "validation_report": {
    "overall_decision": "REJECT",
    "fields": [
      {
        "field_name": "page_size",
        "status": "FAIL",
        "actual_value": 200,
        "violation": "ABOVE_MAX",
        "constraint_broken": "max: 100",
        "message": "page_size value 200 exceeds maximum allowed value of 100"
      },
      {
        "field_name": "query",
        "status": "FAIL",
        "actual_value": "",
        "violation": "BELOW_MIN_LENGTH",
        "constraint_broken": "minLength: 1",
        "message": "query length 0 is below minimum length of 1"
      },
      {
        "field_name": "tags",
        "status": "FAIL",
        "actual_value": [],
        "violation": "BELOW_MIN_ITEMS",
        "constraint_broken": "minItems: 1",
        "message": "tags array has 0 items, below minimum of 1"
      }
    ]
  }
}

Now validate the provided arguments against the constraints.

To adapt this template for your system, replace the [ARGUMENTS] and [CONSTRAINTS] placeholders at runtime with the actual tool call payload and your constraint specification. The constraint specification should be a JSON object where each key is a field name and the value is an object with type (one of integer, number, string, array), optional bounds (min, max, minLength, maxLength, minItems, maxItems), and an optional required boolean. If your system uses JSON Schema for tool definitions, you can extract the relevant constraint fields programmatically rather than authoring a separate specification. The output structure is designed to be consumed by an upstream orchestrator: check overall_decision to gate execution, and use the per-field violation codes to decide whether to trigger a clarification prompt, an argument repair loop, or a hard rejection with a user-facing explanation. For high-risk write operations, always pair this validation with a separate intent re-validation step before dispatching the tool call.

This prompt is designed as a pre-execution gate that sits between the model's tool-call generation and the actual API dispatch. In a production harness, you should never execute a tool call without first running its arguments through this validation step. The prompt expects a JSON payload containing the tool call arguments and a set of defined constraints (numeric ranges, string length limits, array size bounds). It returns a structured validation report that your application code can parse to decide whether to proceed, repair, or reject the call. The harness should treat this prompt as a deterministic validation layer—while an LLM generates the report, the output schema is rigid enough to be machine-read and acted upon automatically.

Integration flow: 1) The primary agent or tool-selection prompt generates a candidate tool call. 2) Your application extracts the tool name and arguments. 3) A constraint configuration is loaded from a registry keyed by tool name and argument path (e.g., tools.transfer.amount.max). 4) The constraint config and candidate arguments are injected into the [TOOL_CALL_ARGUMENTS] and [CONSTRAINT_DEFINITIONS] placeholders of this prompt. 5) The LLM returns a JSON report with validations (an array of per-field pass/fail objects) and overall_valid (a boolean). 6) Your application checks overall_valid. If true, dispatch the tool call. If false, route to a repair loop or clarification prompt. Model choice: Use a fast, cheaper model for this validation step (e.g., GPT-4o-mini, Claude Haiku) since the task is structured classification, not complex reasoning. Retries: If the LLM fails to return valid JSON matching the [OUTPUT_SCHEMA], retry once with a stricter system instruction. After two failures, reject the tool call and log the raw response for debugging.

Validation and logging: Every validation report should be logged alongside the candidate arguments, the constraint definitions used, the model version, and the final dispatch decision (proceeded/repaired/rejected). This creates an audit trail for debugging false positives (valid arguments flagged as invalid) and false negatives (invalid arguments that slipped through). For high-risk operations such as financial transactions or data deletion, add a human approval step when overall_valid is true but any individual field validation carries a confidence score below 0.9. The prompt includes a [RISK_LEVEL] placeholder—set this to high for destructive or regulated operations, which instructs the model to include explicit risk notes in the report. Avoid: Do not use this prompt as a replacement for server-side API validation. It is a pre-flight check that reduces error rates and improves user experience, but the downstream API must still enforce its own contracts. The constraint definitions you pass into [CONSTRAINT_DEFINITIONS] should be derived from your API schemas or a configuration store, not hardcoded in the prompt template itself.