Skip to main content
Glama

Word Comments and Review

word_review
Destructive

Manage review state in Word .docx files: add/reply/resolve/delete comments, accept/reject tracked changes, anonymize for blind review, and prepare manuscripts for submission.

Instructions

Review state: add, reply to, resolve and delete comments, accept or reject tracked changes, switch Track Changes on or off in a closed file, anonymize a manuscript for blind review and restore it, and clean a manuscript for submission. To read comments or tracked changes use word_read; to make tracked edits use word_edit with track=true. resolve_revisions and prepare_for_submission can be undone only from the automatic backup. These ops refuse a document open in Word. Ops, one per line, as name(required; opt optional): what it does. file_path, live and backup are not repeated; word_help shows them:

  • manage_comment(action; opt text author comment_id location done): Add a comment at a location, or reply to, resolve or delete one by comment_id. Leave author out to sign with the user's own name, or pass author="assistant" to sign as "AI Assistant via KS4Word".

  • resolve_revisions(action; opt author): Accept or reject tracked changes in bulk, for every author or one (author); undo is from the automatic backup only.

  • anonymize_for_review(author_names; opt replacement mapping_path): Heuristic: review the flagged items rather than trusting silently. Anonymize a manuscript for blind review, reversibly; writes a private mapping file and flags identifying prose for you to check.

  • deanonymize_document(opt mapping_path): Reverse anonymize_for_review using its mapping file (default .anonymization.json beside the document).

  • prepare_for_submission(opt accept_revisions remove_comments scrub_metadata keep_title): Accept all tracked changes, delete all comments and scrub identifying metadata in one call; footnotes, fields and citations stay.

  • set_track_changes(enabled): Turn Track Changes on or off in a closed document, so Word and ops that take track record later edits (live_set_track_changes for an open one). One tracked edit needs only track=true on that op. 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: - retrack_changes(baseline; opt author preview skip_untrackable): Mark edits made with Track Changes off as tracked changes against an earlier copy. Leave author out to sign with the user's own name, or pass author="assistant" to sign as "AI Assistant via KS4Word".
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.9/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=false, but the description adds material context: resolve_revisions and prepare_for_submission are undoable only from the automatic backup, anonymize_for_review writes a private mapping file and flags prose for human checking, and all ops refuse documents open in Word. That is exactly the kind of irreversibility and side-effect disclosure the annotations alone cannot convey.

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?

Structure is strong: an overview sentence, sibling routing, a warning about irreversibility, then a consistent 'name(required; opt optional): what it does' legend with shared args factored out. The opening sentence is a dense run-on packing eight operations, which costs a little readability, but no line is filler.

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 multi-op dispatcher with no output schema, the definition covers purpose, alternatives, preconditions, irreversibility, per-op arguments, and a pointer to word_help for the shared file_path/live/backup args and for further ops. Nothing an agent needs in order to pick and invoke an op is missing.

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

Parameters5/5

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

Schema coverage is 100% and the args object is freeform, so the description carries the real burden — and it does, listing per-op required and optional arguments (action, comment_id, author, mapping_path, accept_revisions, baseline, etc.) with semantics such as leaving author out to sign with the user's own name. This goes well beyond the schema's generic args description.

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 opening sentence names a specific resource (comments and tracked changes in Word documents) and a concrete set of verbs (add, reply, resolve, delete, accept, reject, anonymize, clean). It explicitly distinguishes itself from siblings by naming word_read for reading and word_edit with track=true for tracked edits, so an agent can route without opening either schema.

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?

Explicit routing is given: 'To read comments or tracked changes use word_read; to make tracked edits use word_edit with track=true.' It also states a hard precondition ('refuse a document open in Word') and names live_set_track_changes as the alternative for open documents, covering when-to-use and when-not.

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