Skip to main content
Glama

Read Word Document

word_read
Read-onlyIdempotent

Inspects, searches, lists, counts, and checks .docx files read-only, so you can review document content and structure before making any changes.

Instructions

Read-only: inspect, search, list, count and check a .docx before changing it. Never changes a file. To change anything use word_edit, word_format, word_structure, word_media, word_review, word_references, word_document or word_app. get_document_info, get_outline, get_text, find_text, get_comments and word_count read a document open in Word live; get_document_view reads its last saved state; the other reads of a file need it closed 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:

  • get_text(opt start end contains include_textboxes textbox): Read body paragraphs as [{index, text, style, ...}]; start and end are paragraph numbers, end exclusive.

  • get_document_view(opt scope detail include): Read the document as an anchored markdown projection, the low-token alternative to get_text for orientation and bulk editing. detail="full" shows revisions and comments.

  • find_text(opt query regex context_chars include_textboxes formatting scope max_results): Find text in paragraphs and table cells; returns locations plus context.

  • list_elements(type; opt filter): List one kind of element (tables, images, charts, bookmarks, notes, fields, lists, sources, ...) with the ids other ops take.

  • get_headers_footers(): Read every header and footer in every section: its text, its type, and whether it holds a page-number field.

  • get_document_info(): Read a one-call overview: paragraph, table, note, comment and revision counts, sections and package parts.

  • com_word_status(): Check whether Word is ready, busy or blocked by a dialog, and which open documents have unsaved changes; use before live edits.

  • validate(opt checks options): Run read-only check batteries (checks, default ['core']; also accessibility, notes, citation_parity and more) and return one report. 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: - diagnose_document(): Report the saved file's structural health (relationships, fields, notes, styles, bookmarks): the deeper companion to validate. - get_workflows(opt task): Recommended tool sequences for common multi-step tasks, with a one-line why per step. - get_styles(opt names type include_formatting): List the document's styles with their explicitly set formatting, in the shape define_style accepts. names, type and include_formatting=false narrow the list; a list over the output limit comes back cut, with a note of what was left out. - get_outline(opt detect_formatted offset): List every heading with its paragraph index and level. - get_table(table_index; opt nested): Read one table in full: every cell's text, the merge map, and column widths. - get_comments(opt author): Read comments with author, anchored text, replies and resolved state; author filters to one reviewer. - get_tracked_changes(opt author limit offset): List every tracked change with its type, author, date, text and paragraph; author filters to one reviewer. - get_server_info(opt include_licensee): Report build, edition, license status, tool surface, Word availability, sandbox shape, host and update state. - structured_diff(old_path, new_path; opt detail_cap): Compare two saved drafts paragraph by paragraph without Word; not a redline (com_multi_document compare makes one). - get_paragraph_format(start; opt end): Read the effective paragraph formatting of paragraphs start to end (inclusive), each value with where it comes from. - word_count(opt by_section exclusions): Count words, characters, and paragraphs; totals only unless by_section=true, which adds a count under each heading (one entry per heading, so long for a manuscript). - get_revision_report(opt mode): Summarize tracked changes by author and type (mode='summary'), or by author and section in detail (mode='analytics'). - comment_report(files; opt include_resolved): Build the reviewer matrix of comment threads for one file, or merged across copies of one draft (files is a list). - get_protection(): Read the document's editing restriction: its mode, whether a password is set, and formatting restrictions. - detect_citation_system(): Detect which citation systems the document uses (Word, Zotero, Mendeley, EndNote or plain text); run it before citation work. - parse_references(opt style_hint): Parse the reference list and in-text citations into a structured model, with a parse confidence for each entry.
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

A5/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description is consistent with them while adding non-obvious constraints: some ops read the document open in Word live, get_document_view reads the last saved state, and other file reads require the file closed in Word. It also flags Word busy/blocked-by-dialog states and unsaved changes via com_word_status.

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

Conciseness5/5

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

Very long but every line is a distinct op with its arguments and return shape; nothing is padded. The critical facts (read-only, the mutating siblings, live vs saved state) are front-loaded before the op table, and at ~23 ops the length is proportionate.

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 23-op dispatcher with no output schema, the description covers purpose, routing, state requirements, per-op arguments, and even return shapes for the main ops (get_text's [{index, text, style, ...}], list_elements' ids). The remaining ops are handed off explicitly to the `op` parameter's schema description in the same format, so nothing needed to call it correctly 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%, but the schema only exposes a bare `op` enum and an `args` bag; the description supplies the real argument semantics per op (e.g. start/end are paragraph numbers with end exclusive, regex vs query in find_text, detail="full" shows revisions and comments). It also states that file_path, live and backup are shared and where to find them.

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?

Opens with a specific verb set (inspect, search, list, count, check) and the exact resource (.docx), and immediately names eight sibling tools that do the mutating work. The live-vs-saved-state sentence further partitions it from its own ops, so an agent can place the tool without opening the 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 when/when-not: 'Never changes a file. To change anything use word_edit, word_format, word_structure, word_media, word_review, word_references, word_document or word_app.' It also routes within the tool — com_word_status 'use before live edits', detect_citation_system 'run it before citation work', get_document_view as the low-token alternative to get_text.

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