Skip to main content
Glama
Sign In
KitchenSink4Word

KitchenSink4Word

by KitchenSink4AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Word Application and Open Documents

word_app
Destructive

Save or close Word documents, insert at cursor, toggle track changes, compare or merge files, convert PDFs, refresh fields, run proofing/readability checks, and repair live edits.

Instructions

Needs Microsoft Word itself: save or close a document open in Word, insert at the user's cursor, switch track changes on an open document, scroll Word to a spot, export to and import from PDF, compare, combine or merge documents, refresh fields, Word's proofing and readability statistics, the opens-clean check, and repair after a crashed live edit. Text edits to an open document go through word_edit and reads through word_read. Live edits stay unsaved until com_save_document; the other com_ ops work in a private hidden Word and never change the source file, except com_refresh_fields, which saves it in place. On a document open in Word, switch track changes on (live_set_track_changes) before editing, and save (com_save_document) last. Ops, one per line, as name(required; opt optional): what it does. file_path, live and backup are not repeated; word_help shows them:

  • com_save_document(opt save close password output_path): Save or close a document open in Word, or save an encrypted copy; close with save=false discards unsaved changes.

  • live_insert_at_cursor(text; opt newline): Insert text at the user's cursor position in the open document (main body text only; headers, footers, and footnotes not supported).

  • live_set_track_changes(enabled): Turn track changes on or off in the open document; the setting stays unsaved until com_save_document (set_track_changes for a closed file).

  • com_refresh_fields(): Update every field (TOC, page references, captions, cross-references) in a hidden Word; this saves the file in place. Header/footer PAGE and NUMPAGES keep their cached values; Word recomputes them at layout.

  • com_validate_opens_clean(opt timeout): Open the file in a hidden Word and report whether it opens clean, with Word's own error if it does not. More ops follow, in the same format, in the op parameter's description.

Input Schema

NameRequiredDescriptionDefault
opYesThe operation to run: an op listed in this tool's description, or one of these, in the same format: - com_multi_document(action, files; opt output_path author section_break_between timeout): Compare two drafts into a redline, combine two reviewers' changes, or merge documents into one new file (action). - com_import_pdf(pdf_path; opt output_path): Convert a PDF to .docx via Word's built-in PDF reflow, in a dedicated invisible Word instance. - com_export_pdf(opt pdf_path overwrite): Export the document to PDF via an invisible Word instance with full fidelity (fields resolved, footnotes, TOC, headers/footers, images). - live_scroll_to(opt find paragraph_index): Scroll the user's Word window to show a location without selecting anything or moving their cursor (useful after a live edit, to show the user what changed). - live_repair(): Repair Word after a crashed live edit (screen updating off, alerts off, an open undo record); safe to run at any time. - com_proofing_errors(opt limit timeout): List Word's spelling and grammar errors with context and suggestions; the file must be closed in Word. - com_readability_statistics(opt timeout): Read Word's readability statistics (Flesch scores, counts and averages); the file must be closed in Word. - update_now(): Install the newer version the update notice named; call only when the user asks or agrees. - update_notices(action): Turn update notices on or off, or show their status (action).
argsNoThe op's arguments as an object. Include file_path (the absolute .docx path) unless the op's line names other paths or the op reads no document; unknown keys are refused. word_help lists every argument.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, it explains that live edits stay unsaved until com_save_document, that most com_ ops use a private hidden Word and do not alter the source file, and that com_refresh_fields is the exception because it saves in place. It also states that closing with save=false discards unsaved changes, which is exactly the kind of destructive behavior an agent needs to know.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but front-loads the purpose, key behavioral constraints, and sequencing before listing operations. It is dense and earns most of its space, though the first few op lines duplicate content already present in the schema enum description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-op, high-complexity tool with no output schema, it supplies the critical context: which ops use hidden Word, which mutate the source file, which require Word to be open, and how to sequence live edits and saves. It also points to word_help for argument details, so the description is complete enough for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds useful meaning: file_path is required unless an op names other paths or reads no document, and unknown args keys are refused. The op argument list is partially duplicated in the schema's op enum description, which keeps this from a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific scope: 'Needs Microsoft Word itself' and lists the exact Word-application operations it owns, from saving open documents to PDF import/export and live repair. It explicitly separates this tool from word_edit and word_read, so an agent can distinguish it from siblings without opening their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It names the alternatives and when to use them: text edits go through word_edit and reads through word_read. It also gives sequencing rules for live work, saying to enable track changes before editing and save last, which tells the agent how to order calls correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools