A building-inspections search tool can match thousands of historical inspection records for a busy commercial corridor, and returning every field of every match would overwhelm the agent's context. What payload design fixes this?
Select an answer to reveal the explanation.
Short Explanation
A search engine hands you titles and snippets, then lets you click into the one you want. Return identifiers and summaries first, full detail only on request.
Full Explanation
A tool's response shape is a context-budget decision. A building-inspections search across a busy commercial corridor can match thousands of records, yet the agent almost always needs to identify a handful worth examining rather than read every field of every match. The payload should be sized for that first step, not the last one.
Returning lightweight identifiers plus a few key summary fields per match keeps the search response small enough to reason over, while a separate detail-fetch tool keyed by record ID makes the full document available on demand. The agent spends context in proportion to what it actually inspects, and the two-stage shape mirrors how the task is really performed.
Returning every field of every match floods the window and buries the relevant record in noise, which is the problem being solved; silently truncating to five matches leaves the agent believing it has seen everything, turning a size limit into a false claim about the corridor's inspection history; returning only a total count with no path to any record makes the tool useless for the actual goal of examining specific inspections.
Exam caveat: when truncation is unavoidable, say so in the payload—report how many matches were omitted and how to page or refine—so the agent can narrow the query instead of working from a partial view whose edges it cannot see. Operational check: query a corridor with thousands of matches and confirm the response states the total, returns bounded summaries, and that a follow-up detail call by ID returns the full record.