Malformed Tool Response Repair Prompt Template

This prompt is for integration developers and AI infrastructure engineers who need to recover from a tool call that returned a syntactically or structurally invalid payload. The job-to-be-done is to programmatically normalize, coerce, or reconstruct a valid output from a malformed response so that downstream application logic—such as a JSON parser, a type validator, or a user-facing summary—does not crash or propagate corrupted data. The ideal user is someone who already has a defined expected schema for the tool output and can supply both the malformed payload and the target schema as inputs to the repair prompt.

Use this prompt when the tool response is partially intact but fails schema validation, contains type mismatches, has missing required fields, or includes extra garbage text around a valid core. Do not use this prompt when the tool response is completely empty, represents an authentication or authorization failure, or indicates a systemic outage. Those scenarios require different recovery playbooks, such as empty-result interpretation, auth-failure recovery, or circuit-breaker activation. This prompt also assumes that repair is safe: the malformed payload is not adversarial, and the repair operation does not introduce fabricated data that could mislead downstream decisions. If the tool output is used in a regulated domain (healthcare, finance, legal), the repaired output must be flagged for human review before any action is taken.

Before wiring this prompt into a production harness, define a strict repair safety boundary. The prompt should be paired with a post-repair validation step that re-checks the output against the expected schema and a diff tool that logs exactly what was changed. If the repair prompt cannot produce a valid output after one attempt, the system should escalate to a human or fall back to a safe static response rather than retrying indefinitely. The next section provides the copy-ready prompt template you can adapt and embed in your recovery pipeline.

This prompt template is the core instruction set for a repair model. It receives a malformed tool response, the expected output schema, and the original tool call context. Its job is to produce a valid, schema-conforming payload without inventing data that wasn't present in the original malformed response. The template uses square-bracket placeholders for all dynamic inputs, making it safe to copy directly into your codebase, prompt management system, or orchestration layer.

codeCopy
You are a strict output repair system. Your only job is to convert a malformed tool response into a valid output that conforms to the expected schema.

## INPUTS
- Malformed Tool Response: [MALFORMED_RESPONSE]
- Expected Output Schema: [OUTPUT_SCHEMA]
- Original Tool Call Arguments: [TOOL_CALL_ARGUMENTS]
- Repair Constraints: [REPAIR_CONSTRAINTS]

## REPAIR RULES
1. Extract every recoverable field from the malformed response that matches a field in the expected schema.
2. For missing required fields, use the following strategies in order:
   - Infer from context in the malformed response if the inference is high-confidence.
   - Use a safe default if one is defined in the repair constraints.
   - Set the field to `null` and add an entry to the `repair_metadata.missing_fields` array.
3. For fields with incorrect types, attempt type coercion following these rules:
   - String to Number: Parse if the string is a valid numeric representation.
   - Number to String: Convert directly.
   - String to Boolean: `"true"`, `"yes"`, `"1"` become `true`; `"false"`, `"no"`, `"0"` become `false`.
   - Object to Array: Wrap in a single-element array if the schema expects an array.
   - If coercion fails, set the field to `null` and add an entry to `repair_metadata.coercion_failures`.
4. For malformed JSON, attempt structural repair:
   - Fix unescaped quotes, trailing commas, and missing braces.
   - If structural repair fails, treat the entire payload as a string and attempt extraction via regex patterns matching the expected field names.
5. Never fabricate data. If a value cannot be recovered, coerced, or defaulted, it must be null.

## OUTPUT FORMAT
Return a JSON object with exactly this structure:
{
  "repaired_output": <schema-conforming object>,
  "repair_metadata": {
    "repair_attempted": true,
    "repair_successful": <boolean>,
    "missing_fields": ["<field_name>", ...],
    "coercion_failures": [{"field": "<field_name>", "original_type": "<type>", "target_type": "<type>"}, ...],
    "structural_repair_applied": <boolean>,
    "confidence": "<high|medium|low>",
    "unsafe_repair": <boolean>
  }
}

