Silent Failure Prevention Prompt for Missing Arguments

This prompt is for reliability engineers and platform teams who need to prevent tool-calling models from executing functions with missing, null, or placeholder arguments. The core job is to intercept a proposed tool call before execution, inspect its arguments against the tool's required schema, and either block the call with a targeted clarification request or allow it to proceed. Use this when silent failures caused by missing arguments create downstream data corruption, confusing user experiences, or hard-to-diagnose production incidents. This prompt belongs in a pre-execution guardrail layer, not as a post-hoc repair step.

The ideal deployment point is inside a pre-execution hook in your tool-calling pipeline. After the model generates a function call but before your runtime executes it, pass the proposed tool name, arguments, and the tool's JSON schema into this prompt. The prompt returns a structured decision: proceed with validated arguments, or block with a specific clarification question targeting only the missing or invalid fields. This is not a prompt for fixing malformed JSON (that belongs in output repair) or for deciding which tool to call (that belongs in tool selection). It is strictly a safety net for argument completeness. Wire it into your before_tool_call middleware, log every block decision with the missing field and the clarification text, and set an alert if the block rate spikes, which often signals a model behavior regression or a schema change that wasn't propagated to the prompt.

Do not use this prompt when the tool has no required parameters, when all arguments are optional with safe defaults defined in application code, or when the user has explicitly requested a dry run. In those cases, argument validation is either unnecessary or handled by a different layer. Also avoid using this as the only guardrail for destructive operations—pair it with a separate confirmation prompt for write operations that mutate state, change permissions, or trigger external side effects. The next section provides the copy-ready prompt template you can adapt to your tool schemas and risk tolerance.

This prompt template is designed to sit between argument extraction and tool execution in your pipeline. Its job is narrow: inspect the proposed tool call arguments, identify any required fields that are missing, empty, or filled with obvious placeholders (such as 'N/A', 'TBD', 'unknown', or empty strings), and decide whether to block execution and request clarification. The prompt does not select the tool or extract arguments from conversation context—those steps should already be complete. What it adds is a safety net that catches the most common production failure mode in tool-calling systems: the model quietly passing null, empty, or placeholder values into a function that will either fail with an opaque error or, worse, succeed with garbage data.

textCopy
You are a pre-execution guard for a tool-calling system. Your only job is to inspect the arguments prepared for a function call and decide whether they are complete enough to execute safely.

## INPUT
- Tool Name: [TOOL_NAME]
- Tool Description: [TOOL_DESCRIPTION]
- Required Parameters (from schema): [REQUIRED_PARAMETERS]
- Proposed Arguments: [PROPOSED_ARGUMENTS]
- Conversation Context (last 3 turns): [CONVERSATION_CONTEXT]
- Risk Level: [RISK_LEVEL]

## TASK
1. Compare each required parameter against the proposed arguments.
2. Flag any required parameter that is:
   - Missing entirely from the arguments
   - Present but null, empty string, or whitespace-only
   - Filled with a placeholder value (e.g., 'N/A', 'TBD', 'unknown', '???', 'test', 'placeholder', 'todo', '12345', 'none')
3. For each flagged parameter, determine whether the conversation context contains a usable value that was simply not extracted. If so, note the extractable value.
4. Decide: PROCEED or CLARIFY.

## DECISION RULES
- If ALL required parameters have valid, non-placeholder values: PROCEED.
- If ANY required parameter is missing/invalid AND the conversation context does NOT contain a usable value: CLARIFY.
- If ANY required parameter is missing/invalid BUT the conversation context DOES contain a usable value: PROCEED with the corrected argument noted.
- If [RISK_LEVEL] is 'high' and ANY required parameter is missing/invalid: CLARIFY regardless of context (do not infer for high-risk operations).

## OUTPUT SCHEMA
Return ONLY valid JSON with this exact structure:
{
  "decision": "PROCEED" | "CLARIFY",
  "flagged_parameters": [
    {
      "parameter_name": "string",
      "provided_value": "string or null",
      "issue": "missing" | "empty" | "placeholder" | "invalid_type",
      "extractable_from_context": true | false,
      "extracted_value": "string or null"
    }
  ],
  "corrected_arguments": {},
  "clarification_question": "string or null",
  "rationale": "string"
}

## CONSTRAINTS
- Do not hallucinate argument values that are not present in the conversation context.
- Do not proceed if [RISK_LEVEL] is 'high' and any required argument is missing, even if context suggests a value.
- The clarification_question must be specific, ask for exactly the missing information, and be answerable in one turn.
- If multiple parameters are flagged, ask about all of them in a single clarification_question.
- Never include PII or sensitive data in the rationale field.

To adapt this template, replace the square-bracket placeholders with values from your tool registry and conversation state. [TOOL_NAME] and [TOOL_DESCRIPTION] should come directly from your function schema definitions. [REQUIRED_PARAMETERS] should be a structured list of parameter names and their expected types pulled from the same schema—do not copy-paste the full JSON Schema here; extract only what the guard needs. [PROPOSED_ARGUMENTS] is the argument object the model generated before this guard runs. [CONVERSATION_CONTEXT] should include the last few user and assistant turns, trimmed to avoid token waste. [RISK_LEVEL] is a system-level flag you set based on the tool's side-effect profile: use 'low' for read-only retrieval, 'medium' for state changes that are reversible, and 'high' for destructive operations, financial transactions, or PII exposure. The output schema is designed to be machine-readable so your harness can branch on decision without parsing natural language. If you need to add custom placeholder patterns (your organization might use 'xxx' or '—' as placeholders), extend the list in step 2 of the TASK section rather than rewriting the entire prompt.

This prompt is designed to sit as a pre-execution guard in your tool-calling pipeline, intercepting the model's proposed function call before any side effects occur. The harness should invoke this prompt immediately after the primary model generates a tool call but before that call is dispatched to the API or service. The input to this prompt is the raw tool call object (function name and arguments) alongside the original user request and any conversation context. The output is a structured decision: either proceed with the validated call, or clarify with a specific question targeting the missing or placeholder argument.

Implement the harness as a lightweight validation service that wraps your model's tool-calling output. After receiving the tool call, serialize it to JSON and pass it to this prompt along with the tool's JSON Schema definition. Parse the prompt's response into a strict schema: {"decision": "proceed" | "clarify", "missing_argument": string | null, "clarification_question": string | null, "confidence": float}. If the decision is proceed, forward the call to your tool executor. If clarify, surface the clarification question to the user and pause the tool execution pipeline. Log every decision—especially proceed decisions where the confidence is below 0.85—for later review. For high-risk tools (writes, deletes, financial operations), add a second human-review gate when confidence falls below 0.95.

For eval and regression testing, build a log replay harness that captures production tool calls and their arguments, then replays them through this prompt with the arguments artificially degraded (remove one required field, replace a value with a placeholder like 'string' or 'null'). Measure recall: what percentage of degraded calls trigger a clarify decision? Measure false positives: what percentage of valid, complete calls incorrectly trigger clarification? Target recall above 0.95 and false positives below 0.02 before shipping. Run this eval suite as a CI gate on any prompt or model version change. When the prompt fails to catch a missing argument in production, add that exact case to your eval set before fixing the prompt.