Skip to main content
Glama

diff_fragments

Read-onlyIdempotent

Compare two .docx files to reveal paragraph and table-level text differences. See exactly what changed between document versions.

Instructions

Compare two .docx files and show paragraph and table-level text differences.

Extracts the pseudo-Markdown text from each paragraph and table cell in both documents, then produces a word-level diff for each fragment position. This is useful for understanding what changed between two versions of a document.

Use this tool:

  • To compare an original document with its redlined version (see what changes were applied)

  • To verify that apply_changes produced the expected modifications

  • To understand differences between two versions of a document

Important Limitations

Fragments are matched by position (fragment 1 vs fragment 1, fragment 2 vs fragment 2, etc.). This tool does not detect fragment reordering or track moved sections. If the documents have very different structures (different fragment counts, major reordering), the output will show extensive changes.

Best used for comparing documents with the same basic structure where you made local edits (word changes, clause deletions, appended sections, table cell modifications).

Output Format

Each fragment is reported with its change status.

Paragraphs::

Fragment 1: unchanged
Fragment 2: modified
  - shall deliver
  + must deliver immediately
Fragment 3: unchanged
Fragment 5: deleted (only in original)
  - This clause is removed.
Fragment 10: added (only in modified)
  + This is a new clause.

Tables::

Table 56: modified
  Cell 56.2.2: modified
    - Gwendolyn Mahon, M.Sc., Ph.D
    + John H. Smith, Ph.D.
Table 57: unchanged
Table 58: dimensions changed (3x2 → 4x2)

Lines starting with - show deleted text, + shows inserted text. Unchanged fragments are listed but their text is omitted for brevity.

For tables, each modified cell is shown with its cell ID (table_id.row.col) followed by the word-level diff of the cell content.

Difference from extract_fragments

  • extract_fragments shows the plain text of a single document (paragraphs, headers, footers, tables). Pre-existing tracked changes cause a hard rejection.

  • diff_fragments compares two separate documents and computes the differences between their plain text (ignoring any tracked changes)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modified_pathYesAbsolute path to the modified .docx file.
original_pathYesAbsolute path to the original .docx file.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Annotations already mark this as read-only/idempotent/non-destructive, so the bar is lower; the description adds meaningful behavior: position-based matching, no reordering detection, ignoring tracked changes, and the output style. No contradiction with annotations.

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?

Although longer than typical descriptions, the structure is organized into purpose, usage, limitations, output format, and sibling comparison, with examples. Each section adds non-redundant operational detail, so it earns its length.

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?

Given the tool's moderate complexity and the presence of an output schema, the description is sufficient: it covers core behavior, matching strategy, important exclusions, and interaction with tracked changes. No critical operational gaps remain.

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

Parameters3/5

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

Input schema has full 100% coverage with clear descriptions of the two absolute paths, so the baseline is 3. The description reinforces which file is original vs modified in the usage bullets but does not add parameter-specific semantics beyond the schema.

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 verb ('Compare'), names the resource (two .docx files), and states the output granularity (paragraph/table-level text differences). It clearly distinguishes itself from sibling extract_fragments by framing this as a comparison tool rather than extraction.

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?

The 'Use this tool' bullet list explicitly enumerates three concrete use cases, and the 'Important Limitations' section states when NOT to use it (different structures, reordering). It also contrasts with extract_fragments, providing an alternative.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sontanon/docx-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server