## UNSAFE REPAIR DETECTION
Set `unsafe_repair` to `true` and `repair_successful` to `false` if:
- More than [MAX_MISSING_RATIO] of required fields are missing.
- The malformed response contains no recognizable fields from the expected schema.
- Repair would require fabricating values for fields marked as `"no_fabrication"` in the repair constraints.
- The malformed response appears to be an error message, stack trace, or HTML error page rather than a corrupted tool output.

## EXAMPLES
[REPAIR_EXAMPLES]

Repair the malformed response now.

Adaptation guidance: Replace [MALFORMED_RESPONSE] with the raw string or partial JSON returned by the failed tool call. [OUTPUT_SCHEMA] should be a complete JSON Schema or a structured description of every expected field, its type, and whether it is required. [TOOL_CALL_ARGUMENTS] provides the original request context, which helps the repair model distinguish between a malformed response and a valid empty result. [REPAIR_CONSTRAINTS] is a critical safety field: define which fields must never be fabricated, list acceptable default values, and set [MAX_MISSING_RATIO] (e.g., 0.3 for 30%) to trigger the unsafe repair flag. [REPAIR_EXAMPLES] should include 2-3 few-shot examples showing a malformed input, the repair constraints, and the correct repaired output with metadata. Before deploying, validate that the repair model's output passes your existing tool response schema validator. If the unsafe_repair flag is true, route the payload to a human review queue instead of passing it downstream.

The malformed tool response repair prompt is designed to sit inside a post-tool-call validation loop, not as a standalone chat interaction. When a tool returns a payload that fails schema validation, the application should catch the validation error, extract the raw malformed response and the expected schema, and feed both into this prompt. The model's job is to produce a repair instruction—a set of normalization, coercion, or reconstruction steps—that the application can then apply programmatically or use to guide a second model call. This prompt is a decision-support tool for the repair orchestrator, not a replacement for deterministic schema coercion logic.

Wiring pattern: The application should implement a repair_or_escalate function that receives the raw tool output, the expected JSON Schema, and any validation error messages. This function calls the repair prompt with [MALFORMED_PAYLOAD], [EXPECTED_SCHEMA], and [VALIDATION_ERRORS] as inputs. The model returns a structured repair plan containing: (1) a repair_strategy enum (COERCE, RECONSTRUCT, DROP_FIELDS, UNSAFE_TO_REPAIR), (2) a repaired_payload if safe, and (3) a confidence_score between 0.0 and 1.0. The orchestrator should gate on confidence_score: if below a configurable threshold (start with 0.85), escalate for human review instead of applying the repair. For UNSAFE_TO_REPAIR, always escalate. Log every repair attempt with the original payload, the repair plan, and the final outcome for auditability.

Retry and fallback integration: This prompt should be called at most once per tool invocation failure. If the repaired payload also fails validation, do not loop—escalate immediately. The repair prompt is not a retry mechanism; it is a one-shot normalization attempt. For transient failures like timeouts or 5xx errors, use a separate retry-with-backoff prompt from the Error Handling pillar. For cases where the tool consistently returns malformed responses, the fix belongs in the tool implementation or schema definition, not in repeated repair attempts. Wire the repair prompt into your observability stack: emit metrics on repair attempt rate, repair success rate, and escalation rate to detect systemic tool quality degradation early.

Model choice and latency budget: Use a fast, instruction-following model for this prompt (e.g., GPT-4o-mini, Claude 3.5 Haiku, or a fine-tuned smaller model if repair patterns are stable). The repair prompt adds latency to the tool call path, so set a strict timeout (500ms–2s depending on payload size). If the repair model times out, treat it as UNSAFE_TO_REPAIR and escalate. For high-throughput systems, consider caching repair strategies keyed by (tool_name, error_type, schema_version) to skip the model call for known failure patterns. Never apply a cached repair without re-validating the output against the current schema.

Safety and human review: In regulated or high-risk domains (finance, healthcare, legal), set the confidence_score threshold higher (0.95+) and require human approval for any repair that modifies field values, not just types. The repair prompt must never invent missing required data—if a required field is absent and cannot be derived from the malformed payload, the repair must fail with UNSAFE_TO_REPAIR. Implement a repair audit log that records every repair decision, the human reviewer if involved, and the final payload that was accepted. This log is essential for compliance reviews and debugging silent data corruption caused by over-aggressive repair.