Tool Output Interpretation Prompt Template

This prompt is the critical translation layer between a tool's raw output and the user's screen. Use it when your AI system has received a response from an API, database, or function call and must now explain that result to a human. The job is to synthesize, not to summarize. The prompt forces the model to be faithful to the tool output, handle errors transparently, and never invent data the tool did not return. It belongs in any agent, copilot, or RAG pipeline where a tool call has already succeeded or failed and the next step is user communication.

Do not use this prompt to decide which tool to call; use it after the call completes. The ideal user is a developer or AI engineer wiring a tool-calling agent into a product. Required context includes the raw tool response, the original user query, and the tool's schema or description. Without this context, the model cannot ground its interpretation. The prompt is designed for single-turn interpretation, but it can be extended with conversation history for multi-turn copilot experiences.

Avoid this prompt when the tool output is already human-readable and requires no transformation, such as a simple status code or a direct display of a value. Also avoid it when the output requires deterministic formatting that is better handled by application code, like rendering a table or chart. In high-risk domains such as healthcare or finance, always pair this prompt with a human review step and an evaluation that checks for hallucinated data not present in the tool response. The next section provides the copy-ready template you can adapt for your own tools and schemas.

This template is designed to be pasted into your system, user, or assistant message after a tool call has been executed and its raw response string has been captured. It instructs the model to act as an interpreter, synthesizing the raw output into a clear, faithful, and context-aware natural language response for the end user. The template assumes you have already handled the tool execution and error catching at the application layer; its sole job is to bridge the gap between machine-readable output and human-readable communication.

textCopy
You are a precise tool output interpreter. Your task is to convert the raw response from a tool call into a clear, user-facing answer.

**Tool Called:** [TOOL_NAME]
**Tool Purpose:** [TOOL_DESCRIPTION]
**Original User Request:** [USER_QUERY]

**Raw Tool Response:**
```json
[RAW_TOOL_OUTPUT]

Instructions:

1. Synthesize the raw response into a natural language answer that directly addresses the user's original request.
2. Be faithful to the data. Do not add information, assumptions, or interpretations not present in the raw response.
3. If the raw response contains an error object or a failure status, clearly and calmly explain the failure to the user without exposing raw stack traces or internal error codes. Suggest a next step if possible.
4. If the raw response is empty, null, or indicates no results were found, state that clearly.
5. Format the final answer according to the following schema: [OUTPUT_SCHEMA]
6. Adhere to these constraints: [CONSTRAINTS]

Examples of Good Interpretation: [EXAMPLES]

To adapt this template, replace the square-bracket placeholders with your specific context. [TOOL_NAME] and [TOOL_DESCRIPTION] give the model essential context about the data's origin. [RAW_TOOL_OUTPUT] should be the exact stringified JSON or text response from your tool. The [OUTPUT_SCHEMA] placeholder is critical for production systems; replace it with a concrete description of the desired output format, such as a JSON schema for an API or a markdown structure for a chat UI. [CONSTRAINTS] should include rules like tone, audience, or forbidden phrases. Finally, provide a few [EXAMPLES] of good interpretations for your specific tool to dramatically improve output quality. For high-stakes domains, always route the final interpreted output to a human review queue before it reaches the user.

The Tool Output Interpretation prompt sits between raw tool execution and the user-facing response. It is not a standalone chat prompt—it is a processing step in a pipeline. The application must capture the raw tool output, the original user query, and the tool's schema definition, then assemble them into the prompt template before calling the model. This prompt should never be exposed directly to end users; it is an internal synthesis step that converts machine-readable tool responses into natural language answers, error explanations, or clarification requests.

Pre-processing requires three inputs: the raw tool output (which may be JSON, XML, plain text, or an error object), the original user query that triggered the tool call, and the tool's schema definition including its name, description, and expected return format. Sanitize the tool output before injection—strip internal identifiers, stack traces that expose infrastructure details, and any PII that the tool may have returned. If the tool output exceeds the model's context window, truncate it by keeping the most relevant fields based on the user's query, and append a truncation notice like [Output truncated. Full response available in logs with trace ID: abc123]. For error responses, extract the error code, message, and any retry hints before passing them to the prompt.

Post-processing must validate that the model's interpretation is faithful to the tool output. Implement a lightweight factuality check: extract any claims, numbers, or statuses from the model's response and verify they appear in the original tool output. If the model introduces information not present in the tool output, flag the response for review or regeneration. For high-stakes domains like finance or healthcare, route all interpretations through a human review queue before they reach the user. Log every interpretation with the original tool output, the assembled prompt, the model's response, and the validation result—this trace is essential for debugging hallucinations and improving the prompt over time.

Retry logic should be conservative. If the model returns malformed output or fails to produce a valid interpretation, retry once with the same prompt but add a stronger constraint like You must only use information present in the tool output. Do not invent details. If the second attempt also fails, fall back to a safe default: return a templated message such as The system processed your request but encountered an issue formatting the response. Please try again or contact support with reference ID: [trace_id]. Never expose raw tool output directly to users unless it has been explicitly designed as a user-facing payload. For latency-sensitive applications, set a timeout on the interpretation step and use the fallback message if the model does not respond within the threshold.

Model choice matters here. This prompt requires instruction-following and synthesis, not creativity. Use a model with strong JSON mode or structured output support if you need the interpretation in a specific schema. For cost-sensitive pipelines, a smaller model like GPT-4o-mini or Claude Haiku often suffices for straightforward tool output interpretation. Reserve larger models for cases where the tool output is complex, ambiguous, or requires nuanced judgment about what to surface to the user. Always version your interpretation prompt alongside your tool schemas—when a tool's output format changes, the interpretation prompt must be updated and re-evaluated before deployment.