docx-mcp

by sontanon

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation4/5
Most tools have clear, distinct purposes: extract, apply changes, validate, audit, and diff. However, validate_document_tool and audit_document_tool both inspect document structure and could be confused, and apply_changes_from_file is a redundant variant of apply_changes. Overall, the descriptions help clarify boundaries.
Naming Consistency4/5
Tool names follow a consistent verb_noun pattern with lowercase underscores (extract_fragments, apply_changes, diff_fragments). The '_tool' suffix on validate_document_tool and audit_document_tool is a minor inconsistency, and apply_changes_from_file is long but clear. The naming is generally predictable.
Tool Count5/5
With 6 tools, the server is well-scoped for the domain of .docx extraction, tracked changes, validation, and comparison. Each tool contributes to a focused workflow, and the count is within the ideal 3-15 range.
Completeness4/5
The tool surface covers the core lifecycle: extraction, applying changes, validation, auditing, and diffing. Minor gaps exist, such as no direct tool for creating documents or accepting/rejecting changes, and the extraction tool skips some elements. However, the primary redlining workflow is well-supported.
Average 4.6/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context by detailing what the audit reports on (headers, footers, images, tables, tracked changes, comments, unsupported elements), reinforcing its non-mutating nature without contradicting 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?
The description is two concise sentences with no filler. It front-loads the verb and object, then immediately lists the specific report categories. Every sentence earns its place.
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 a full input schema and output schema, the description fully covers what the tool does and what it reports. The list of auditable elements is sufficiently specific, and the output schema handles return-value documentation.
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?
The input schema covers both parameters with full descriptions: document_path requires an absolute path and format enumerates text/json with a default. The description does not add parameter-level detail beyond what the schema already provides, so the baseline 3 applies.
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 uses a specific verb ('Audit') with a clear resource ('.docx file') and scope ('structural issues and skipped content'). It lists concrete report categories, which clearly distinguishes it from sibling tools like apply_changes and validate_document_tool.
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 description clearly states when to use the tool: to audit a .docx file for structural issues and skipped content. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select it over write-oriented or fragment-manipulation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond the annotations by detailing the required JSON file format (bare array or object with 'changes' key) and providing an example. It also references apply_changes for rules. Annotations already indicate idempotency and non-destructiveness, so the description complements rather than repeats them. No contradictions.
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?
The description is efficient and well-organized: a lead reference to the sibling tool, explicit use cases, and a compact example of the file format. Every sentence earns its place without redundancy or fluff.
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 schema covers all parameters and the description provides usage scenarios, file format requirements, and a pointer to apply_changes for the change-object schema, the tool is fully contextualized. The presence of an output schema further reduces the need for the description to explain return values. This is a complete package for a tool of this complexity.
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?
The schema provides descriptions for all four parameters (100% coverage), so the description doesn't need to explain them. It adds minimal value for parameters beyond the changes_file example, which illustrates content but not the parameter meaning. The baseline 3 is appropriate since the schema does the heavy lifting.
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 clearly states the tool is 'Same as apply_changes but reads the change list from a JSON file,' immediately distinguishing it from the sibling apply_changes. It specifies the action (applying changes) and the resource (document with changes from a file), leaving no ambiguity about its purpose.
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 description explicitly identifies when to use this tool: 'for large change sets that would exceed token limits in a direct tool call, or for reusing a change set across multiple runs.' It also directs users to apply_changes for schema and rules, implicitly providing the alternative context. This is clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations by disclosing specific behaviors: it produces w:ins/w:del tagged changes, hard-rejects documents with pre-existing tracked changes, silently drops comments in headers/footers, and explains pseudo-Markdown formatting. These are non-obvious traits not captured by readOnlyHint, idempotentHint, or destructiveHint, adding significant value.
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?
The description is long but well-organized with sections, examples, and a clear progression from summary to details. It is appropriately sized for the tool's complexity, though it includes some repetition of information already present in the schema (e.g., pseudo-Markdown rules). The front-loaded summary sentence ensures immediate clarity.
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?
The description covers prerequisites, change types, parameter constraints, edge cases (headers/footers, pre-existing changes), output behavior, and provides multiple examples. It even explains the return value. Despite the tool's complexity and nested schema, the description is sufficiently complete for an agent to select and invoke it correctly.
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 description coverage is 0% for top-level parameters, so the description must compensate—and it does thoroughly. It defines document_path as an absolute path, output_path's default behavior, author's default, and the structure of changes list. It also explains nested change types, required fields, and validation rules, effectively documenting all parameters.
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 and resource: 'Apply tracked changes to a .docx file and save a new redlined document.' It clearly distinguishes the tool from siblings like apply_changes_from_file by focusing on in-memory change objects and mentioning the redlining output. The scope is unambiguous.
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 description explicitly instructs 'Always call extract_fragments first to get fragment IDs,' which is a clear prerequisite and differentiates this tool from alternatives. It also provides detailed rules for when to use each change_type and parameter. However, it does not explicitly contrast with apply_changes_from_file, so the exclusion is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations by detailing the exact output format, fragment ID conventions, markup syntax, and limitations (skipped elements, hard rejection of tracked changes). This provides substantial behavioral context that the annotations (readOnlyHint, idempotentHint) do not cover.
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?
The description is well-structured with clear sections (output format, fragment IDs, formatting, limitations, args, returns). It is appropriately sized given the tool's complexity, and every sentence contributes useful information without redundancy.
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?
The description is thorough: it explains the output schema, fragment ID patterns, formatting, limitations, parameters, and return value. It also places the tool in its workflow context relative to apply_changes, making it fully self-contained for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a single parameter (document_path) and 0% schema description coverage, the description compensates by explaining 'Absolute path to the .docx file,' which adds the required meaning. While not exhaustive, it fully clarifies the only parameter's purpose and type.
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 clearly states the verb+resource: 'Extract text from a .docx file as tagged fragments.' It further distinguishes the tool by explaining its role as the first step for obtaining fragment IDs to be used in apply_changes, setting it apart from sibling tools.
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 description explicitly instructs 'Call this first to get fragment IDs, then use those IDs in apply_changes,' which tells the agent exactly when to use this tool. It also mentions limitations (skips images, nested tables, etc.) that imply cases where the tool is not suitable, though it does not name alternative tools for those situations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint: true, idempotentHint: true) are complemented by detailed behavioral descriptions: it lists the four specific validation checks (annotation ID isolation, comment integrity, tracked-change attributes, package consistency) and provides example success/failure output. This goes far beyond annotation hints and gives a clear picture of what the tool does, with no contradictions.
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?
The description is well-structured with clear headers, bullet points for validation checks, and code blocks for example output. Although somewhat long, every section adds value and the main purpose is front-loaded in the first sentence. No redundant or filler content.
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 simplicity (one parameter, full schema coverage, no nested objects) and the presence of an output schema, the description is more than complete. It covers purpose, usage scenarios, validation checks, and example output, leaving no significant gaps for an agent to misuse the tool.
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?
The input schema already provides 100% coverage of the single parameter document_path, including a description ('Absolute path to the .docx file to validate'). The tool description adds no additional semantics about this parameter, so baseline 3 applies.
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 'Check a .docx file for structural issues' and elaborates on validating OOXML structure for Word compatibility, tracked changes, and comments. This is a specific verb+resource statement that thoroughly distinguishes its scope from sibling tools, especially audit_document_tool, by listing the exact validation checks.
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 description includes an explicit 'Use this tool:' section listing three concrete scenarios (after apply_changes, debugging open failures, verifying existing redlined documents). It also notes that validation is automatically enabled via validate=True in apply_changes, effectively communicating when the tool may not need to be called separately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![docx-mcp MCP server](https://glama.ai/mcp/servers/sontanon/docx-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sontanon/docx-mcp)

Score Badge

Copy to your README.md:

[![docx-mcp MCP server](https://glama.ai/mcp/servers/sontanon/docx-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sontanon/docx-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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