Grounding and citing tool results

The failure it prevents

In production: The final answer asserts numbers and quotes that no tool ever returned.

A tool returns a malformed page, an error payload dressed as data, or results for a different query than the one asked. The model, which cannot tell, builds a confident answer on top. By the time a human reads it, the wrong figure has a citation-shaped glow and no actual source behind it.

The drift version is subtler: the tool returned five sources, the answer cites the two that agree with its draft and silently improves a number in the third. Nothing in the transcript shows where any claim came from, so checking the answer means redoing the research.

How it works

Validate results before the model sees them. The MCP specification assigns this to hosts directly: validate tool results before passing them to the model. A result that fails its shape (missing fields, wrong types, an error body in a success wrapper) becomes a tool error the model must react to, not data it can cite.

Prefer structured output where it exists. MCP tools can declare an outputSchema, and structured results come back as structuredContent alongside the text form. Clients validate structured content against the declared schema, which turns "looks right" into "checks out". One documented caveat: tool errors do not return structured content, so the failure path needs its own handling.

Keep provenance welded to the payload. Tool name, retrieval time, and the exact query ride along with the results through the run, so the final answer can cite the source of each claim. Anthropic's research system does this with a dedicated CitationAgent pass over the gathered documents, and their tools guidance adds a smaller trick with real effect: meaningful, human-readable identifiers in results (readable slugs instead of opaque UUIDs) measurably improved their retrieval precision, because the model can reason about what it is holding.

Cite or drop. At write-up time, claims that cannot be pointed at a returned result are removed or flagged as inference. That rule, enforced by the harness rather than requested in a prompt, is the difference between a sourced answer and a plausible one.

When to use it

• Research, reporting, and any output a reader will repeat to someone else.
• Numbers, prices, dates, and specifications, where a small drift is a factual error.
• Tools returning third-party content that can be malformed, stale, or adversarial.
• Multi-source answers, where merging sources blurs which one said what.

When to skip or soften it

• Creative drafts and brainstorms, where grounding every sentence would strangle the exercise; mark the output as ungrounded instead.
• Internal scratch reasoning that never leaves the run; ground what gets published.

Tradeoffs

Validation rejects some usable results, and provenance bookkeeping adds tokens and code to every step. Citation passes cost an extra model call in systems that do them thoroughly. The trade is worth it exactly when the answer leaves the building: a reader repeating your figure to a third party cannot see your transcript, only your claim. Inside a throwaway prototype, the same machinery is ceremony.

Provenance envelope around a result (AgentsUse shape)

The harness wraps raw tool output with where it came from and when, validates the payload against the expected shape, and only then admits it to the context as citable evidence.

{
  "source_tool": "web_search",
  "retrieved_at": "2026-10-08T14:03:11Z",
  "query": "mcp elicitation accept decline cancel",
  "result_status": "validated",
  "items": [
    { "id": "mcp-elicitation-spec", "title": "...", "url": "https://...", "content": "..." }
  ]
}

Shape source: AgentsUse suggested shape; host validation duty per MCP specification 2025-06-18. Placeholders only; adapt names and numbers to your stack.

Implementation checklist

• Tool results pass a shape check in the harness before entering the model context.
• Tools with an outputSchema return structuredContent, and the harness validates against it.
• Every result carries tool name, retrieval time, and the query that produced it.
• Final answers cite the result behind each factual claim; uncited claims are cut or marked as inference.
• Identifiers in results are human-meaningful where the tool allows it (slugs over UUIDs).
• Malformed results surface as tool errors, never as citable data.

Related patterns and directory links