🚰 KitchenSink4Word

Landing page · llms.txt (machine-readable capability manifest for agents and LLM crawlers)

Everything plus the kitchen sink for Microsoft Word. The most complete Word (.docx) MCP server available: 221 document operations across 110 tools, one consistent grammar, engineered not to corrupt and stress-tested against long, heavily formatted real-world documents. Live editing included: documents open in Word are edited in place, visibly, with each tool call landing as a single Ctrl+Z step.

⚠️ v2.0 is a breaking change

Every v1.x tool name changed. The 189-tool v1.6 surface was rebuilt as a consolidated set of 110 tools that cover every prior capability under one grammar. If you are upgrading from v1.x, read the migration guide first: it maps every old tool name to its v2 home, and get_workflows("migrate-from-v1") returns the same map in-session. New installs need nothing extra.

Two numbers that matter

• 221 document operations, 110 tools. The operation count went up and the tool count came down on purpose. v1 spread similar jobs across many competing names; v2 gives each concept exactly one name built from a small verb table (insert_, set_, manage_, list_elements, validate, delete_element), so an agent picks the right tool the first time and carries less schema to do it. Fewer tools, more reach. Measured with one yardstick on both trees, v1.6 performed 200 operations across its 189 tools and v2.0 performs 221 across 110: every v1.6 capability survived the consolidation (the migration map covers all 189, test-guarded) and v2 adds the anchored batch editor, the anchored document view, deletion parity, and wider dispatch on the multiplexers. Both figures come from scripts/count_operations.py; the v1.6 run is scripts/count_operations_v16.py, which measures a v1.6 checkout with the same definition.
• Tiered loading: starts at about 8.0k tokens, scales to everything. A fresh session loads the 29-tool lite core (about 8,000 tokens) and turns on capability packs only when a task needs them, with one enable_tools call. Load every pack and the full surface measures about 27,800 tokens, down from about 34,400 in v1.6: roughly 23% less for the whole sink, about 78% less at lite start. (All figures are script-measured; see Context cost below.)

The packs

Numbers below come straight from scripts/measure_surface.py, never hand-counted. The lite core loads at startup; the seven packs load on demand.

Quickstart: start lite, enable what you need

A session begins with the lite core. When a task needs more, the agent turns on the pack by name:

enable_tools(["references"])          # citations, bibliography, Zotero
enable_tools(["academic", "review"])  # notes, TOC, tracked changes, comments

Lite-tool refusals name the pack and the exact enable_tools call to run, and get_workflows recipes name the packs each workflow needs, so discovery is built in. To skip tiering entirely, start the server with KS4W_MODE=full and every tool is present from the first call.

Installed from the .mcpb bundle, the same two choices are checkboxes in the server's Claude Desktop settings: "Load every tool at startup" and "Lock the tool set at startup" (which fixes the surface so enable_tools refuses). They write KS4W_ALL_TOOLS and KS4W_LOCK_TOOLS. Both take true or false, treat empty as off, and refuse to start on anything else rather than guessing. KS4W_MODE beats the first and KS4W_PACK_POLICY beats the second whenever they are set, so a pinned pack list survives an install, and the server writes one line to stderr at startup naming what decided the surface.

One tip that removes most permission pop-ups: In Claude Desktop's Tool permissions for this server, set the Read-only tools group to Always Allow. Those tools cannot change anything, so approving them once is safe, and Claude stops asking about every read. Leave the acting tools on Ask, so anything that changes things still checks with you first.

One client-side caveat: some MCP clients drop a tool's schema when a pack is disabled and do not pick it back up on re-enable, even though the server sends tools/list_changed both ways (observed in Claude Code, 2026-09). If a re-enabled tool comes back as "no such tool", refresh the tool list on the client side (in Claude Code, a ToolSearch call for the tool reloads its schema).

Why this one (the capability comparison)

Every public Word MCP server was surveyed before building this. The honest comparison is about what each one can do, not how many names it has:

Capability survey compiled from public repositories, documentation, and issue trackers. Corrections welcome: open an issue.

What the 221 operations cover

The everyday core covers text and formatting, tables (including merge-aware column insert/delete and one-call bulk cell edits), footnotes and endnotes (full lifecycle plus footnote and endnote conversion), TOC and caption lists, headers, footers, and sections, images, bulleted and numbered lists, content controls and fields, threaded comments, and tracked changes (read, accept and reject by author, and writing edits as tracked changes). Beyond that the surface spans equations (LaTeX to Word math), native charts, document assembly (chapter files into one manuscript), Zotero library citations, publication style conversion (8 styles, beta), review-cycle analytics, workflow suites (mail merge, batch operations, redaction, compliance and accessibility audits and fixes, submission prep, front matter, diagnostics), and Word-COM-backed document compare, field refresh, PDF export and import, and open-clean validation on Windows.

What makes it different