Codex and Claude can edit Word documents without a dedicated document tool. They can open a .docx as a ZIP package, inspect its XML, write Python or C# to find the right node, change it, and save the package again.
That works, but the agent has to produce the editing toolset as well as the edit. Even a small request can turn into code for locating text across Word runs, preserving formatting, handling tracked changes, and keeping the document valid.
I wanted to know whether a Model Context Protocol (MCP) server that already implements that tools could reduce the output tokens an agent emits. I used OfficeAgent.NET, which exposes Word operations such as find, replace, format, comment, and accept revisions as tools. Instead of writing the XML manipulation, the agent can describe the change in a compact, structured tool call.
What I tested
Four agent and model combinations edited the same Word contract:
- Claude Code with Sonnet 5;
- Claude Code with Opus 4.8;
- Codex with GPT 5.6 Sol;
- Codex with GPT 5.6 Terra.
Each received the same seven editing tasks:
- change text with tracked revisions;
- format a paragraph;
- fill a content control;
- insert a sentence;
- insert a table;
- add a review comment;
- accept all revisions.
The benchmark compared two paths:
- Direct editing: the agent used the Open XML SDK or raw OOXML, with no document MCP.
- MCP editing: the agent performed the edit through OfficeAgent.NET.
The primary comparisons ran five attempts per task and condition. A separate verifier, built directly on the Open XML SDK, checked the saved document. The token figures below use medians from verifier-successful attempts.
This benchmark covers edits to an existing document only. Creating a document from scratch is a different workload and is not included.
What happened
Across the seven tasks, the median task-level MCP/direct output-token ratios were:
- Claude Code, Sonnet 5: 33%
- Claude Code, Opus 4.8: 28%
- Codex, GPT 5.6 Sol: 36%
- Codex, GPT 5.6 Terra: 51%
Lower is better. A result of 33%, for example, means that the MCP workflow used about one third of the output tokens of direct editing for the median task-level comparison.
Every one of the 28 task and model comparisons had a lower successful-attempt median when the MCP path was used.
The reduction was not identical for every operation. Accepting revisions and adding comments benefited more than some simpler formatting and insertion tasks.
That supports the proposed mechanism: the more document-specific procedure the tool absorbs, the less implementation code the model has to generate.
Token savings and cost savings are not the same thing
The output-token reduction was large. The session-cost reduction was smaller.
For Claude, the median task-level session-cost ratio was:
- 83% of direct on Sonnet
- 84% of direct on Opus
Two of the fourteen Claude task and model comparisons cost slightly more with MCP, even though they used fewer output tokens.
A plausible contributor is input overhead. MCP tool definitions add context, while fresh input, cache reads, cache writes, and output tokens are priced differently. This benchmark did not isolate the contribution of each component.
The recorded figures are model-session costs, not total cost of ownership. They do not include the cost of hosting, securing, or maintaining the MCP server. Codex did not report comparable USD costs, so I did not make a cross-agent dollar comparison.
What this result does not prove
This was a pilot:
- one Word document;
- seven supported editing operations;
- two agent environments;
- two models per agent;
- five attempts per primary comparison cell.
The direct baseline had the Open XML SDK available, but it did not have a mature reusable Word-editing abstraction. A team that already owns such an abstraction may see a smaller difference.
The verifier checked whether the requested OOXML change was present. It did not prove full visual equivalence or rule out every unintended change elsewhere in the document.
The result also does not mean that every MCP server will reduce tokens. The operation must be supported, and the agent must actually use the tool path.
Conclusion
In some Word-editing workflows, an MCP server can let agents emit fewer output tokens by moving document-specific implementation out of the conversation and into a reusable tool.
In this pilot, the median task-level MCP/direct ratio ranged from 28% to 51%, depending on the agent and model.
The practical lesson is not that MCP automatically makes agents cheaper. It is that a well-matched tool can remove a large amount of procedural work from the model.
For teams using AI agents to edit Word documents, that is worth testing against the operations they perform most often.
The project used in this benchmark is available on GitHub: OfficeAgent.NET
Top comments (0)