An AI tool result should give the agent enough evidence to choose its next action without forcing it to reread every record the tool touched. Keep exact values needed for decisions and follow-up calls, summarize relevant bulk information, and retain a usable path to the source material when more detail may be needed.
This reference proposes a field-level policy for tool responses. It does not recommend deleting the underlying records or using a universal token limit. The right response depends on the next task: a short answer may be enough for a status check, while reconciliation or editing needs exact identifiers and source details.
- 01Preserve action-critical fields.Identifiers, units, status and task revision may be necessary even in a concise result.
- 02Summaries need provenance.Keep the source, scope and a retrievable path to omitted evidence.
- 03Context is not storage.Removing content from the model input does not delete the authoritative record.
01 — Reference methodDesign for the next decision
Ask what the model must decide after the tool returns. If the next action is to choose a matching record, provide discriminating fields. If it must update the record, include the exact identifier required by the update tool. If it must explain a failure, preserve the error category and affected fields.
Anthropic’s tool-design guidance recommends meaningful context and concise or detailed response formats. It also acknowledges that technical identifiers remain necessary for some downstream calls. Read that as a task-dependent design choice, not a blanket instruction to strip IDs.
A hypothetical inventory lookup might return the requested item, available quantity, unit and record ID. Returning the entire warehouse export would add irrelevant material. Returning only “in stock” could omit the unit or variant that determines whether the user can actually use it.
02 — Reference methodChoose a policy for each result field
The table below is a proposed design reference. Keep exact means preserve the value needed for the next operation or decision. Summarize means produce a bounded representation with provenance. Fetch on demand means retain a usable locator. Exclude refers to the model context, not automatic erasure from storage.
The rows are conditional. A full document may be essential for a document-editing task, and a resource identifier may be unnecessary for a one-off explanation. Define the required downstream operation before applying the policy; do not turn the table into an inflexible global filter.
| Default treatment | Field class | Condition and reason |
|---|---|---|
| Keep exact | Operation identifier | Needed to inspect or reconcile the same action; pair with a human-readable label. |
| Keep exact | Resource identifier | Keep when a later tool requires it; avoid asking the model to reconstruct opaque IDs. |
| Keep exact | Terminal status | Preserve success, failure, partial or uncertain state rather than a generic summary. |
| Keep exact | Task revision | Identify which authorized request the result answers. |
| Keep exact | Value and unit | Keep decision-relevant quantities with currency, timezone or other units. |
| Keep exact | Error category | Retain the machine-actionable error or validation issue needed for the next step. |
| Summarize | Relevant record fields | Return the fields that answer the current question, with source identity. |
| Summarize | Repeated log messages | Group repetition while preserving representative lines and the complete-log reference. |
| Summarize | Search findings | Include relevant excerpts, source URLs and uncertainty; do not imply exhaustive coverage. |
| Fetch on demand | Long document | Keep a locator and relevant passage; retrieve more when the decision needs it. |
| Fetch on demand | Full query result | Store in an authorized artifact; include row count, filters and a retrieval path. |
| Fetch on demand | Binary artifact | Provide path, format and version; load the actual artifact for tasks needing its content. |
| Exclude from model context | Credentials | Use trusted execution storage; return a redacted status instead of a secret. |
| Exclude from model context | Irrelevant personal fields | Do not include data unrelated to the authorized task. |
| Exclude from model context | Duplicate raw payload | Avoid a second copy unless the protocol or a downstream consumer requires it. |
03 — Reference methodMake summaries explicit about what they omit
A useful summary states the question answered, the scope of the retrieval and the result. Include filters, source version or retrieval time when they affect the conclusion. If a query returned only its first page, the summary must not imply that no other records exist.
For long logs, preserve representative errors and a reference to the complete artifact. For retrieved documents, keep the passages that support the answer and enough source identity to open the same version. If the source cannot be retrieved later, be honest that a pointer alone cannot support follow-up work.
Anthropic’s context-engineering article describes selecting relevant context and retrieving information when needed. Our context reliability playbook covers the broader strategy. This reference focuses on the output contract that makes that strategy workable.
04 — Reference methodKeep protocol structure and application meaning aligned
The MCP tools specification dated June 18, 2025 supports structured content, unstructured content and resource links. A structured result is server-produced data; it is distinct from asking a model to generate schema-constrained output. Validate the actual returned data against the contract your application expects.
Use one authoritative status field and avoid a conflicting prose summary. If the structured result says an update failed, a friendly text block must not say it succeeded. Preserve whether the failure is a tool-execution error, a rejected argument or a connection problem so the next step can be appropriate.
The pinned MCP specification also recommends a serialized text representation of structured content for backward compatibility. Do not remove a protocol-required representation solely to save context. Deduplicate in the consumer’s model-input construction where supported, while preserving the tool response needed by other clients.
05 — Reference methodSeparate evidence, instructions and secrets
A retrieved page or document may contain text that looks like an instruction. Treat that as source content, not permission to change the application’s task. Selection can reduce exposure to irrelevant text, but a shorter payload does not make untrusted content safe.
Keep credentials in the trusted execution layer. A successful login operation can return a status and account label without returning its token. If the task needs personal information, include only the fields necessary for that authorized task and retain the appropriate access checks when retrieving more.
For voice frontends, OpenAI’s delegation guidance recommends keeping long records and full tool output in the backend. The voice layer needs concise relevant facts and status. Our background-tool voice guide applies that distinction to speaking while work continues.
06 — Reference methodTest what the compact result lets the agent do
Use the blank tool-result worksheet to list fields, their treatment, the downstream operation and the evidence retained. Compare a compact result with the current response on tasks that need exact identification, error recovery and follow-up detail. Do not evaluate token reduction alone.
Include a missing field, a stale version, a partial query and two similar resources. Check whether the agent requests more information when needed rather than guessing. A useful concise result can lead to another fetch; the goal is sufficient evidence for the task, not the smallest possible conversation.
The session-state responsibility reference helps decide where omitted records live. For implementation support, our AI transformation service can help define the tool contract and a bounded acceptance set. No context-selection experiment was run for this article.
Evidence and scope
- As-of date
- September 12, 2026. September 10 is the editorial allocation; current documentation was reviewed later.
- Method
- Primary documentation and research were reviewed for the cited distinctions. Tables, worksheets and pilot checks are Digital Applied proposed methods, not observed deployment results.
- Limitations
- No production API workflow, vendor benchmark or participant study was executed for this article. Documentation can change; verify the selected configuration before implementation.
07 — Next stepPut the decision into practice
Design for the next decision
Choose one noisy tool response and identify the next decision it must support. Preserve the exact fields that make that decision possible, then make every omission visible and recoverable where the task requires it.