MCP Tool Output Too Large? A Reversible Path to 76% Fewer Normal-Path Tokens

An agent only wants one error code from a log.

Before it can search the log, it receives the names, descriptions, and parameter schemas of more than a dozen tools. The tool then returns the complete log. The useful error code may be only a few characters long, but the model must read thousands of lines to reach it.

This overhead becomes difficult to ignore as an MCP setup grows. The tool catalog consumes context before the work begins, and the full result consumes more context after the work is done.

Truncation looks like the easiest fix. If the missing section later matters, however, the agent may call the tool again. Repeating a search or file read may only add latency. Repeating a tool that sends email, creates a ticket, or writes to a database can create a second real-world action.

Useful MCP token optimization therefore has to preserve three properties.

Deliver a full tool schema only when the task needs it.
Execute the selected upstream tool at most once per request.
Allow a shorter first result while keeping the original result exactly recoverable.

MCP Slim Guard separates tool discovery, upstream execution, and result delivery. Its compact result is a recoverable view of the original output rather than a model-generated guess.

Which part should you optimize when MCP tool output is too large?

Start with the way the task consumes data.

Many tools, but only one or two per task: use progressive discovery so the entire schema catalog does not enter context in advance.
Large results, but tasks usually need a small section: save the original result, deliver a compact view, and recover only the required section.
The task must read every row: direct delivery is often cheaper than paging through a recovery interface.
The tool has side effects: recovery must not re-execute the upstream tool.

The useful question is how much of the original data the task eventually reads. The compression percentage follows from that answer.

One MCP call creates two token costs

The MCP tool flow is straightforward.

A host obtains tool definitions through tools/list. The model uses the name, description, and input schema to select a tool, then invokes it through tools/call. The MCP Tools specification allows text and structured tool results, and it lets a server provide an output schema that clients can validate.

Two forms of overhead become visible as the system grows.

The catalog arrives before the model selects a tool

Sending every schema is convenient when a server exposes three tools. With thirty or three hundred tools, the catalog becomes a recurring context cost.

One task in Slim Guard's public 24-task fixture only searches a product catalog and returns three records. The baseline still delivers definitions for all 12 tools first. That tools/list response contains 5,909 characters, or 1,380 tokens with o200k_base.

The task calls one tool. The other 11 schemas still enter the model context.

The model needs one answer but receives the whole result

After tool selection, a log, search result set, long document, or large JSON response may contain thousands of lines. The model may need only three records whose status is failed, but the full result has already become part of the conversation history.

Both costs follow the same default: deliver everything now because it may be useful later. Changing the delivery time lets the current task receive what it needs first and request the rest only if that need becomes real.

Four ways to reduce MCP tokens solve different problems

These approaches work at different layers and can be combined.

Connect fewer servers

If a session only needs files and Git, disabling unrelated systems is the cheapest and easiest optimization to reverse.

It depends on advance knowledge. General agents, enterprise workspaces, and long sessions cannot always predict the next required tool.

Discover tools on demand

Anthropic's Code execution with MCP describes two relevant patterns. Tools can appear as explorable code files, or a search_tools-style entry point can load only the definitions needed for the current task.

Slim Guard's Compact and Extreme modes use progressive discovery. The host initially sees find_tool, call_tool, and read_result. A tool search returns at most three matches and the complete original schema of each match.

The schema remains complete. It simply appears when the task requires it.

Filter results inside a code execution environment

When an agent has a secure code sandbox, a large result can remain in that environment while code filters or aggregates it. Processing a 10,000-row table this way is often more natural than making the model read each row.

The operator also inherits sandboxing, resource limits, permission isolation, and monitoring. Model context becomes smaller while harness complexity grows.

Keep delivery reversible

Some hosts still need ordinary MCP calls, and the team may not want to operate a code execution environment. Reversible delivery fits when most tasks use only a small part of each result.

