Tool Call Refusal for Missing Required Arguments Prompt

This prompt is designed for integration developers and backend engineers who need to prevent malformed tool calls from reaching execution. Its core job is to force the model to refuse a function call when required arguments are missing, rather than guessing, hallucinating defaults, or calling the tool with incomplete data. The primary reader is someone wiring an LLM into a production system where a single missing field—such as an empty user_id or a null transaction_amount—can corrupt state, trigger a confusing error downstream, or silently produce incorrect results. This is not a prompt for improving tool selection accuracy or resolving ambiguity between multiple tools; it is strictly for enforcing argument completeness on a specific, already-selected tool call.

Use this prompt when your application layer cannot safely fill missing arguments from session state, user profiles, or deterministic defaults. It is most valuable in systems where the model is expected to extract structured arguments from natural language user input, and where the cost of an incomplete call is high—for example, initiating a payment, updating a medical record, or modifying a production configuration. The prompt should be placed immediately before the tool call execution step in your pipeline, acting as a guard that either returns a validated call or a structured refusal. Do not use this prompt as a substitute for proper schema design; the tool's JSON Schema definition should already mark required fields, and this prompt adds a semantic layer that catches cases where the model might otherwise populate a required field with a nonsense value like "unknown" or an empty string.

Avoid this prompt when your application already has robust pre-execution validation that can deterministically reject incomplete calls and request missing information from the user without an additional model round-trip. It is also unnecessary for low-risk read operations where a missing filter argument might just return a broader result set that the user can refine. In regulated domains such as healthcare or finance, this prompt is a useful defense-in-depth layer, but it must be paired with deterministic schema validation and human review gates for high-risk operations. The output of this prompt should be logged as part of your tool-call audit trail, capturing both the refusal reason and the specific missing arguments identified.

This prompt template is designed to be placed in your system instructions or as a pre-tool-call guard prompt. It instructs the model to inspect the user's request and the available conversation context against the required arguments for any candidate tool. When required arguments are absent, the model must produce a structured refusal object that identifies each missing argument by name, explains why it is required, and asks the user to supply the missing information. This prevents the most common production failure mode for tool calls: execution with null, empty, or hallucinated argument values that corrupt downstream state or produce confusing errors.

textCopy
You are a tool-use assistant with strict argument-completeness discipline. Before you call any tool, you must verify that every required argument for that tool is present and non-empty in the user's request or the conversation context.

If one or more required arguments are missing, you MUST NOT call the tool. Instead, respond with a structured refusal using the exact format below.

## Refusal Format
{
  "action": "refuse_tool_call",
  "tool_name": "[name of the tool you would have called]",
  "missing_arguments": [
    {
      "argument_name": "[exact parameter name from the tool schema]",
      "reason_required": "[one sentence explaining what this argument is used for and why it cannot be defaulted or guessed]",
      "clarification_question": "[a specific question the user can answer to supply this argument]"
    }
  ],
  "refusal_message": "[a polite, user-facing message explaining that you need more information before proceeding, referencing the missing arguments]",
  "partial_arguments_provided": {
    "[argument_name]": "[value already available from context]"
  }
}

## Rules
1. Never guess, fabricate, or default a required argument. If the user did not provide it and it is not in the conversation context, it is missing.
2. If the user's request is ambiguous about which tool to call, first resolve the tool selection, then check argument completeness for the selected tool.
3. If all required arguments are present, proceed with the tool call normally.
4. If optional arguments are missing, you may proceed without them unless the tool description explicitly states they are conditionally required.
5. Always include the `partial_arguments_provided` field so the user can see what you already understood correctly.

## Available Tools
[TOOLS]

## Conversation Context
[CONTEXT]

## User Request
[INPUT]

To adapt this template, replace [TOOLS] with your actual tool definitions in the format your model expects (OpenAI function schemas, Anthropic tool use blocks, or a custom JSON schema). Replace [CONTEXT] with the conversation history or relevant session state. Replace [INPUT] with the user's latest message. For high-risk domains such as finance or healthcare, add a [RISK_LEVEL] field to the refusal object and require human review when risk is elevated. Test this prompt against a golden dataset of requests with known missing arguments to verify that the model refuses correctly and identifies the right missing fields. The partial_arguments_provided field is critical for user experience—it shows the user that the system understood part of their request and only needs specific missing pieces, reducing frustration and rework.

This prompt is designed to sit between the model's initial tool selection and the actual execution of the tool call. In a production harness, you should never execute a tool call directly from the model's output without first passing it through a validation layer. The prompt's refusal output is a structured signal that your application code must parse and act on—typically by surfacing the missing arguments to the user or logging the refusal for review. The harness should treat a refusal as a non-exceptional control flow outcome, not an error.

Implement a pre-execution guard that intercepts the model's response before any tool is invoked. Parse the output for a refusal indicator—such as a refusal key set to true or a top-level error_type of missing_required_arguments. When a refusal is detected, extract the missing_arguments list and the user_prompt field, then surface them to the user interface without calling any backend tool. If the model instead returns a tool call, validate that every argument marked as required in the tool's JSON Schema definition is present and non-null. Missing required arguments should trigger a retry with this refusal prompt, passing the original user input, the tool schema, and the incomplete argument payload as context. Limit retries to a maximum of two attempts before escalating to a human review queue. Log every refusal and retry with the model's reasoning, the missing fields, and the final resolution for later eval analysis.

For high-risk domains such as finance or healthcare, add a human-in-the-loop gate after the second retry. Do not fall back to guessing default values or calling the tool with partial arguments. The harness should also track refusal rates per tool and per argument to identify schema design problems—if a particular required field consistently triggers refusals, the tool description or the user interface may need to be redesigned to collect that information earlier. Wire the refusal events into your observability stack with structured metadata: tool_name, missing_arguments, retry_count, resolution (user_provided, escalated, abandoned), and latency_ms. This data feeds directly into the argument completeness eval and helps tune the prompt's refusal threshold over time.