Check Whether Your Agent Retrieved the Whole Answer

Quick answer: Before an agent concludes that a document lacks a requirement, establish which version it retrieved, how much survived extraction, and which sections it searched. A successful fetch alone cannot support a claim about the whole source. Keep missing coverage visible and use a bounded recovery step.

An agent reads an API guide and reports that requests have no expiration rule. Its answer includes a link, a quotation, and a confident explanation. The missing detail is that it reviewed only the beginning of the guide.

This failure can be difficult to spot because the quotation may be accurate. The problem lies in the scope of the conclusion. Finding a sentence establishes that the sentence exists. Failing to find one establishes much less unless the search covered the relevant material.

The workflow below uses a fictional twelve-section guide. Its records and outcomes are illustrative, rather than results from a running retrieval system.

Follow the document through each boundary

Separate four questions that are easily compressed into “the tool worked”:

Boundary	Useful question
Source selection	Did we choose the right document, revision, and representation?
Transfer	Did we receive the intended response completely?
Extraction	Did headings, tables, notes, and other relevant material survive conversion?
Model delivery	Did the agent receive every selected section, with its identity and limits?

HTTP already distinguishes some forms of partial delivery. A 206 Partial Content response can successfully supply one or more requested ranges. Its success concerns that range request. It does not assert that the client has assembled the whole representation. RFC 9110's range semantics define this distinction.

Even complete delivery of an HTML response leaves the extraction question open. Check whether the material you need lives in a linked appendix, a downloadable specification, a table, or another document. Define the source boundary before evaluating coverage.

A tool can also return several content items. The MCP tools specification dated 2025-11-25 permits multiple items in a tool result. That protocol structure supplies no evidence that a particular application's later transformation preserved every item. Inspect the result at the boundary where the agent consumes it.

Record coverage in units that have meaning

For the fictional guide, imagine the question is: “Does a continuation token expire?” A compact record might look like this:

{
  "source": "Example API guide",
  "revision": "edition-4",
  "representation": "official plain-text export",
  "expected_sections": 12,
  "retrieved_sections": [1, 2, 3, 4],
  "missing_sections": [5, 6, 7, 8, 9, 10, 11, 12],
  "coverage": "partial",
  "question": "Does a continuation token expire?"
}

The expected count needs a source of its own, such as a verified contents list. If the count is unknown, record it as unknown. Inventing a denominator makes a progress percentage look more convincing without improving the evidence.

Choose units appropriate to the document. Page numbers can work for a fixed PDF. Section identifiers can work for a versioned specification. Byte intervals can work for a particular stored representation. Keep those units distinct: a character count from extracted text is not directly comparable with compressed transfer bytes.

Record a digest when you need to identify a saved artifact later. A digest identifies those bytes; it does not establish that they contain everything the source intended to publish. Preserve both identity and coverage.

Let the gap determine the next retrieval

In our example, the visible contents list places pagination in section 8 and token lifecycle in section 9. Reading sections 1–4 does not justify an answer about expiration.

The next step is small: retrieve sections 8 and 9, including any referenced qualifications. Suppose section 9 says tokens expire after a stated interval. The agent can now answer the specific question and cite the relevant passage without reading every unrelated endpoint example.

If the task instead asks whether the guide contains any retention requirement, the coverage demand is wider. Inspect the complete relevant source, including appendices and incorporated documents, or narrow the conclusion to the sections actually reviewed.

This gives retrieval a stopping rule. Stop when the evidence supports the requested conclusion. If the remaining source is unavailable within the permitted budget, report the gap and its effect on the answer.

Use a bounded fallback

For a long authorized source, downloading a stable copy can make repeated inspection easier. Keep it in a task-owned location, record where it came from, and search or read sections from that artifact. Avoid mixing chunks from different revisions as if they formed one document.

Set transfer time, redirect, and size limits appropriate to the source. The curl manual documents controls including --max-time, --max-redirs, and --max-filesize; their detailed behavior depends on the installed version and transfer options. A stopped transfer should leave the record marked incomplete.

Downloading is useful only when access is authorized and the chosen representation contains the needed material. It does not grant access to hidden sources or repair an extraction problem automatically. If a table is unreadable in text, inspect a suitable rendering or record that the table remains unreviewed.

For range retrieval, check the returned range metadata and representation identity before combining pieces. A request for a range is not proof that the response supplied that range. RFC 9110 also describes the conditions for combining partial representations.

Match the strength of the answer to the search

Consider three possible conclusions:

• “Section 9 states that continuation tokens expire.” A located passage can support this, subject to its context and version.
• “The phrase ‘continuation token’ does not appear in the stored text.” This needs a complete search of that specific artifact.
• “The API has no token expiration rule.” This needs much broader evidence, including alternate terminology and other authoritative sources within scope.

A literal search can miss “cursor,” “validity window,” or a rule expressed through a referenced definition. After finding likely sections, read the surrounding material and follow relevant cross-references. Preserve the distinction between a missing string and a missing requirement.

When coverage remains partial, a useful answer is specific: “I found no expiration rule in sections 1–4. The token lifecycle section was not retrieved, so I cannot determine the rule from this result.” That tells the next reader what remains to do.

Keep a short retrieval review record

Before accepting a research answer, check:

• The source and revision match the question.
• The record identifies the representation being inspected.
• Missing pages, sections, blocks, or ranges are explicit.
• Extraction has preserved the content relevant to the conclusion.
• The fallback has a finite scope and records unsuccessful retrievals.
• Negative claims say exactly which material and terminology were searched.
• Citations lead to evidence that supports the stated claim.

These checks fit naturally into a tool contract: completeness and recovery information belong beside the returned content. They also improve an agent knowledge base, because a saved conclusion can retain its source boundary and unresolved gaps.

Start with the next “the documentation does not mention this” answer you receive. Ask for the source version, coverage, and search scope. Those three details often determine whether the answer is ready to use or needs one more targeted read.