PRODUCTION SCENARIO
An MCP database inspection server's query tool returns 45,000 rows, roughly 18 MB of JSON, when an agent inspects a production access log. Passing that back saturates the context and the agent stops making progress. The agent's job is to characterize the whole log rather than read it in order, any individual row may turn out to matter later, and the client can fetch resource URIs the server hands it.
How should the tool return a result of that size?
Answering here is anonymous. Nothing is saved unless you sign in.
Show answer and explanation
Answer: Write the rows to storage and return the count, the schema and a resource link
A tool may return a resource link, a URI the client can fetch, so the rows live outside the context while the result still carries enough shape - a count, the column types, a few samples - for the agent to decide what to ask for next, and every row stays reachable. A cursor is the right design when an agent consumes rows in order and can stop early, which does not help a job that has to characterize all 45,000. An embedded resource is worth it when the payload is small enough to inline, and 18 MB is the case where it is not. Server-side aggregates are the answer when only summary figures are ever needed, and this investigation may have to pull specific rows.