Function Call Repair from Natural Language Fallback Prompt Template

This prompt template is designed for agent developers and platform engineers who need to recover structured function calls when a model outputs natural language prose instead of a valid JSON tool call. The core job-to-be-done is intent extraction: taking a user's or sub-agent's free-text request (e.g., 'send an email to Priya about the Q3 report') and mapping it to the correct tool name and a valid set of arguments from the available tool registry. The ideal user is an engineer building an agent loop that cannot afford to abort execution on a format error and needs a reliable repair step before retrying the tool call.

Use this prompt when the model's primary output is a natural language description of an action rather than a structured function call, and you have access to the original tool schema and invocation context. This is common with models that lack native function-calling support, when using cheaper models for cost optimization, or when a model 'thinks aloud' before acting. Do not use this prompt when the model has already produced valid JSON that merely fails a business rule—use a schema-mismatch or type-coercion repair prompt instead. Also avoid this prompt when the natural language request is genuinely ambiguous and requires user clarification rather than automated inference; escalating to a human is safer than hallucinating arguments.

The prompt requires the original natural language utterance, the list of available tools with their schemas, and the conversation context. It outputs a structured function call with an extracted tool name and arguments. Before shipping, you must wire in validation against the tool schema, set a retry budget, and add an eval that checks for argument hallucination—specifically, that no argument value was invented without grounding in the input text. Start by copying the template below, substituting your tool registry and input, then build the harness described in the implementation section.

This prompt template is designed to recover from a common agent failure mode: the model describes what it wants to do in natural language instead of emitting a valid function call. Use this template when your agent loop receives a text response that contains an implied tool invocation but no structured JSON. The prompt instructs the model to extract the intended tool name, arguments, and any clarifying questions from the free text, then output a clean, schema-conformant function call. It is not a replacement for proper tool-use fine-tuning or system prompt design—it is a repair step for production fallback.

textCopy
You are a function call repair agent. Your job is to convert a natural language description of a tool invocation into a valid structured function call.

## INPUT
Natural language agent response:
"""
[INPUT_TEXT]
"""

## AVAILABLE TOOLS
[TOOLS]

## CONSTRAINTS
- Output ONLY a valid JSON object with the following structure. No markdown, no commentary.
- If the input describes a tool that does not match any available tool, set `tool_name` to `null` and explain the mismatch in `clarification`.
- If arguments are missing or ambiguous, set them to `null` and list what is needed in `clarification`.
- Do not invent argument values that are not present in the input text.
- Preserve the user's intent exactly. Do not add, remove, or reinterpret actions.

## OUTPUT SCHEMA
{
  "tool_name": "string | null",
  "arguments": {},
  "clarification": "string | null",
  "confidence": "high | medium | low"
}

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace each square-bracket placeholder with production data. [INPUT_TEXT] should contain the raw natural language response from the model. [TOOLS] must include the full function definitions—names, descriptions, and parameter schemas—exactly as they were provided in the original request. [EXAMPLES] should contain at least two few-shot demonstrations: one showing a straightforward extraction and one showing an ambiguous or missing-tool case. Set [RISK_LEVEL] to high if the tool performs destructive actions (delete, send, charge) so downstream code can enforce human approval. After the prompt returns, validate the output against the schema before executing any tool. If confidence is low or clarification is populated, route to a human or a clarification step rather than proceeding automatically.

This prompt is designed as a recovery step inside an agent execution loop, not as a standalone endpoint. It should be invoked only after a primary function-calling attempt has failed—specifically when the model returns unstructured prose instead of a valid tool call JSON. The harness must first detect this failure mode by checking whether the model's output is parseable JSON matching a known tool schema. If the output is valid JSON but fails schema validation, route to a structured repair prompt (such as Malformed Tool Call JSON Repair) instead. This prompt is exclusively for the prose-to-structured conversion path.

Wire the prompt into your agent framework as a conditional branch. After the primary model invocation, run a lightweight classifier or regex check: if the response contains no JSON block or the JSON parser throws, extract the full text response and pass it as [NATURAL_LANGUAGE_INPUT]. Supply the [TOOL_REGISTRY] as a list of available tool names with brief descriptions—do not include full schemas here, as the goal is disambiguation and intent extraction, not schema validation. The [CONVERSATION_CONTEXT] should include the last 2-3 user and assistant turns to ground the repair. Set a strict retry budget: this prompt should run at most once per turn. If it fails again, escalate to a human or log the failure for offline analysis rather than looping indefinitely.

For validation, parse the repaired output and run it through the same tool call validator used in your primary path. Check that the tool_name matches an entry in your registry exactly (case-sensitive comparison). Validate that all required arguments for that tool are present and correctly typed. Log every repair attempt with: the original prose text, the repaired JSON, whether validation passed, and the tool name extracted. This audit trail is critical for detecting systemic failure patterns—such as a model consistently failing to call a specific tool—and for tuning the primary prompt to reduce fallback frequency. If your application operates in a regulated domain, require human approval before executing any repaired tool call, and surface both the original prose and the repair in the review UI.