How do I use mcp-server-docx?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-server-docx Create a Word document at /tmp/test.docx from this markdown: # Hello World" 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.

mcp-server-docx

by jamesmehorter

Overview Schema Related Servers Score Discussions

TypeScript

Local

Word Document MCP Server

A fast, TypeScript-based MCP server for creating professional Word documents from markdown or structured content.

🚀 Markdown-First Workflow - Just write natural markdown and get professional Word documents in ~300ms!

Quick Setup

Download index.js from Releases and save to ~/mcp-servers/docx/index.js
Configure Claude Desktop - edit claude_desktop_config.json:
- macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
- Windows: %APPDATA%\Claude\claude_desktop_config.json
```
{
  "mcpServers": {
    "mcp-server-docx": {
      "command": "node",
      "args": ["/Users/YOUR_USERNAME/mcp-servers/docx/index.js"]
    }
  }
}
```
Replace the path with where you saved the file (Windows: use C:\\Users\\... with double backslashes)
Restart Claude Desktop
Test by asking Claude:

Create a Word document at /tmp/test.docx from this markdown:

# Hello World

This is my **first** Word document with *markdown*!

## Features
- Easy to use
- Fast generation
- Professional formatting

You should get a properly formatted Word document at /tmp/test.docx!

git clone <repository-url>
cd mcp-server-docx
nvm install && npm install && npm run build

Use dist/index.js in your Claude config instead of the downloaded bundle.

Related MCP server: Word MCP Server

Features

🎯 Pure Markdown Mode (Recommended)

The simplest way to create Word documents - just write natural markdown like you always do!

Just tell Claude what you want in plain markdown syntax:

Create a Word document at /tmp/my-resume.docx from this markdown:

# JANE SMITH
jane@example.com | (555) 123-4567

## PROFESSIONAL SUMMARY

I am a **senior software engineer** with *10+ years* of experience building scalable web applications.

> "Jane is an exceptional technical leader and mentor." — Former Manager

## SKILLS

- Expert in **TypeScript**, **React**, and **Node.js**
- Strong experience with **AWS** cloud architecture
- Passionate about **clean code** and **best practices**

---

## WORK EXPERIENCE

### Senior Engineer at Tech Corp (2020-Present)

Key achievements:

1. Designed and implemented **microservices architecture**
2. Reduced system latency by *40%*
3. Mentored team of 5 junior engineers

### Software Engineer at Startup Inc (2015-2020)

- Built MVP from scratch using **React** and **TypeScript**
- Implemented REST API with **Express** and **PostgreSQL**

What you get:

✅ Professional Word document in ~300ms
✅ Proper heading styles with borders (H1, H2)
✅ Bold and italic formatting
✅ Bulleted and numbered lists
✅ Block quotes formatted in italics
✅ Horizontal rules handled automatically
✅ Proper spacing between sections
✅ Times New Roman font (professional default)

Supported Markdown:

# ## ### Headings (H1/H2 get bottom borders)
**bold** and *italic* inline formatting
[text](url) for clickable hyperlinks
- or * for bullet lists
1. 2. for numbered lists
> quote for block quotes (rendered in italics)
--- *** ___ horizontal rules (rendered as lines)
Empty lines for spacing between sections

Behind the scenes: Uses create_document_from_markdown tool

🎨 Custom Styling for Markdown

Want Helvetica instead of Times New Roman? Different font sizes? - Easily customize the appearance!

You can override the default styles by passing a styles object:

Create a Word document at /tmp/my-resume.docx from this markdown:

# JANE SMITH
## Professional Summary
I am a senior engineer.

Use these custom styles:
- All headings should be Helvetica
- H1 should be 36pt bold without bottom border
- H2 should be 24pt bold with bottom border
- Paragraphs should be Arial 12pt

Style options by element:

heading1, heading2, heading3, heading4 - Control heading appearance
paragraph - Regular paragraph text
bullets - Bulleted list items
ordered - Numbered list items
blockquote - Block quote text (from > quote)

Each element can have:

fontName - Font family (e.g., "Helvetica", "Arial", "Times New Roman")
fontSize - Font size in points (e.g., 12, 14, 36)
bold - Bold text (true/false)
italic - Italic text (true/false)
color - Text color as hex RGB (e.g., "FF0000")
borderBottom - Bottom border for headings (true/false)

Example styles object:

