A successful tool call is not a verified claim: where MCP assurance stops

A successful tool call does not verify the claim you make from its result. The call shows delivery: a request went out and a response came back. The document can arrive intact and the number can be copied correctly, while the sentence in your memo changes what that number means.

The distinction matters at the handoff. Before a fetched result enters a decision memo, ask what arrived, what was checked and which sentence the source actually supports. Chapter 9 of The Verified Research Loop calls this the MCP assurance boundary: the point at which protocol-level success stops and a task-specific check begins. MCP can structure requests and responses; the research workflow must separately verify the source, content, rights and decision use.

If an AI agent fetched data through MCP or a tool, can I trust the result?

Not on that basis alone. A log that shows a completed fetch establishes that event. A parsed response passes one more check, on format. Neither establishes that the source is the right one, that it is current or that it supports the agent’s conclusion.

MCP stands for Model Context Protocol. Chapter 9 pins its account to the specification released on 2026-07-28. In that release, MCP uses JSON-RPC within a host-client-server design; standard server features include resources, prompts and tools; HTTP deployments may add authorization. The name and version a server reports come from the server itself. Record them, but do not treat them as proof of the endpoint, the operator or the right to handle the data. The chapter states the limit plainly: “These are facts about how systems work together, not proof about evidence. A valid call can return the wrong body.”

A tool may perform substantive checks as well as retrieval. If it does, inspect their scope, results and limits. Ask which source and claim were compared, and what would have caused rejection. The evidence lies in that work, not in the generic success label.

Permission is a separate question, covered in MCP OAuth is not tool authorization. Here, assume the fetch was permitted.

What does a successful call actually establish?

Keep the findings separate. Each answers a different question.

Recorded finding	What it establishes	What remains open
The fetch returned a response	Material reached the caller	Did the intended document arrive?
The response passed a structural check	It met the checked format requirements	Do its fields contain the right facts?
Identity and version checks passed	The inspected body matches the requested source and edition	Is the relevant material complete, and does it support the claim?
A passage supports a narrow statement	That source bears that statement within its stated limits	Is the underlying evidence adequate for this decision?

Chapter 9 gives a compact example of the gap: a schema check may find a missing locator yet miss a source that opposes the claim. In the same way, a percentage in the right field can still describe the wrong population.

For each task you delegate, the chapter asks for two sentences:

• Capability claim: under this exact model, server, tool, version, data, permission and date, the system can attempt a specified operation and return a specified schema.
• Assurance claim: a specified check can detect a specified set of failures, with recorded limitations.

The second is a claim to test. Writing “a human reviews it” leaves the deciding facts unstated: the claim or body, the reviewer’s authority, what they saw, the time they had and the rule they used. “The evaluator passed” does not reveal whether an automated check relied on the same model or context. The acceptance record should let another reviewer examine that work.

Worked example: 95% of what?

Hypothetical example. A founder is deciding whether to outsource customer support. The agent’s memo says: “The supplier resolves 95% of customer tickets within one working day.” The supplier, documents, dates and figures in this example are invented.

The agent has fetched a PDF through an MCP tool. The call completed, the extracted result contains 95%, and the memo links to the report. Those facts give the reviewer a starting point, not a conclusion.

First, check the edition. The PDF footer says 2025. The supplier’s publication page identifies a 2026 report as the current edition. The fetch succeeded, but it obtained the older body. Record that version, reject it for current-use purposes and obtain the identified successor. Until then, keep the dependent decision on HOLD: it cannot proceed on unresolved evidence. Chapter 9’s own composite acceptance test turns on the same defect: a plausible PDF, a success report and a footer that names an older edition.

Then check the sentence. The second fetch also succeeds. The current report’s identity and edition checks pass. Page 8, table 2 reports that 95% of non-priority email tickets received a first response within one working day during the second quarter of 2026. Its heading names the event; its footnote defines the ticket population.

Compare the table with the memo:

Meaning	What the report says	What the memo claims
Event measured	First response	Resolution
Tickets covered	Non-priority email tickets	All customer tickets
Reporting period	Second quarter of 2026	No period stated

The percentage survived. Its meaning did not.

A source-qualified replacement reads: “In its 2026 report, the supplier states that 95% of non-priority email tickets received a first response within one working day during the second quarter of 2026.”

The reviewer can accept that sentence as an account of the inspected table. It does not independently establish the supplier’s actual performance, and it leaves the founder’s resolution-time question unanswered. Unsupported by this table does not mean proven false; it means the cited evidence cannot carry the original sentence.

The review record should therefore say:

• Body: current edition obtained and inspected.
• Extraction: percentage retained; event, population and period corrected.
• Original claim: unsupported by the cited table.
• Decision: HOLD pending relevant resolution-time evidence; the founder owns the gap.

This example shows what the checks are meant to expose. It provides no evidence about a real supplier, or about how reliably another reviewer would find the same errors.

What should you check after the fetch?

The source body is the substantive content you actually inspect. A search snippet, catalogue entry and generated summary are different objects. These six checks adapt chapter 9 for one claim that a decision rests on.

