Tool Call Operation Type Contract Validation Prompt

This prompt is a pre-execution guardrail for API platform teams and authorization architects who need to programmatically enforce that a proposed tool call matches its declared operation type contract. The core job-to-be-done is catching a dangerous mismatch before execution: a tool that is declared as read-only in the tool registry receiving arguments that would cause a write, mutation, or side effect. This is a common failure mode in agentic systems where schema drift between a tool's declaration and its actual implementation creates a security gap that static analysis often misses. Use this prompt when a model or agent has already selected a tool and constructed its arguments, and you need a structured compliance report before the call is allowed to proceed.

The ideal user is an engineer integrating this validation step into a tool-execution pipeline. The required context is a tool registry with declared operation types (e.g., read, write, destructive) and a proposed tool call payload that includes the tool name, its arguments, and the declared operation type. This prompt is not a tool-selection prompt; it does not help the model choose which tool to call. It is also not a replacement for runtime authorization or IAM policy enforcement. It is a contract-validation step that catches semantic mismatches, such as a GET /users endpoint declared as read being called with a DELETE action in the arguments. The prompt produces a structured compliance report, not a binary allow/deny decision, so your harness must interpret the report and act on it.

Do not use this prompt when you lack a reliable tool registry with declared operation types, as the validation is only as strong as the registry's accuracy. It is also the wrong tool for validating argument schemas against a JSON Schema definition—that is a type-checking problem, not a contract-compliance problem. If your goal is to classify user intent as read or write before any tool is selected, use the sibling prompt 'Read vs Write Intent Classification Prompt Template' instead. For post-execution audit, pair this prompt with the 'Tool Call Audit and Observability Prompts' from the observability pillar. Always require human review for any flagged mismatch in production systems where a false negative could result in unauthorized state changes.

This prompt template is designed to be pasted into your system prompt or placed as a pre-execution validation step before any tool call is dispatched. It enforces the contract between a tool's declared operation type (read-only, write, destructive, or user-visible) and the actual arguments being passed. The primary job is to catch mismatches—such as a tool declared as read-only receiving a DELETE verb, a POST body, or a mutation parameter—before execution reaches your backend. Use this when you have a tool registry with declared operation types and you need a structured compliance report before allowing the call to proceed.

textCopy
You are a tool-call contract validator. Your job is to compare a proposed tool call against the tool's declared operation type contract and flag any mismatches.

## INPUTS
- Tool Declaration: [TOOL_DECLARATION]
- Proposed Tool Call: [PROPOSED_TOOL_CALL]
- Operation Type Contract: [OPERATION_TYPE_CONTRACT]
- Additional Constraints: [CONSTRAINTS]

## OPERATION TYPE DEFINITIONS
- read-only: Must not mutate state, create resources, delete data, or trigger side effects. Safe for GET, SELECT, DESCRIBE, LIST operations.
- write: May create or update resources. Must not delete or destroy. Safe for POST, PUT, PATCH, INSERT, UPDATE.
- destructive: May delete, drop, truncate, or permanently remove resources. Requires explicit user confirmation.
- user-visible: May display information, send notifications, or render UI. Does not mutate backend state but may have observable effects.

## VALIDATION RULES
1. If the tool is declared read-only, reject any call containing write, delete, or mutation arguments (e.g., HTTP methods other than GET/HEAD/OPTIONS, SQL INSERT/UPDATE/DELETE/DROP, file write operations).
2. If the tool is declared write, reject any call containing destructive operations (DELETE, DROP, TRUNCATE, PURGE).
3. If the tool is declared destructive, flag the call for human review regardless of argument validity.
4. Check for argument-verb mismatch: a parameter named `action` with value `delete` on a read-only tool is a violation.
5. Check for indirect mutations: arguments that reference callback URLs, webhook triggers, or state-changing endpoints on a read-only tool are violations.
6. If the proposed call includes arguments not present in the tool declaration schema, flag as a schema drift warning.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "compliant": boolean,
  "violations": [
    {
      "severity": "BLOCKER" | "WARNING" | "REVIEW_REQUIRED",
      "rule": "string identifying which validation rule was triggered",
      "field": "string path to the violating argument or property",
      "expected": "string describing what the contract requires",
      "actual": "string describing what was found",
      "recommendation": "string describing how to resolve the violation"
    }
  ],
  "requires_human_review": boolean,
  "contract_compliance_score": number between 0.0 and 1.0
}

## CONSTRAINTS
- Do not execute the tool call. Only validate it.
- If the tool declaration is missing or incomplete, return a single BLOCKER violation with rule "missing-tool-declaration".
- If the operation type contract is not one of the four defined types, return a BLOCKER violation with rule "unknown-operation-type".
- Always check for argument-verb mismatch even if the top-level method appears correct.
- Flag any argument that could cause a side effect on a read-only tool, even if the argument name is ambiguous.

To adapt this template, replace [TOOL_DECLARATION] with the full tool schema including name, description, parameters, and their types. Replace [PROPOSED_TOOL_CALL] with the actual function name and arguments the model generated. Replace [OPERATION_TYPE_CONTRACT] with one of the four defined types from your tool registry. Use [CONSTRAINTS] to add domain-specific rules, such as "no PII fields in read-only queries" or "rate-limit write operations to 10 per minute." If your system uses OpenAPI or JSON Schema for tool definitions, map the HTTP method or SQL verb to the operation type before invoking this prompt. For high-risk deployments, always set requires_human_review to true when the compliance score drops below 0.8 or when any BLOCKER violation is present. Wire the output into your pre-execution guard: if compliant is false, abort the tool call and log the violations for audit. If compliant is true but requires_human_review is true, queue the call for approval before execution.

This prompt is designed to sit between your tool declaration registry and the execution layer. It should never be called at runtime on every user request; instead, integrate it into your tool registration pipeline, CI checks, or a pre-commit hook that validates tool schemas before they are deployed. The core job is to catch mismatches where a tool's declared operation_type (e.g., read-only) conflicts with its actual parameter schema or description (e.g., a DELETE endpoint described as a retrieval tool). Run this validation whenever a new tool is added, a schema is updated, or a tool description is rewritten.

To wire this into an application, build a thin harness that fetches the tool declaration from your registry, constructs the prompt with the [TOOL_DECLARATION] and [OPERATION_TYPE_CONTRACT] placeholders, and sends it to a fast, cost-effective model like GPT-4o-mini or Claude Haiku. The output must be parsed as a structured JSON report containing a compliance_status enum (compliant, non_compliant, review_required) and a list of violations. Implement a strict validator on the output: if the JSON is malformed or missing required fields, retry once with a simplified schema, then fail closed and flag for human review. Log every validation result with the tool name, version, timestamp, and raw model output for auditability. For high-risk production systems, add a human approval gate on any non_compliant result before the tool can be registered or updated.

Common failure modes to guard against include schema drift between the declared contract and the actual implementation, false negatives where the model misses an indirect mutation (e.g., a GET that triggers a state change), and prompt injection via tool descriptions that contain adversarial text. Mitigate these by version-locking your tool schemas, running the validation on every schema change, and sanitizing tool descriptions before they enter the prompt. Do not rely solely on this prompt for runtime safety—pair it with pre-execution guardrails that validate actual tool call arguments before execution. The next step after implementing this harness is to integrate the validation report into your deployment pipeline so that non-compliant tools block deployment until resolved.