Provides conversion of DOCX files to Markdown format, preserving document structure, formatting, and content organization.
Supports installation and dependency management through npm, facilitating easy setup and maintenance.
Utilizes TypeScript for server implementation, providing type safety and improved development experience.
Implements schema validation for processing parameters and ensuring data integrity during document operations.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DOCX MCP Server analyze the structure of my report.docx"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A comprehensive Model Context Protocol (MCP) server for processing Microsoft Word (.docx) documents with full formatting support.
This MCP server provides advanced DOCX document processing capabilities using the powerful mammoth library:
Text Extraction: Extract plain text with word count
HTML Conversion: Convert to HTML with preserved formatting
Structure Analysis: Analyze document structure, headings, and formatting elements
Image Extraction: Extract embedded images (as base64 or save to files)
Markdown Conversion: Convert to Markdown format
Rich Formatting Support: Handles bold, italic, lists, headings, and more
Related MCP server: Office Word MCP Server
extract_textExtract plain text content from a DOCX file.
Parameters:
file_path (string): Path to the .docx file
Returns:
Plain text content
Processing messages
Word count
convert_to_htmlConvert DOCX file to HTML with formatting preserved.
Parameters:
file_path (string): Path to the .docx file
include_styles (boolean, optional): Include inline styles (default: true)
Returns:
HTML content with formatting
Processing messages
Warnings and errors
analyze_structureAnalyze document structure, headings, and formatting elements.
Parameters:
file_path (string): Path to the .docx file
Returns:
Document statistics (characters, words, paragraphs, headings)
Structure analysis (headings with levels)
Formatting analysis (bold, italic, lists count)
Processing messages
extract_imagesExtract and list images from a DOCX file.
Parameters:
file_path (string): Path to the .docx file
output_dir (string, optional): Directory to save extracted images
Returns:
Total image count
Image details (src, alt text, base64 status)
Output directory information
Processing messages
convert_to_markdownConvert DOCX file to Markdown format.
Parameters:
file_path (string): Path to the .docx file
Returns:
Markdown content
Word count
Processing messages
npm install
npm run buildThe server runs on stdio and communicates via JSON-RPC 2.0 protocol.
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "analyze_structure",
"arguments": {
"file_path": "/path/to/document.docx"
}
}
}{
"file_path": "/path/to/document.docx"
}✅ Text Extraction: Plain text with word counting
✅ Rich Formatting: Bold, italic, underline, strikethrough
✅ Document Structure: Headings (H1-H6), paragraphs
✅ Lists: Ordered and unordered lists with items
✅ Images: Extraction as base64 or file export
✅ Tables: Basic table structure (via HTML conversion)
✅ Links: Hyperlinks preservation
✅ Styles: Custom style mapping support
✅ Error Handling: Comprehensive error reporting
✅ Multiple Formats: HTML, Markdown, plain text output
The convert_to_html tool supports custom style mapping for better semantic HTML output:
// Example style mappings
"p[style-name='Heading 1'] => h1:fresh"
"r[style-name='Strong'] => strong"
"r[style-name='Emphasis'] => em"Base64 Embedding: Images can be embedded as base64 data URLs
File Export: Images can be extracted to a specified directory
Metadata: Alt text and content type preservation
Provides comprehensive document analysis including:
Character and word counts
Paragraph and heading counts
Formatting element statistics
Document structure hierarchy
Install dependencies:
npm installBuild the server:
npm run buildFor development with auto-rebuild:
npm run watchTo use with Claude Desktop, add the server config:
On MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"docx-format-server": {
"command": "/path/to/docx-format-server/build/index.js"
}
}
}@modelcontextprotocol/sdk: MCP protocol implementation
mammoth: Advanced DOCX processing library
zod: Schema validation
typescript: TypeScript support
All tools include comprehensive error handling with detailed error messages for:
File not found errors
Invalid file format
Processing errors
Permission issues
Since MCP servers communicate over stdio, debugging can be challenging. We recommend using the MCP Inspector, which is available as a package script:
npm run inspectorThe Inspector will provide a URL to access debugging tools in your browser.
v0.2.0: Complete rewrite with mammoth library, added 5 comprehensive tools
v0.1.0: Basic text extraction with docx-parser (deprecated)
ISC License
Analyze document structure, headings, and formatting elements
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the .docx file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool analyzes structure but doesn't disclose traits like whether it's read-only, what permissions are needed, how it handles errors, or the format of the output. This is a significant gap for a tool with no annotations, as it leaves key behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of a single, clear sentence that directly states the tool's purpose without any wasted words. Every part of the sentence earns its place by specifying the action and target resources efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the analysis returns (e.g., a structured report or raw data), potential side effects, or error handling. For a tool with no structured behavioral data, the description should provide more context to be fully helpful to an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'file_path' clearly documented as 'Path to the .docx file'. The description doesn't add any meaning beyond this, such as specifying file format constraints or analysis scope, but the schema provides adequate baseline information, justifying a score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('analyze') and resources ('document structure, headings, and formatting elements'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'extract_text' or 'convert_to_html', which might also involve document analysis, so it doesn't reach a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'extract_text' or 'convert_to_html'. It lacks any context about prerequisites, such as requiring a .docx file, or exclusions, leaving the agent to infer usage based on the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert DOCX file to HTML with formatting preserved
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the .docx file | |
| include_styles | No | Include inline styles (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'with formatting preserved', which adds some behavioral context about output quality, but does not disclose other traits such as error handling, file size limits, performance characteristics, or what happens if the file is invalid. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Convert DOCX file to HTML') and adds a key detail ('with formatting preserved') without any wasted words. It is appropriately sized for the tool's complexity and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations and no output schema, the description provides basic purpose but lacks details on behavior, error cases, or output format. It is minimally viable for understanding what the tool does, but does not compensate for the missing structured data, leaving gaps in completeness for a conversion tool with potential complexities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('file_path' and 'include_styles') with descriptions. The description does not add any meaning beyond what the schema provides (e.g., it doesn't explain the implications of 'include_styles' or provide examples). Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Convert DOCX file to HTML') and the resource ('DOCX file'), with the additional detail 'with formatting preserved' that distinguishes it from sibling tools like 'convert_to_markdown' or 'extract_text' which likely handle different formats or outputs. It uses precise verbs and specifies the input format and output format explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for converting DOCX files to HTML, but does not explicitly state when to use this tool versus alternatives like 'convert_to_markdown' or 'extract_text'. It provides basic context (format conversion with formatting) but lacks guidance on exclusions or specific scenarios where this tool is preferred over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert DOCX file to Markdown format
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the .docx file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe important behavioral traits: whether it preserves formatting, handles images/tables, requires specific permissions, has rate limits, or what happens on failure. 'Convert' implies a transformation but lacks details about the conversion process quality or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that directly states the tool's function. There's zero wasted language, no unnecessary elaboration, and it's front-loaded with the core purpose. Every word earns its place in this minimal description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file conversion tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the output looks like (format details, where the markdown is saved/returned), conversion quality, error conditions, or important behavioral constraints. The agent would need to guess about the conversion's scope and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single 'file_path' parameter. The description doesn't add any parameter semantics beyond what the schema provides - it doesn't explain acceptable path formats, file location constraints, or supported DOCX versions. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Convert') and resource ('DOCX file'), specifying the target format ('Markdown format'). It distinguishes from some siblings like 'extract_text' or 'extract_images' by focusing on format conversion, though it doesn't explicitly differentiate from 'convert_to_html' which is a similar conversion tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'convert_to_html' for different output formats, or when to use 'extract_text' if only plain text is needed. There's no context about prerequisites, file size limitations, or compatibility issues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract and list images from a DOCX file
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the .docx file | |
| output_dir | No | Directory to save extracted images (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions extraction and listing but doesn't specify whether images are saved, displayed, or returned in a particular format, nor does it address permissions, rate limits, or error handling for the file operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (file processing with two parameters) and lack of annotations or output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, output format, and usage context, leaving gaps for an AI agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for both parameters in the input schema. The description adds no additional meaning beyond what the schema provides, such as explaining how 'output_dir' affects the extraction process, so it meets the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('extract and list') and resource ('images from a DOCX file'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'extract_text' or 'convert_to_html' which might also handle DOCX files, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'extract_text' or 'convert_to_html' that might also process DOCX files. It states what the tool does but offers no context about appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract plain text content from a DOCX file
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to the .docx file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('extract plain text content') but doesn't cover important traits: whether it handles errors (e.g., invalid files), what permissions are needed, if it modifies the original file, or the format of the output. This is inadequate for a tool with mutation implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste. It's front-loaded with the core action and resource, making it highly efficient and easy to parse. Every word earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'plain text content' entails (e.g., stripped formatting, handling of tables/images) or potential errors. For a tool with implied file reading and content extraction, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter 'file_path' with its description. The tool description adds no additional meaning beyond what the schema provides (e.g., no examples or constraints on file paths). Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('extract') and resource ('plain text content from a DOCX file'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'convert_to_html' or 'convert_to_markdown' which also extract content but in different formats, so it doesn't fully distinguish from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'convert_to_html' or 'convert_to_markdown'. It doesn't mention prerequisites (e.g., file must be a valid DOCX) or exclusions (e.g., not for other file types). This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
analyze_structureconvert_to_htmlconvert_to_markdownextract_imagesextract_textEach tool has a clearly distinct purpose with no overlap: analyze_structure focuses on metadata and formatting, convert_to_html and convert_to_markdown handle different output formats, extract_images targets embedded media, and extract_text retrieves raw content. An agent can easily differentiate between structural analysis, format conversion, and content extraction tasks.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., analyze_structure, convert_to_html, extract_text). The verbs (analyze, convert, extract) are distinct and appropriately descriptive, creating a predictable and readable naming convention throughout the set.
With 5 tools, this server is well-scoped for DOCX file processing. Each tool earns its place by covering essential operations: structural analysis, format conversion to HTML and Markdown, image extraction, and text extraction. This count is neither too thin nor bloated for the domain.
The toolset provides strong coverage for core DOCX processing needs, including analysis, conversion, and extraction. A minor gap exists in editing or modification capabilities (e.g., update_content or merge_documents), but agents can work around this by using the conversion tools to intermediate formats. The surface is largely complete for reading and transforming DOCX files.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Document-to-Markdown MCP server — convert PDF, Office and HTML into LLM-ready Markdown.
Hosted MCP server: convert PDFs to clean, LLM-ready Markdown with tables, formulas and OCR.
Use your own Word templates to convert Markdown → DOCX/PDF/HTML from any MCP-compatible AI.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/zeph-gh/Docx-Mcp-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
