How the design of an MCP server affects agent token usage

In the previous article, I tested whether an MCP server could reduce the output tokens agents need to edit Word documents. The MCP workflow used 28% to 51% as many output tokens as direct editing with OOXML or the Open XML SDK, depending on the agent and model.

While reviewing the experiment traces, I noticed that agents repeatedly performed the same sequences of operations. Opening a document required registration followed by inspection. A text edit could require registration, text lookup, and application of an edit plan.

In OfficeAgent.NET 0.5, I introduced two shortcut operations:

• open_document combines document registration and inspection;
• edit_document combines registration, text lookup, and application of an edit plan.

The shortcuts do not add editing capabilities or replace the lower-level tools. They provide a shorter path for common operation sequences.

I then ran an experiment to measure how this redesign of the MCP server affected agent token usage.

What was tested

The experiment compared two tool surfaces over the same OfficeAgent.NET implementation:

• Shortcuts: nine tools, including the two composite operations.
• No shortcuts: seven tools, with the composites and their guidance hidden.

Both conditions used the same prompts, Word document, execution engine, proxy, verifier, and logging path. Only the MCP surface advertised to the agent changed.

The shortcut condition also included two additional tool definitions and approximately 1,000 extra characters of server instructions. This increased the input context slightly, making it important to measure the complete trade-off rather than assuming that more tools would be more efficient.

Four models participated in the test:

• Claude Sonnet 5;
• Claude Opus 5;
• GPT 5.6 Sol;
• GPT 5.6 Terra.

Each model performed seven edits to the same Word contract, with three attempts per task and condition. The tasks covered tracked text changes, paragraph formatting, content-control filling, sentence insertion, table insertion, comments, and revision acceptance.

A separate Open XML SDK verifier checked the saved documents. All 168 completed attempts passed verification. Fifty-five launches that were blocked before a model attempt began produced zero tokens and were excluded from the analysis; they are not counted as task failures.

Each model used the same harness configuration in both conditions. Token comparisons were made within each model because the agent environments and usage reporting differ. The results should not be interpreted as a cross-harness or cross-vendor model ranking.

What happened

The clearest result was a reduction in MCP calls.

With shortcuts, every model reached a median of four MCP calls per successful attempt. Without shortcuts, the medians ranged from five to seven calls.

Across all completed attempts, the total number of MCP calls fell from 501 to 358-a reduction of approximately 29%.

The composite operations removed protocol steps that agents otherwise had to select and execute individually.

Output-token use also decreased

The median of the seven task-level shortcut/no-shortcut output-token ratios was:

• Claude Sonnet 5: 0.85x, approximately 16% fewer output tokens;
• Claude Opus 5: 0.92x, approximately 8% fewer;
• GPT 5.6 Sol: 0.96x, approximately 4% fewer;
• GPT 5.6 Terra: 0.90x, approximately 10% fewer.

For the two Claude models, the corresponding median task-level session-cost ratios were approximately 0.90x and 0.91x.

The token reduction was smaller than the call reduction. Shortcuts removed protocol steps, but they did not eliminate all reasoning around each edit. Their additional tool definitions and instructions also increased the input context.

The aggregate result was positive for every model, but not for every individual task. Each model had at least one task where the shortcut condition used more output tokens. With three attempts per comparison cell, the data supports a model-level aggregate conclusion, not a claim that every operation will always become cheaper.

Why the tool surface matters

An MCP tool contract shapes the sequence of decisions an agent must make.

Atomic tools provide flexibility, but they require the model to assemble common workflows one operation at a time. Composite tools move a stable sequence into the server and let the model express the same intent with fewer calls.

This trade-off is most likely to help when a shortcut:

• represents a frequent multi-call sequence;
• has a stable order and predictable behavior;
• preserves the validation and safety checks of the underlying operations;
• is easy for the model to select correctly;
• removes enough calls to justify its input-context overhead.

Adding shortcuts does not always help. Every additional tool consumes context and adds another choice. A composite operation should earn its place through adoption and a measurable improvement in calls, tokens, latency, cost, or reliability.

Practical implications for MCP design

A useful shortcut-design process is:

1. Identify repeated multi-call sequences in actual agent traces.
2. Introduce a composite operation without removing the underlying primitives.
3. Keep prompts, validation, and execution behavior identical in the experiment.
4. Verify that agents select the composite without task-specific coaching.
5. Measure correctness, calls, output tokens, input overhead, latency, and cost separately.
6. Evaluate aggregate results before drawing conclusions about individual operations.
7. Remove shortcuts that do not justify their context cost.

This produces a measured mix of atomic and composite tools rather than assuming that either a larger or smaller tool catalog is inherently better.

Conclusion

Composite MCP operations reduced the number of steps agents needed to edit Word documents.

In this test, agents adopted the shortcuts in every eligible attempt. Total MCP calls fell by approximately 29%, while median task-level output-token use fell by approximately 4% to 16%, depending on the model. All 168 completed documents passed verification.

The result supports a limited conclusion: for some Word-editing operations, a suitable MCP server can use fewer output tokens than direct agent implementation, and carefully designed shortcuts can reduce the remaining protocol overhead.

MCP does not make an agent token-efficient by default. The benefit depends on how much reliable procedural work the tool absorbs-and whether that benefit exceeds the context cost of exposing it.

For MCP designers, the practical question is which repeated tool sequences are stable and valuable enough to become one operation.

The project used in these experiments is available on GitHub: OfficeAgent.NET.