Keep the information that lets an agent make the next decision and recover the evidence behind it: stable identity, relevant content, source and version, result scope, and a clear path to omitted material. Trim redundant and irrelevant fields before cutting the conditions that change a passage's meaning. When a response is incomplete, say how it is incomplete.
A short search response can be more useful than a large one. It can also be misleading if shortening removes a seven-day exception from a thirty-day retention rule. The target is enough evidence for the decision, with explicit limits on what was returned.
Separate the tool's result from retrieved content
The tool controls the response envelope: whether the request succeeded, the query applied, pagination, and which fields were omitted. A document inside that response controls none of those facts. Its text remains source material, including any instructions it happens to contain.
The MCP 2026-07-28 tools specification supports structured results and output schemas. It distinguishes server-produced structured content from schema-constrained model generation. A transport schema can make the envelope predictable; it cannot make retrieved prose authoritative.
For an application search tool, a useful result might contain:
{
"query": "export",
"items": [{
"id": "p-17",
"title": "Export retention",
"revision": "r4",
"source": "docs/policy#trial",
"text": "Standard exports remain for 30 days. Trial exports remain for 7 days."
}],
"returned_count": 1,
"total_count": 2,
"has_more": true,
"next_cursor": "opaque-continuation",
"text_truncated": false
}These fields are an original application contract, not mandatory MCP fields. Only return a total count if the service actually knows it; distinguish an estimate from an exact count. The continuation token must be one the tool can honor.
Trim fields according to the next action
Suppose the backend returns an object ID, title, revision, source, text, internal debug data, repeated account labels, and presentation markup. To answer a retention question, the first five fields are useful. Debug data and repeated chrome usually are not. To perform an authorized update afterward, the stable ID and revision become essential.
Anthropic's tool-design article discusses meaningful response content, targeted search, pagination, filtering, and explicit truncation. The design here applies those ideas to a policy-search envelope, rather than adopting a universal response-size limit.
Selection is preferable to arbitrary clipping when the tool can identify the relevant field or section. Let the caller narrow by document, section, date, or query. Provide a detail read for the full item. If the tool emits a summary, label it as a summary and retain a route to the original passage.
Do not remove a technical identifier simply because a human-readable name looks friendlier. Names can collide or change. Return both when the next operation needs exact identity and the reader needs understandable context.
Distinguish pagination from text truncation
Pagination limits the set of returned items. Truncation shortens an item or an overall response. A response can be paginated without truncating any document text, and a single-item response can still contain a truncated passage.
Use separate indicators. has_more: true tells the caller more items are available under this query. text_truncated: true should identify the affected item and a supported way to retrieve the missing range or full section. Neither should be inferred from whether the response happens to end with an ellipsis.
Continuation also has a lifetime. A cursor may expire, depend on the original filters, or traverse a dataset changing between requests. Document those behaviors. Do not promise a snapshot merely because the token is opaque. If a cursor expires, return a clear recovery path and enough query identity to avoid accidentally restarting a different search.
What the local response exercise preserved
Our Python fixture started with two synthetic records containing 1,500-character debug strings. It returned one record per page, removed the debug field, and kept the complete short text, stable IDs, revisions, and source locations.
Four checks passed: the first page indicated continuation, the second ended it, traversing both pages recovered each record once, and the trial exception survived while debug fields disappeared. The two original records serialized to 3,332 bytes; the two envelopes together serialized to 570 bytes under the fixture's JSON encoding.
Those are byte counts for contrived data, not token counts, latency measurements, or measured model savings. The fixture uses a static list and an integer offset as its continuation implementation. The public contract above uses an opaque token because a production service should own continuation semantics. No backend, MCP client, or model was exercised.
The useful result is preservation, not the percentage reduction: a caller can identify the record, read the exception, and obtain the remaining result without guessing.
Test what a shorter result makes impossible
Review a response by asking which decisions it supports. Can the agent distinguish two identically named records? Can it tell which revision it saw? Can it tell whether “no results” means a complete search, a permission filter, or a failed request? Can it recover the footnote that changes the answer?
Include large results and failure cases in tool evaluations. A malformed filter should not silently become an unrestricted search. An upstream failure should not look like an empty result. A summary should not claim that omitted records were examined.
Context compaction preserves a task across a reduced conversation. Tool-response design works earlier: it determines which evidence enters the conversation in the first place. Information removed at this boundary may never be available for a later handoff to preserve.
Keep the envelope concise and the evidence recoverable. When the next action needs more detail, make that detail reachable through an explicit, authorized read rather than asking the model to reconstruct what was cut.
Documentation and fixture date: October 28, 2026. All records are synthetic; no production data, token benchmark, or remote tool operation was used.
