PATH COMPLETION0 / 45 STEPS (0%)
BACK TO LEARNING PATHTRACK 03: Context Engineering
Step 5 of 6 in this track · 7 min

Managing tool output

People optimise their prompts and ignore tool results. It is nearly always the wrong way round. A prompt is a few hundred tokens. One unfiltered command can be tens of thousands.

The usual offenders

Reading whole files. A 2,000 line file is roughly 20,000 tokens, and it stays in context for the rest of the session.

Unfiltered command output. npm install produces hundreds of lines nobody needs. A full test run prints every passing test to tell you about one failure.

Recursive listings. ls -R in a project with node_modules can bury everything else in a single call.

Verbose API responses. A REST endpoint returning fifty fields when the agent needs two.

Fixes that work

Ask for ranges. Read lines 40 to 90, not the file. Most harnesses support offset and limit on reads.

Filter at the source. npm test 2>&1 | tail -30 gives the failure without the passing noise. grep -n "pattern" file beats reading the file and searching in the model's head.

Exclude the obvious. Keep node_modules, dist, .git, and build output out of searches. A good search tool does this by default; check that yours does.

Prefer targeted tools. A search tool that returns matching lines with line numbers is dramatically cheaper than a read tool pointed at the same file.

The rule of thumb

Before running something, ask roughly how many lines it will produce. If the answer is more than about a hundred and you only need a few, narrow it first.

This is not premature optimisation. It is the difference between a session that stays sharp for an hour and one that degrades in twenty minutes.

Tool definitions count too

Every connected tool contributes its name, description, and full parameter schema to every request, whether or not it is used.

Connect ten MCP servers and you pay for ten schemas on every turn for the whole session. Connect the ones the task needs. This is the easiest saving available and almost nobody makes it.

When output is genuinely large

Sometimes you do need to process something big: a long log, a large dataset, a lengthy document.

Delegate it. A subagent reads the whole thing in its own context and returns only the conclusion. The main conversation gets the answer without the raw material.

Measure it

If a session feels sluggish or the agent starts forgetting, look at what is actually in the context. It is almost always a tool result you did not think about, and it is almost always removable.