styles: {
  heading1: { fontName: 'Helvetica', fontSize: 36, bold: true, borderBottom: false },
  heading2: { fontName: 'Helvetica', fontSize: 24, bold: true, borderBottom: true },
  heading3: { fontName: 'Helvetica', fontSize: 18, bold: true },
  paragraph: { fontName: 'Arial', fontSize: 12 },
  bullets: { fontName: 'Arial', fontSize: 12 },
  ordered: { fontName: 'Arial', fontSize: 12 },
  blockquote: { fontName: 'Georgia', fontSize: 12, italic: true }
}

Default styles (used when you don't provide custom styles):

Headings: Times New Roman, bold, H1=24pt, H2=18pt, H3/H4=14/12pt
H1/H2: Bottom borders, H3/H4: No borders
Paragraphs/Lists: Times New Roman, 12pt
Blockquotes: Times New Roman, 12pt, italic

Pro tip: You only need to specify the elements/properties you want to change! Unspecified elements use the defaults.

⚡ Batch Mode with Structured Content

For when you need fine-grained control - specify exact fonts, sizes, and colors

Use this when markdown isn't flexible enough and you need precise control over formatting:

Create a resume at /tmp/my-resume.docx using create_document_from_content.

Make the name "JANE SMITH" in Helvetica 36pt bold.
Add a "PROFESSIONAL SUMMARY" H2 heading with a bottom border in Helvetica 14pt.
Add a paragraph about my experience in Times New Roman 12pt.
Add a "SKILLS" H2 heading with a bottom border.
Add bullet points for my skills in Times New Roman 12pt.

Example structure:

content: [
  {
    text: 'JANE SMITH', // defaults to paragraph type
    format: { fontName: 'Helvetica', fontSize: 36, bold: true },
  },
  { text: '' }, // empty paragraph for spacing
  {
    type: 'heading',
    text: 'PROFESSIONAL SUMMARY',
    format: { level: 2, borderBottom: true },
  },
  {
    text: 'Software engineer with 10+ years experience...',
    format: { fontName: 'Times New Roman', fontSize: 12 },
  },
  {
    type: 'bullets',
    items: ['TypeScript & React', 'Node.js & Python', 'AWS & Docker'],
    format: { fontName: 'Times New Roman', fontSize: 12 },
  },
];

Content item options:

type: 'paragraph' (default), 'heading', 'bullets', 'ordered'
text: For paragraphs and headings (use '' for spacing)
items: Array of strings for lists
format: fontName, fontSize, bold, italic, color, level (headings), borderBottom (headings)

Behind the scenes: Uses create_document_from_content tool

📝 Using Markdown Formatting in Structured Content

You can use markdown-style formatting even in structured mode!

Both the pure markdown approach and structured content support inline **bold** and *italic* formatting:

// Markdown formatting works in any text field:
{
  text: 'Led **4-engineer team** building *next-gen platform*',
  format: { fontSize: 12 }
}

// Also works in list items:
{
  type: 'bullets',
  items: [
    'Expert in **TypeScript** and **React**',
    'Passionate about *clean code* and *best practices*'
  ]
}

This gets automatically converted to proper Word formatting with bold and italic runs.

Contributing & Local Development

Installation

git clone <repository-url>
cd mcp-server-docx
nvm install  # Use the correct Node.js version from .nvmrc
npm install
npm run build

Creating a Release

This project uses automated GitHub releases. See RELEASING.md for details.

Quick summary:

Update version in package.json (e.g., npm version patch)
Create PR and merge to main
GitHub Actions automatically creates a release with the bundled index.js

The release workflow only triggers on changes to:

src/** (excluding tests)
package.json
package-lock.json

Testing

Comprehensive test suite with 54 tests powered by Vitest:

npm test              # Run tests once
npm run test:watch    # Watch mode with fast HMR
npm run test:coverage # Coverage report
npm run test:ui       # Visual UI mode

Test coverage:

Markdown parsing (headings, lists, block quotes, horizontal rules, inline formatting, links)
Auto-session creation
Paragraph, heading, and list formatting
Link support in paragraphs, headings, and lists
Horizontal rule rendering
Color formatting for all element types
Batch document creation
Error handling
Complex multi-section documents
Spacing between elements

Performance: All 54 tests complete in ~400ms

Code Quality

npm run lint         # Run ESLint (fails on warnings)
npm run lint:fix     # Auto-fix linting issues
npm run format       # Format code with Prettier
npm run format:check # Check formatting (CI)
npm run typecheck    # TypeScript type checking
npm run ci           # Run all checks (lint + format + test + typecheck)

Standards:

TypeScript with strict mode
ESLint (no warnings allowed)
Prettier (single quotes, 2-space indent, 100 char width)
GitHub Actions CI on all PRs

Project Structure

mcp-server-docx/
├── src/
│   ├── __tests__/
│   │   ├── document-manager.test.ts  # Document management tests
│   │   └── markdown-parser.test.ts   # Markdown parsing tests
│   ├── index.ts              # MCP server implementation
│   ├── document-manager.ts   # Core document logic
│   ├── markdown-parser.ts    # Markdown to content converter
│   └── types.ts              # TypeScript type definitions
├── dist/                     # Compiled JavaScript
├── vitest.config.ts          # Test configuration
├── package.json
├── tsconfig.json
└── README.md

Performance & Architecture

Key Performance Metrics:

Single document creation: ~300ms
Full resume (batch mode): ~300ms vs 3-5s (incremental) vs ~35s (Python)
100x faster than Python implementation
20-30x fewer MCP calls (1 batch call vs 20-30 incremental)

Design Principles:

Batch Operations - Create entire documents in a single MCP call
In-Memory Storage - Documents stored in memory until save (eliminates file I/O overhead)
Auto-Session Creation - No explicit initialization needed, start adding content immediately
Smart Markdown Parsing - Single-pass parsing with inline **bold**/*italic* support
Default Styling - Times New Roman applied automatically for professional appearance
Type Safety - Full TypeScript definitions for correctness

Future Enhancements

Tables and images
Custom style definitions
Headers, footers, and page breaks
Search & replace functionality

License

ISC

Author

James Mehorter

Acknowledgments

This project is built on two excellent open source libraries:

Document Generation: docx

docx.js.org | GitHub - A powerful library for generating Word documents (.docx files) in JavaScript/TypeScript. This MCP server wouldn't be possible without the solid foundation that docx provides for creating and manipulating Office Open XML documents.

Markdown Parsing: remark

remark.js.org | GitHub - A robust markdown processor powered by plugins, part of the unified collective. Remark's standards-compliant parsing ensures accurate conversion of markdown to Word documents.

Thanks to:

Dolan Miu and all contributors to the docx library
Titus Wormer and the unified collective for remark
The Anthropic team for building the Model Context Protocol and Claude Code
The open source community for making tools like this possible

Available Tools

7 tools

add_bullet_listC

Add a bulleted list

ParametersJSON Schema

Name	Required	Description	Default
`filename`	Yes
`items`	Yes
`font_name`	No
`font_size`	No

TDQS

C2.1/5.0

Behavior2/5

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

No annotations provided, so the description carries full burden. It only states 'add' without disclosing whether the list appends or overwrites, what happens to the document, or any side effects. No behavioral traits beyond the action are revealed.

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

Conciseness3/5

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

The description is very concise (one short phrase), but it sacrifices necessary detail. For a tool with 4 parameters and no annotations, this level of conciseness is under-specification rather than efficient communication. Every sentence should earn its place, but here the single sentence is insufficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters, no output schema, and no annotations, the description is completely inadequate. It does not specify preconditions (e.g., does the document exist?), postconditions, or return values. The agent lacks critical context to use this tool safely or correctly.

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

Parameters1/5

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

Schema description coverage is 0% and the description adds no meaning to parameters. It does not explain that 'items' are the bullet points, nor the purpose of 'font_name' and 'font_size'. With 4 parameters (2 required), the agent receives no guidance on how to use them effectively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Add a bulleted list' is clear but vague. It does not specify the context (e.g., adding to a document) or distinguish from siblings like 'add_heading' or 'add_paragraph' sufficiently. With sibling names suggesting document operations, the purpose is implied but not explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description lacks context for when a bulleted list is appropriate compared to headings, paragraphs, or other list types. No explicit exclusions or recommendations.

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

add_headingC

Add a heading with optional formatting

ParametersJSON Schema

Name	Required	Description
`filename`	Yes
`text`	Yes
`level`	No	Heading level 1-9
`font_name`	No
`font_size`	No
`bold`	No
`border_bottom`	No	Add bottom border

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only mentions 'optional formatting' without specifying how formatting works, side effects, or required permissions.

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

Conciseness3/5

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

The description is very short but lacks necessary information. It is concise but at the expense of completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters, no output schema, and no annotations, the description is severely incomplete. It omits insertion behavior, constraints, and return values, making it insufficient for an agent.

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

Parameters2/5

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

Schema description coverage is only 29% (2 of 7 parameters have descriptions). The description adds no parameter details beyond the schema, failing to compensate for the low coverage.

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 'Add a heading with optional formatting' clearly states the tool's action (adding a heading) and distinguishes it from sibling tools like add_paragraph and add_bullet_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidance is provided. The description does not explain when to use this tool versus alternatives like add_paragraph or when to set parameters like level.

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

add_paragraphC

Add a paragraph with optional formatting

ParametersJSON Schema

Name	Required	Description
`filename`	Yes
`text`	Yes
`font_name`	No	Font family (e.g., Helvetica, Times New Roman)
`font_size`	No	Font size in points
`bold`	No
`italic`	No
`color`	No	Hex RGB color (e.g., 000000)

TDQS

C2.6/5.0

Behavior2/5

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

Without annotations, the description must fully disclose behavioral traits. It implies mutation (adding to a document) but does not specify whether the paragraph is appended, inserted, or requires an existing file. No mention of side effects, permissions, or return values.

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

Conciseness3/5

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

The description is very concise (one phrase) but lacks structure or prioritization. It is not front-loaded with critical information, and the brevity results in under-specification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of 7 parameters, no output schema, and no annotations, the description is insufficiently complete. It does not explain the operation's effect, required preconditions, or output, leaving the agent with significant ambiguity.

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

Parameters2/5

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

The description only mentions 'optional formatting' without elaborating on the 7 parameters. Schema coverage is low (43%), and the description adds minimal value beyond the schema, failing to compensate for undocumented parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (Add) and resource (paragraph), and mentions optional formatting. However, it lacks specificity about the context (e.g., which document) and does not differentiate from siblings like add_heading or add_bullet_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as add_heading or add_bullet_list. The description does not mention prerequisites or context for usage.

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

create_documentC

Create a new Word document

ParametersJSON Schema

Name	Required	Description
`filename`	Yes	Path to save the document
`title`	No	Document title
`author`	No	Document author

TDQS

C2.7/5.0

Behavior1/5

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states 'Create a new Word document' without any details on side effects (e.g., overwrite behavior), required permissions, rate limits, or error conditions. This is critically insufficient for a tool that performs a side effect.

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 a single, concise sentence with no wasted words. However, it could be improved by front-loading key differentiators while maintaining brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tools have multiple siblings, no output schema, and no annotations, the description is incomplete. It does not explain return values, error handling, or how this tool fits into the workflow, making it hard for an AI agent to use correctly.

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 100% of parameters with descriptions, so the baseline is 3. The description adds no additional semantics beyond the schema; it simply repeats the creation action without furthering understanding of the parameters like 'title' or 'author'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a new Word document, specifying the verb 'create' and the resource 'Word document'. However, it fails to differentiate from sibling tools like create_document_from_content and create_document_from_markdown, which may also create Word documents, so the purpose is clear but not uniquely identified.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 such as create_document_from_content or create_document_from_markdown. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision support.

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

create_document_from_contentB

Create a complete Word document in a single call (FAST - use this instead of multiple calls)

ParametersJSON Schema

Name	Required	Description
`filename`	Yes	Path to save the document
`title`	No	Document title
`author`	No	Document author
`content`	Yes	Array of content items (paragraphs, headings, bullets)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, and the description only mentions speed and single-call nature. It does not disclose potential side effects, permissions, or behavior on existing files, leaving significant gaps.

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 very concise, with the key purpose and usage hint front-loaded. It could include more detail without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (nested content array, no output schema), the description is too brief. It lacks information on return values, error scenarios, or limitations, making it incomplete.

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?

Schema description coverage is 100%, so parameters are already well-documented. The description adds no extra parameter meaning beyond the schema, meeting the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a complete Word document in a single call, distinguishing it from piecemeal sibling tools like add_paragraph. However, it does not differentiate from other single-call creation tools like create_document or create_document_from_markdown.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises using this tool instead of multiple calls, providing some context for when to use it. But it lacks explicit guidance on when not to use it or alternatives like create_document_from_markdown.

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

create_document_from_markdownA

🚀 RECOMMENDED: Create a Word document from markdown text (MOST INTUITIVE - just write natural markdown!)

ParametersJSON Schema

Name	Required	Description
`filename`	Yes	Path to save the document
`markdown`	Yes	Markdown text supporting headings (# ## ###), paragraphs, lists (- or 1.), block quotes (>), horizontal rules (---), and inline formatting (bold, italic)
`title`	No	Document title
`author`	No	Document author
`styles`	No	Optional style overrides for markdown elements. Supports heading1-4, paragraph, bullets, ordered, blockquote. Each can have fontName, fontSize, bold, italic, color, borderBottom.

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavior. It only says 'Create a Word document' and implies ease, but fails to mention file overwriting, error handling, required permissions, or the returned document format.

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 a single sentence with no wasted words, but the use of emojis and emphasis is appropriate. It efficiently conveys purpose and recommendation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 5 parameters, nested objects, and no output schema. The description does not explain return values, error conditions, or how styles interact, leaving significant gaps for an agent to understand the full context.

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?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds only a brief note on markdown syntax, which is already in the schema. No additional meaning beyond baseline.

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 creates a Word document from markdown text and emphasizes it as the recommended, intuitive approach, distinguishing it from sibling tools like create_document and create_document_from_content.

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 phrase 'RECOMMENDED' and 'MOST INTUITIVE' provides clear context for when to use this tool over alternatives, but does not explicitly state when not to use it or list excluded scenarios.

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

save_documentC

Save the document to disk

ParametersJSON Schema

Name	Required	Description	Default
`filename`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description bears full burden. It only states 'save to disk' without disclosing overwrite behavior, file format, permissions, or return value. This is insufficient for a mutation operation.

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 a single concise sentence with no extraneous words. It is front-loaded but too brief to be fully useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite low complexity, the description lacks context about file handling (e.g., overwrite, error states) and output. It fails to fully compensate for the absence of annotations and schema descriptions.

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

Parameters1/5

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

Schema coverage is 0%, and the description adds no meaning to the 'filename' parameter. It does not explain format, path, or required conventions, leaving the agent to guess.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Save the document to disk' uses a clear verb and resource, distinguishing this save operation from sibling creation tools like create_document. However, it lacks specificity about which document is saved (e.g., current document).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites like having an open document or how it differs from creation tools.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, but the three document creation tools (create_document, create_document_from_content, create_document_from_markdown) overlap in function. Descriptions with 'FAST' and 'RECOMMENDED' help disambiguate, so agents can typically choose correctly.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with lowercase and underscores. Verbs like 'add_', 'create_', and 'save_' are used predictably, and 'create_document' variants share a common prefix. No mixing of conventions.

Tool Count5/5

With 7 tools, the server is well-scoped for creating Word documents. It covers creation, content addition (three common types), and saving. The three creation tools are justified by different input modes, and no tool feels superfluous.

Completeness3/5

The tool set covers basic document creation (create, add paragraphs/lists/headings, save) but lacks support for tables, images, hyperlinks, or more advanced formatting. The markdown tool partially compensates, but there are notable gaps for a document creation server.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mdmagic-mcp-server A
io.github.MDMagic-MCP
Use your own Word templates to convert Markdown → DOCX/PDF/HTML from any MCP-compatible AI.
Workplace & Productivity Developer Tools
102
netcafe-docflow A
com.ainetcafe
Markdown in, any format out. PDFs merged, split, watermarked. Runs on our own doc engines.
Developer Tools Documentation Access
131
DocRocket
io.github.Crash-ept
Generate on-brand proposals, reports, and contracts instantly. Auto-extracts brand from any URL.
Workplace & Productivity Content Management Systems
2
Unmarkdown
io.github.UnMarkdown
The document publishing layer for AI tools. Convert markdown to 6 destinations, 62 templates.
Developer Tools Content Management Systems App Automation
21

Related MCP Servers

docxtpl MCP Server
Developer Tools Content Management Systems
z1w2r3
A
license
Not graded
quality
D
maintenance
Enables Word document generation from templates using Jinja2 syntax and parsing of DOCX, PDF, and Excel files to extract structured content, metadata, and text.
Updated a year ago (2025-10-15 00:00 UTC)
16
1
MIT
Word MCP Server
Workplace & Productivity Content Management Systems Developer Tools
mndambuki
F
license
Not graded
quality
D
maintenance
Enables creation and management of Word documents from markdown content, with support for multiple templates and conversion of chat conversations to formatted Word documents.
Updated 9 months ago (2025-12-07 09:04 UTC)
Word Document MCP Server
Workplace & Productivity App Automation Developer Tools
bibash44
A
license
B
quality
D
maintenance
Enables AI assistants to create and manipulate Microsoft Word documents programmatically with support for rich text formatting, tables, lists, headings, and find-and-replace operations.
Updated a year ago (2025-10-09 17:13 UTC)
10
27
MIT
AI Group Markdown to Word MCP
Developer Tools Workplace & Productivity Content Management Systems
jackdark425
A
license
A
quality
C
maintenance
Converts Markdown documents to professional Word documents with advanced formatting capabilities including mathematical formulas, custom styling, tables, images, headers/footers, and watermarks.
Updated 4 months ago (2026-04-24 05:56 UTC)
4
98
13
MIT

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/jamesmehorter/mcp-server-docx'

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