Slim Guard stores an immutable snapshot before any lossy first delivery. It then returns a compact view and a result_ref. The agent can search or page through the local snapshot with read_result; the upstream tool does not run again.

Disabling unrelated servers controls configuration growth. Progressive discovery shrinks the tool catalog. Code-side filtering handles complex data processing. Reversible delivery provides a smaller first result without giving up exact recovery.

Call constraints have to hold before compression begins

A proxy that only shortens results is difficult to trust with write-capable tools. Slim Guard first constrains the call path.

Each call_tool can resolve only an authorized tool. Slim Guard validates arguments against the original schema, forwards them unchanged, and executes the selected upstream tool at most once. Invalid arguments fail locally, before the request reaches upstream.

Authorization, policy, and tool-resolution failures close the call path. If Slim Guard cannot confirm that a tool may run, it does not invoke the tool.

After an upstream tool returns successfully, a projection, snapshot, observation, or audit failure causes the delivery layer to return the exact upstream result. The optimization can exit without losing the valid result.

Audit records exclude credentials, call arguments, result bodies, and private capability references. They record the path taken without creating another copy of sensitive content.

This contract covers tool access and result delivery. Network isolation, secret management, human approval, upstream permissions, and code sandboxing remain separate responsibilities.

Where does the 76% figure come from?

The public August 6, 2026 three-mode, 24-task evidence contains 12 deterministic tools and 24 English and Chinese tasks.

The report uses o200k_base and counts each prompt plus every model-facing MCP tools/list and tools/call request and response. All 24 tasks follow a successful path, with one upstream execution per task.

Mode	Normal-path tokens	Reduction from baseline
Baseline	71,388	0
Native	39,521	44.64%
Compact	16,983	76.21%
Extreme	16,478	76.92%

Native preserves the original names of authorized host tools and mainly tightens result delivery, so catalog cost remains. Compact reduces discovery to three entry points. Extreme uses a shorter first delivery for eligible large results.

The 76% in the title is the normal-path difference between Compact and the baseline.

This is a deterministic successful-protocol replay. No model selects the tools. The benchmark does not measure answer accuracy, provider caching, pricing, or the rest of a real session. The 76% describes model-visible protocol tokens in this fixture, not a guaranteed billing discount.

A counterexample defines the useful boundary

The 100-tool, 8,000-row stress fixture deliberately enlarges both catalog and output. Direct delivery uses 352,157 tokens. On the normal path, Compact uses 1,451 and Extreme uses 1,134, reductions close to 99.7%.

The test then forces the agent to read all 8,000 rows.

Compact requires 50 read_result calls and reaches 687,741 protocol tokens. Extreme reaches 687,424. The recovered hashes exactly match the original result and the upstream tool still runs once, but token use approaches twice the direct path.

Exact recovery has a cost. Unread content creates the net saving. When a task eventually consumes every row, direct delivery is usually cheaper.

Finding an error code in a log, selecting three sources from search results, or looking up one object in a large JSON response fits on-demand delivery. A full migration, complete audit, or row-by-row transformation belongs in a code execution environment or another deterministic program.

When is Slim Guard worth considering?

The fit is strongest when:

a host connects many tools but each task uses only one or two;
tools often return logs, long documents, search sets, or large JSON objects;
most tasks read only a small part of each result;
upstream tools have side effects and recovery must not rerun them;
the team wants authorization, original-schema validation, and an audit boundary.

Direct MCP is sufficient when there are only a few tools and results are short. Paging adds cost when every task consumes the full result. Teams with a mature code execution layer may prefer to filter and aggregate data inside a sandbox. Current Slim Guard recovery references also belong to the current runtime generation; durable cross-runtime recovery needs a separate design.

If tool catalogs or oversized results are slowing down your sessions, start with the Slim Guard product page, then inspect the source, three-mode benchmark, and recovery evidence on GitHub. The MCP Slim Guard Alpha launch note retains the earlier release and host context.