These three write Word files and almost nothing else about them is the same. @docx-mcp/docx-mcp is a document builder: you hand it a validated JSON document tree and it renders it, with images, syntax-highlighted code blocks and page control. @usejunior/docx-mcp is an editor for documents that already exist, with tracked changes, comments, footnotes and a comparison between two files. Ours is neither: it is a small set of business documents, proposals, contracts, letters and template fills, produced from a stored letterhead.
| Fact | Ours | @docx-mcp/docx-mcp | @usejunior/docx-mcp |
|---|---|---|---|
| Tools | 8 plus license_status and license_activate | Create, query, edit, open and save operations over a JSON schema | Read, search, edit, comment, footnote, tracked changes, save, compare, export |
| Licence | MIT | MIT | Apache-2.0 |
| Latest version read on npm | publish pending; .mcpb bundle and clone-and-build | 0.5.0, published 2025-08-26 | 0.19.1, published 2026-07-24 |
| Transport | stdio (npx or .mcpb bundle) | stdio (npx) | stdio (npx); end users are pointed at the @usejunior/safe-docx wrapper |
| Writes a proposal or contract | Yes, proposal_create and contract_create with reference numbers | No, you supply the whole document tree | No, it edits documents you already have |
| Fills {{placeholders}} in a template | Yes, on joined paragraph text, keeping styles, headers and images | Not documented | Not documented; it edits by content instead |
| Tracked changes and comments | No. doc_read ignores them | No | Yes, inspect and accept tracked changes, comments and footnotes |
| Images in generated documents | No | Yes: URL download, local file and base64 embedding | Editing only |
| PDF output | No, by design. doc_to_html plus print | No | No; exports documents and structured revisions |
Rows for the two alternatives were read from their npm registry records and READMEs on 2026-09-03.
Pick it when the document is generated wholesale by a program and the layout matters. It validates a document against a JSON schema and renders headings, tables, lists, blockquotes, info boxes, text boxes, horizontal rules, page and section breaks, page settings and per-page headers and footers, plus code blocks with syntax highlighting for over 180 languages and images from a URL, a local file or base64. None of that exists in ours. If you are building a report generator rather than sending a proposal, it is the better fit, and its image support in particular is something we do not offer at all.
Pick it when the document already exists and the job is to change it carefully. It reads and searches
content, applies text, paragraph, formatting, comment and footnote edits, inspects and accepts tracked
changes, saves clean and tracked copies, and compares two documents. It also handles OpenDocument
.odt. Ours reads a .docx as text and outline and cannot see a tracked change or
a comment at all, so for a contract going back and forth with a counterparty's redlines, that server does
the job and this one does not. Note the licence difference: Apache-2.0 rather than MIT.
Pick ours when you want the document, not a document engine. One sentence produces a client-ready
proposal with your letterhead, a cover title, summary, scope, deliverables, a timeline table, a priced
investment table, terms, validity and a signature block, numbered PROP-YYYY-NNNN, and the
counter is written before the record is stored, so a crash burns a number rather than handing the same
reference to two sent documents. The letterhead comes from the same business_set profile
the invoice server uses, so the proposal you win becomes the invoice you send.
Everything is local: no upload, no account, no native dependency, and no network request of any kind.
Two details are the reason this server reads and fills real files rather than clean ones. Template
filling substitutes on the joined text of each paragraph, not per run, because Word routinely splits a
placeholder you typed as {{client}} into three runs after an edit or a spell-check pass, and
per-run replacement misses those silently. And numbered lists are told apart from bullets by resolving
each paragraph's w:numId against word/numbering.xml, which is the only place
that distinction is recorded: without it, every numbered clause in a contract reads back as a bullet.
The known cost is stated on the page and in the README: a paragraph mixing bold and regular text around a
placeholder comes back in the first run's formatting.
Ours, Claude Code:
claude mcp add docx -- npx -y @theluckystrike/mcp-docx@docx-mcp/docx-mcp:
claude mcp add docx-mcp -- npx -y @docx-mcp/docx-mcp@usejunior/docx-mcp:
npm install --global @usejunior/safe-docx
claude mcp add safe-docx -- safe-docxPer client config paths for ours are on the setup pages, the product page is MCP Docx, and the walkthrough is in proposals and contracts from chat.
None of the three. Every pure JavaScript path from Word to PDF needs a native dependency or a cloud API. Ours writes semantic HTML with a print stylesheet through doc_to_html so you can print to PDF, and says so in the tool description rather than promising a file it cannot make.
@usejunior/docx-mcp. It inspects and accepts tracked changes, handles comments and footnotes, and can compare two documents. Ours reads text, headings, lists and tables only, and ignores tracked changes entirely.
@docx-mcp/docx-mcp can, from a URL, a local file or base64. Ours puts a logo on the letterhead on Pro and nothing else; there is no general image block.
Yes. Ours and @docx-mcp/docx-mcp are MIT. @usejunior/docx-mcp is Apache-2.0, which carries a patent grant and a notice requirement that MIT does not. If your legal review cares, that is the row to read.
No. contract_create writes a drafting skeleton with bracketed placeholders and prints on the document itself that it is a template and not legal advice. Nothing in it has been reviewed by a lawyer in any jurisdiction.