Skip to main content
Glama

Edit Word Text

word_edit
Destructive

Edits Word .docx body text by inserting, rewriting, deleting, finding and replacing, adding breaks, redacting sensitive content, and applying anchored batch changes with optional tracked changes.

Instructions

Change body text: insert, rewrite, delete, find and replace, page and section breaks, redaction, the anchored batch editor (apply_edits) and anchor stamping. Tables and lists are word_structure; styles and formatting are word_format. In any text an op writes, \n is a line break and \t a tab. Ops that take track=true record the change as a tracked change. Leave author out to sign with the user's own name, or pass author="assistant" to sign as "AI Assistant via KS4Word". Every edit to a closed file backs it up first and saves atomically, and a failed validation changes nothing. A document open in Word is edited live and stays unsaved until word_app com_save_document; ops with no live route refuse it. Paragraph numbers count body paragraphs from 0, tables not included, so the first paragraph (usually the title) is paragraph 0; get_text and get_outline show the numbers. An insert at {"paragraph": N} goes after paragraph N (position "before" puts it in front). When a heading or phrase marks the spot, use after_heading, search or anchor instead of a number. 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_paragraphs(paragraphs; opt location inherit_format copy_format_from track author): Insert paragraphs (items {text, style?, formatting?, heading_level?, paragraph_format?}) at a location object (omitted = document end). Each item becomes a new paragraph; to add words inside an existing paragraph, use search_and_replace. 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: - search_and_replace(replacements; opt scope preview find_formatting max_replacements track author): Find and replace a list of {find, replace, regex?} items in one call, safe across Word's split runs; preview=true changes nothing. To add words inside a paragraph, replace the words just before the spot with the same words plus the new ones; with track=true only the new words are marked. Not for removing sensitive text: to remove a name or code everywhere before sharing a document, use redact_text, which also cleans charts, properties and hidden places and confirms the result. If redact_text refuses a replacement, ask the user what to use instead of replacing here. - delete_paragraphs(opt start end range track author expect_start expect_end): Delete body paragraphs by 0-based inclusive index (start, end; end defaults to start) or by range={start, end} location objects. - insert_break(opt type location): Insert a page break or a section break after the located paragraph (omit location for the document end). - apply_edits(edits; opt atomic): Apply a batch of anchor-addressed edits in one call: one lock, backup, and validated save. - delete_element(type; opt id location): Delete one equation, image, chart, bookmark, hyperlink, caption, reference list or content control (type picks which). - stamp_anchors(opt scope detail include): Write durable paragraph anchors into the file so later edits can address paragraphs by anchor; the writing form of get_document_view. - set_paragraph_text(location, new_text; opt expect): Replace one paragraph's full text, keeping style and base formatting; address it with a location object ({paragraph: N}, {search: ...}, {outline: ...}). Pass expect to refuse if the index shifted. - redact_text(targets; opt replacement scope ignore_case whole_word): Permanently remove matched text, then re-read the saved file. targets: [{find, regex?}].
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 destructiveHint=true annotation it discloses the actual safeguards: every edit to a closed file backs it up first, saves atomically, and a failed validation changes nothing; a document open in Word is edited live and stays unsaved until word_app com_save_document, and ops with no live route refuse. It also explains tracked-change semantics (track=true) and authorship (omit author to sign with the user's name, author="assistant" to sign as an AI). This is exactly the extra context the annotations cannot carry.

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 logical and front-loaded: purpose, sibling boundaries, escaping, track/author semantics, backup and live-edit behavior, addressing rules, then a per-op line format. It is long and dense, and the trailing 'More ops follow... in the op parameter's description' is a meta-instruction, but nearly every sentence carries non-redundant operating information for a multi-op dispatcher.

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 9+-op dispatching tool with no output schema, it covers addressing, safety, live-vs-closed files, and per-op argument shape thoroughly. It does not say what the ops return or how success/failure is reported beyond 'a failed validation changes nothing,' leaving a modest gap for a tool with varied per-op results.

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%, but the description still adds real meaning: paragraph indices are 0-based, count body paragraphs only, exclude tables, and are visible via get_text/get_outline; an insert at {"paragraph": N} goes after paragraph N, with position 'before' putting it in front; and in any written text \n is a line break and \t a tab. That resolves ambiguities the enum/schema alone would leave open.

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 line states a specific verb+resource (change body text) and enumerates the covered operation families: insert, rewrite, delete, find/replace, breaks, redaction, apply_edits, anchor stamping. It also draws explicit boundaries against siblings: 'Tables and lists are word_structure; styles and formatting are word_format,' so an agent can distinguish it without opening another 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?

It gives concrete routing rules: use after_heading/search/anchor 'instead of a number' when a heading or phrase marks the spot, use search_and_replace to add words inside an existing paragraph, and use redact_text rather than search_and_replace for sensitive removal. It names what to do when redaction refuses ('ask the user what to use instead'), and it routes live-file work to word_app com_save_document, so when/when-not/alternatives are all explicit.

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