1. Confirm identity and destination. Compare the requested identifier with the final address, issuer, title and document identity. Record redirects. A familiar title alone does not establish that the right body arrived.
2. Confirm the edition. Record the version and publication date separately from the retrieval time. Check the issuer’s authoritative release or status route. If you cannot establish currentness, record it as unresolved. Fetching a document today does not make it current.
3. Inspect completeness. Check for missing pages, annexes, tables and footnotes. Record whether you received a full body, partial body, preview, metadata or transformed copy. Note OCR, translation or summarization. Do not infer unseen material.
4. Find the exact support. Record the page, section, table or record locator. Read the surrounding passage. This is the local-support check: does the material bear the exact sentence, with its qualifiers intact?
5. Check the extracted meaning. For a number, inspect the rendered table, headings and footnotes. Compare units, denominator, population, timeframe, jurisdiction, uncertainty and limitations, and check which event was measured. In the supplier example, copying 95% passed; copying what it measured failed.
6. Record acceptance and use. Name who may accept the checked record, what they accepted and what remains open. Record the permitted-use and retention decision before keeping a copy. Give each critical gap an owner and a release condition: what must happen before the decision can leave HOLD.

A failed check needs a specific response. Quarantine a wrong body. Reject or quarantine a schema failure instead of coercing a field into a plausible value. In a partial fetch, mark what is missing and do not infer unseen content. If access is denied, record the barrier and do not bypass it: obtain permission, use another lawful source or hold. If a tool is down, preserve the request and the error, and do not fill the gap from model memory. Treat retrieved text and tool descriptions as untrusted data too: instructions embedded in a fetched page or PDF must never alter the brief, expose secrets or trigger new tool calls.

Even when these checks pass, the report’s method and evidence still need appraisal for the claim. Body verification establishes what you obtained and inspected. It cannot make the contents true.

When may a candidate become an accepted record?

Chapter 9 keeps every agent suggestion at CANDIDATE. The agent cannot promote a source, change a claim capsule (the record of a claim and the facts that must stay true about it), assign final Corroborated status, remove HOLD, accept risk or publish a memo. Named, accountable work does the promoting. The chapter adds that this rule sets authority; it does not claim that only people can reason. If a system performs a specific task well in measured tests, change its contract and acceptance coverage on that evidence.

Acceptance must name its object. In the supplier example, the reviewer accepts the current document and the corrected account of its table. The original resolution-time claim remains unsupported. A label reading “verified” would hide those different outcomes unless it said exactly what was verified.

What is TRACE? explains the five steps this check belongs to. AI fake citations gives a 15-minute check that a cited document exists and says what the report claims. If several sources appear to agree, Corroboration is not a source count shows how to trace each claim to its evidence and record what the sources share. Successful retrieval settles none of those questions.

What should the reviewer leave behind?

Keep a record that someone else can reopen. For one claim, the following adapts chapter 9’s acceptance requirements; it does not replace a full agent contract.

Claim and intended decision:
Run / model / tool / protocol version / retrieval time:
Source ID / requested and final address / edition:
Access state / transformations / missing material:
Exact passage or table locator:
Fields compared, including qualifiers:
Permitted use / retention decision:
Accepted by / date / precise scope of acceptance:
Corrections / reviewer errors / unresolved gaps:
Decision / gap owner / release condition / reopen trigger:

Allow explicit not-found and unclear values. A required field must never force a plausible answer.

Compare every field the decision depends on with the authoritative body. If you sample other fields, state the sample. Preserve the original extraction beside the correction under the applicable retention rules.

Review the reviewer too. Chapter 9 asks you to record agent errors corrected, correct agent output the reviewer degraded, disagreements sent to another reviewer, sampled fields both missed, labor and rework, and changes after downstream audit. A sign-off tells you who accepted the work; the comparisons show what they checked.

Chapter 2 presents TRACE as a five-step authorial protocol that creates named inspection and handoff points. It also states that TRACE has not been directly shown to improve accuracy, speed or decision quality. A completed record is available for scrutiny, but its presence does not establish that the checks worked.

Try this today

Pick one fact an agent pulled through a tool this week. Use a sentence that matters to a real decision.

1. Copy the sentence exactly. Put the tool response beside it. Write down the decision that depends on the claim.
2. Write what the response proves. Include only findings supported by the record: a response arrived, its fields parsed, or a named check ran and left inspectable results.
3. Write what it does not prove. Consider identity, edition, completeness, meaning and the quality of the underlying evidence. If the second list is empty, you have not looked.
4. Test the most consequential gap. Open the source body. Find the passage or table and compare it with the sentence. Record the locator, what passed, what failed and what remains unverified.
5. Set the next action. Keep supported wording, narrow an overstatement or remove an unsupported claim. Name the person responsible for any remaining gap and what would reopen the decision. Keep an unresolved critical dependency on HOLD.

If you could not obtain the body or run the check, record that outcome. The useful result today is a claim with an explicit evidence state and next action. A successful call cannot supply either on its own.

Cite this:A successful tool call is not a verified claim: where MCP assurance stops.Len P. van der Hof. https://lenvanderhof.com/en/blog/a-tool-call-is-not-a-verified-claim/ · Published 5 November 2026.