MCP Agent Verification That Proves Every Claim's Source

MCP agent verification, as most teams practice it, asks one question of every answer: is this true? A second question matters just as much, and most suites never ask it: where did this come from? The two axes fail independently. An agent can state a refund timeline that is correct today while reading it from a cache populated last week. It can quote a support number that is right, pulled from a community MCP server a teammate installed and nobody vetted. A fact check passes both answers. An auditor should not.

This playbook covers the full loop: a decision grid for classifying failures, five provenance failure modes built into MCP architectures, a binding pattern that stamps each claim to the tool call that produced it, and eval additions that catch right-answer-wrong-source failures in CI. It closes with the question teams dread most: the grid says a shipped answer had a bad source. Now what?

Why a Correct Answer Can Still Fail

Most MCP agent verification suites grade one axis: factual correctness, whether each claim matches reality. Source correctness is a separate axis: whether the claim resolves to the specific tool result that produced it, whether that result is still current, and whether its server is trusted enough to back a user-facing statement.

The axes are independent because the truth of a sentence carries no information about its origin. Consider a pricing question. The agent answers "Seats cost $19 per user" and the number is right, so the eval passes. What the eval never sees is that the figure came from a stale mirror, from the wrong tool in a fan-out where two tools answered at once, or from a server the security team would not have allowlisted. Correctness-only scoring is structurally blind to this class of failure, because its scoring function never receives the origin. Nobody learns the pipeline depends on an untrusted mirror until the mirror is wrong, and then the incident review discovers the dependency in the worst possible way.

The blindness is fixable, and the fix is cheaper than most teams expect, but it has to happen at one specific place in the pipeline. First you need a shared vocabulary for what failed.

The Fact-versus-Source Decision Grid

Cross the two axes and you get four quadrants, each with a verdict, an owner, and a next action:

Quadrant	Verdict	Owner	Next action
Fact right, source right	Ship it	Approver	Log the pair as a regression baseline
Fact right, source wrong	Hidden failure, the riskiest cell in the grid	Agent platform team	Re-bind or regenerate the claim; add a wrong-source test to CI
Fact wrong, source right	Good tool, bad read	Model or product owner	Fix extraction and prompting; keep the source
Fact wrong, source wrong	Garbage in	Whoever granted server access	Quarantine the server; demote its tier

Run every failed eval and every user report through this grid. The fact wrong, source right quadrant routinely gets misdiagnosed as a tooling bug when the model simply misread a clean result, so teams waste days debugging infrastructure that works. The fact right, source wrong quadrant is where incidents hide, because nothing else in the pipeline catches it.

Take the pricing question from earlier. The eval passes because "Seats cost $19 per user" is true. Pull the provenance stamp and you find the figure resolved to a stale mirror of the pricing server rather than the live call, so the answer lands in fact right, source wrong. The grid then does what it was built for: the owner column hands the case to the agent platform team, whose next actions are to re-bind or regenerate the claim against the live pricing call, then encode the mirror-versus-live pair as a conflicting-source test in CI so the same landing fails the next run instead of shipping silently.

Track quadrant distribution over time, and give the tracking one specific alarm: alert when the fact-right-source-wrong share of failed evals rises between runs. Prompt tweaks move the fact axis; that share climbing usually means a dependency is rotting underneath a pipeline that still passes fact checks.

Five Ways MCP Architectures Lose Provenance

Provenance loss in MCP systems is architectural, not accidental. Five patterns do most of the damage.

Flattened Shared Context

Most clients concatenate tool outputs into a single context window. Once spans merge without per-call markers, attribution is lost at ingestion and cannot be reliably reconstructed afterward. The model's wording encodes what it read, not which buffer it read from, and string-matching heuristics break the moment two tools return overlapping content. Post-hoc attribution is guessing with extra steps.

Citation Drift Across Turns

In multi-turn sessions, claims outlive the tool results that produced them. In turn 3 the agent fetches the current plan price. In turn 9 the user re-asks, the agent paraphrases from conversation memory, and the citation quietly re-binds to a newer call, or to nothing. Each turn looks internally consistent, which is exactly why citation drift goes undetected.

Stale Tool Caches

A cache entry is a snapshot with a birthday it does not advertise. Cached results can outlive the data they copied while still looking fresh to the model and to your citation renderer. The stale tool cache fix is to make staleness detectable at answer time: every provenance stamp carries a fetch timestamp and a TTL, and answers assembled from results past their TTL get flagged or refreshed at render.

Untrusted Third-Party Servers

A server you did not write is a trust boundary, and its outputs are inputs to be validated, never an extension of the model's knowledge. Indirect prompt injection makes this concrete: a compromised server can return text that instructs the agent, complete with convincing in-band citations, so the agent asserts injected claims that look properly sourced. OWASP's agentic AI top 10 tracks exactly this class of risk for agentic systems. Source trust has to gate what reaches context, not just what gets cited at the end.

Parallel Call Merges

When an agent fans out to several tools concurrently, results can arrive in nondeterministic order and land in one merged block. If two tools answer the same question differently, the rendering layer often picks a citation by position, and position is not truth. The failure is timing-dependent, so it dodges unit tests and surfaces in production traces.

The common thread: every mode either loses the call-to-claim link at ingestion or lets it silently move afterward. The binding pattern below attacks both.

Provenance Binding, Stamping Claims to Tool Calls

