Skip to main content
Glama

Word Files and Assembly

word_document
Destructive

Create, copy, merge, split, template, mail-merge, protect, and export whole Word .docx files; manage backups, metadata, watermarks, accessibility fixes, and tables.

Instructions

Whole files: create, copy, assemble, split, templates, mail merge, backups, protection, watermark, document properties, accessibility fixes and table export. Edits inside one document belong to the other tools. Writes only the files named in args; manage_backups lists, restores and snapshots the automatic backups. Ops, one per line, as name(required; opt optional): what it does. file_path, live and backup are not repeated; word_help shows them:

  • insert_document(target_path, source_path; opt location formatting): Insert the ENTIRE body of source_path into target_path at one position, with full resource reconciliation: the chapter-merge tool.

  • copy_document(dest_path; opt overwrite): Copy a document byte for byte to dest_path; an existing destination is refused unless overwrite=true.

  • create_document(opt title): Create a new blank .docx, optionally with a title property; an existing file is refused.

  • manage_backups(action; opt file_path directory source scope dry_run label dest_dir): List, restore, purge or snapshot the automatic backups (prev and anchor slots); purge is a dry run unless dry_run=false.

  • set_document_properties(opt title author subject keywords category comments update_fields_on_open embed_fonts embed_fonts_subset): Set core document metadata (File > Info): title, author, subject, keywords, category, comments; only the parameters given change.

  • split_document(output_dir; opt level filename_from): Split a document into one standalone .docx per heading section, the inverse of com_multi_document merge (no Word needed).

  • copy_table(target_path, source_path, table_index; opt after_index after_text at_end): Copy one table from source_path into target_path, reconciling styles, numbering, images and notes; the source is not changed.

  • apply_template(reference_path; opt include_page_geometry): Restyle this document to match a reference document: styles, theme, fonts, layout settings, optionally page geometry. 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: - fill_template(data; opt missing): Fill a template IN PLACE: replace every {{name}} with data[name] (safe across fragmented runs, first run's formatting kept) and set MERGEFIELDs as plain text. - mail_merge(template_path, data_rows, output_dir; opt filename_pattern missing): Mail merge: one filled .docx per data row, saved into output_dir. - assemble_front_matter(spec): Insert front matter (title page, abstract, TOC, lists) at the start, numbered in roman numerals before the body. - set_document_protection(opt protection password restrict_formatting): Restrict editing, or lift the restriction. - set_watermark(watermark): Set or remove the page watermark. - fix_accessibility(opt alt_text_placeholders heading_skips heading_strategy table_headers doc_title dry_run): Repair validate(checks=['accessibility']) findings, one opted-in category at a time; all default OFF, none enabled refuses. - export_table(table_index; opt format output_path include_merges): Export one body-level table to CSV or JSON as a rows x grid-columns matrix.
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.6/5.0
Behavior5/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, and the description goes well beyond them: "Writes only the files named in args", "an existing destination is refused unless overwrite=true", "purge is a dry run unless dry_run=false", "all default OFF, none enabled refuses", "unknown keys are refused", "only the parameters given change". These refusal, dry-run, and no-op-default semantics are exactly the mutation-safety context an agent needs and are not derivable from the annotations.

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?

Front-loaded with the scope sentence, then a dense but uniform per-op table — appropriate for a 15-op dispatcher, and every line earns its place. Minor cost: the enumeration is split between the description and the op parameter's description ("More ops follow, in the same format"), forcing the agent to read two places, and terms like "live" and "backup" are referenced before being introduced.

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

Completeness4/5

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

For a complex multi-op writer with no output schema and an open args object, the definition covers all 15 ops, the path convention, and the mutation-safety profile. Gaps are small: the args-key contract is delegated to word_help, and return/result behavior for the file-writing ops is left implicit.

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?

Schemas cover the top-level op/args shape, but args is an untyped additionalProperties object — the description supplies the real semantics: required vs. optional per op and what each does ("insert_document(target_path, source_path; opt location formatting)"). It also explains the shared file_path convention and that "file_path, live and backup are not repeated; word_help shows them", which is meaning the schema cannot provide.

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?

"Whole files: create, copy, assemble, split, templates, mail merge, backups..." states the resource and scope with a specific verb list, and the immediate contrast "Edits inside one document belong to the other tools" carves out the boundary against word_edit/word_format. An agent can route between this and its nine siblings from the first two sentences alone.

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

Usage Guidelines4/5

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

The when-not rule ("Edits inside one document belong to the other tools") plus the whole-file scope is an explicit exclusion, and per-op lines describe the situation each op serves ("the chapter-merge tool", "the inverse of ... merge"). It stops short of naming the specific sibling an agent should use for in-document edits, leaving that inference to the agent.

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