You do not need to invent identifiers, because MCP already provides the handles. tools/call is a JSON-RPC request, so its request id pairs each call with its result at the protocol layer, and the MCP tools specification defines the call and result schema. Model APIs expose their own handles: Anthropic's tool use docs describe tool_use blocks, each carrying an id. The provenance binding pattern extends an existing handle instead of adding a parallel tracking system that can drift out of sync.

The pattern has four moves:

1. Tag at ingestion. Middleware wraps each tool result before it enters context: call id, server name, tool name, an arguments hash, fetch timestamp, and TTL. Visible per-call markers go into the context text itself, so the boundary between one result and the next survives flattening.

2. Stamp at generation. While the originating call is still addressable in context, extract claim-level bindings: a claim id, the origin call id, and the span of the result that supports it. The model can emit markers directly, or a post-pass can extract them. Either way, this is the moment the binding must happen.

Bind while the originating call is still addressable. After flattening, archiving, or re-fetching, you are reconstructing, and reconstruction is not verification.

1. Resolve at render. Citations resolve against the stamped tool results, never against a live re-fetch. A re-fetch can diverge from what the model actually read, which quietly reintroduces misattribution at the last step.

2. Persist the stamp. Store it alongside the answer. Tracing an agent claim to its MCP tool call becomes a lookup, not an investigation.

A stamp is small. A minimal schema:

{
  "claim_id": "clm_01h9",
  "claim_text": "Premium refunds process within 5 business days",
  "origin": {
    "tool_call_id": "req_8842",
    "server": "policy-mcp.internal",
    "tool": "get_refund_policy",
    "arguments_hash": "9f3ab2",
    "fetched_at": "2026-10-02T14:03:11Z",
    "ttl_seconds": 3600
  },
  "span": { "block": 0, "start": 41, "end": 96 },
  "render": { "marker": "[2]", "policy": "require_tier_gte_1" }
}

Claims that cannot be stamped are, by policy, unsourced. Strip them, downgrade them, or flag them, but never let them render with a citation they did not earn. That single rule closes the fake-receipt failure mode, injected citations included.

MCP Agent Verification Metrics That Catch Wrong Sources

Standard checks grade the fact axis. Groundedness evaluation, such as the RAGAS faithfulness metric, scores whether each answer claim is supported by the context provided, which makes it a necessary floor. It is not sufficient here, and the reason matters: faithfulness is scored against context as a whole. With flattened context, a claim can be fully faithful to the merged text while being bound to the wrong call. LLM citation verification usually asks whether a document supports a sentence; call-level verification asks whether that document is the one that produced the sentence. You need both.

Three cheap agent evaluation metrics close the gap:

Citation Precision

The share of answer claims that resolve to a real tool result whose content actually supports them. This measures your binding machinery itself, before you argue about any facts.

Wrong-Source Rate

The share of factually correct claims whose stamp points at a wrong, stale, or below-tier origin. This is the direct eval for right-answer-wrong-source failures, the quadrant your fact checks pass.

Conflicting-Source Test Cases

Seed the environment with two servers that return different answers to the same query. Assert the agent cites the higher-tier server and surfaces the conflict rather than averaging. These cases are deterministic, cheap to author, and they fail loudly.

None of these require new infrastructure once stamps exist. They are queries over data you already persist.

Trust Tiers for Third-Party MCP Servers

Untrusted MCP server risk mitigation starts with tiering and deny-by-default. Model Context Protocol security guidance in the MCP security best practices recommends explicit trust decisions and allowlists, and treats third-party servers as untrusted. The harder line is this playbook's own synthesis: server outputs are context inputs to validate, never an extension of the model's knowledge, and tiering is what makes that distinction enforceable. A working rubric:

Tier	Covers	Gates	May back user-facing claims?
T0 First-party	Servers you build and run	Response contracts, schema validation, tests	Yes, with stamps
T1 Vetted external	Paid or contracted APIs	Allowlist, response contract, monitoring	Yes, stamped and labeled
T2 Community	Public community servers	Sandbox, no sensitive data, periodic review	Facts only, attributed; never authoritative claims
T3 Unknown	Anything unclassified	Deny by default	No

Two operating rules keep the rubric honest. First, the tier decides at render time, not just at review time: a T2 result can enter context as background, but the render policy refuses to let it back a definitive claim. Second, re-review on a schedule, because server code and ownership change under you. An allowlist reviewed once is an allowlist rotting quietly.

A Minimal Rollout Plan

Sequenced so every phase produces value on its own:

1. Day one, about thirty minutes. Add middleware that wraps every tool result with its call id and fetch timestamp before context assembly. Change nothing else. You now have ground truth for everything that follows.
2. Week one. Shadow-run citation precision over your existing eval set to get a baseline. Expect an uncomfortable number.
3. Weeks two and three. Add wrong-source rate and conflicting-source cases to CI, with thresholds that gate merges once stable.
4. Production. Enforce tier rules at render, and emit the tool call id, server, and tool name on your tool call spans following OpenTelemetry's GenAI conventions, so agent observability dashboards show which call produced each result, not just how long calls took. For the audit story, the NIST AI Risk Management Framework supplies governance language for third-party components you depend on but do not control.
5. When the grid flags a shipped answer. Re-fetch from a trusted origin. If the claim survives, re-stamp and correct the record. If it does not, notify the user and fix the answer. Either way, the case becomes a new conflicting-source test.

That last step answers the question this piece opened with. An MCP agent's answer is only as verifiable as its weakest tool call, and verifiability is decided at the moment the claim is generated. Stamp provenance at the tool-call boundary, and every audit, incident review, and eval run afterward becomes arithmetic. Skip it, and you are left reconstructing what the model read from prose it already flattened.