Skip to main content
Glama
jackdark425

AI Group Markdown to Word MCP Server

by jackdark425
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

AI Group Markdown to Word MCP Server

License: MIT Node.js MCP Protocol Version

Professional Markdown-to-Word conversion over MCP, with advanced styling, tables, formulas, images, Mermaid rendering, and HTTP deployment support.

Overview

aigroup-mdtoword-mcp is an MCP server for generating professional .docx documents from Markdown content.

It is designed for:

  • converting Markdown into structured Word documents

  • applying reusable templates and styling presets

  • rendering tables, formulas, images, and Mermaid diagrams

  • exposing both MCP and simplified HTTP endpoints

  • integrating with Claude Desktop and other MCP-compatible clients

Related MCP server: mdmagic-mcp-server

Highlights

  • Markdown to DOCX conversion with document styling and layout control

  • Advanced formatting for headings, tables, lists, code blocks, and blockquotes

  • Math support for inline and block formulas

  • Image embedding for local and remote assets

  • Mermaid rendering with safe fallback to code blocks

  • Header / footer / page numbering / watermark support

  • Template, resource, and prompt support for guided usage

  • HTTP deployment options including Cloudflare Worker workflows

Quick Start

Requirements

  • Node.js >= 18

  • npm >= 8

Run with npx

npx -y aigroup-mdtoword-mcp

Install locally

git clone https://github.com/jackdark425/aigroup-mdtoword-mcp.git
cd aigroup-mdtoword-mcp
npm install
npm run build
npm start

MCP Client Configuration

Claude Desktop / compatible MCP clients

{
  "mcpServers": {
    "markdown-to-word": {
      "command": "npx",
      "args": ["-y", "aigroup-mdtoword-mcp"]
    }
  }
}

Local build output

{
  "mcpServers": {
    "markdown-to-word": {
      "command": "node",
      "args": ["/path/to/aigroup-mdtoword-mcp/dist/index.js"]
    }
  }
}

Tools

markdown_to_docx

Converts Markdown content or a Markdown file into a .docx document.

Typical inputs include:

  • markdown

  • inputPath

  • filename

  • outputPath

  • styleConfig

table_data_to_markdown

Converts CSV or JSON tabular data into formatted Markdown tables.

Typical inputs include:

  • data

  • format

  • style

  • hasHeader

Resources

Templates

  • template://customer-analysis

  • template://academic

  • template://business

  • template://technical

  • template://minimal

Style Guides

  • style-guide://quick-start

  • style-guide://advanced

  • style-guide://templates

Metrics

  • metrics://conversion-stats

  • metrics://memory-usage

Styling Capabilities

The styling system supports:

  • document-level fonts, colors, and page layout

  • heading and paragraph styles

  • table presets and formatting

  • image sizing and placement

  • code block styling

  • headers, footers, page numbers, and watermarks

Included table styles cover common business, academic, financial, technical, and minimal report layouts.

Example

# Project Report

## Executive Summary
This is a sample report with **bold text** and *italic text*.

- Feature 1: Complete Markdown support
- Feature 2: Advanced styling system
- Feature 3: Professional document layout

| Column 1 | Column 2 | Column 3 |
|----------|----------|----------|
| Data 1   | Data 2   | Data 3   |
| Data 4   | Data 5   | Data 6   |

Mathematical formula: $E = mc^2$

```mermaid
flowchart TD
  A[Start] --> B{Check input}
  B -->|Valid| C[Generate DOCX]
  B -->|Invalid| D[Return error]
```

Deployment

HTTP server

npm run server:http

Cloudflare Worker

npm install -g wrangler
wrangler login
wrangler deploy

Related endpoints typically include:

  • /health

  • /mcp

  • /convert

  • /.well-known/ai-plugin.json

  • /openapi.yaml

  • /openapi.json

See detailed guidance in docs/DEPLOYMENT_INSTRUCTIONS.md.

Project Structure

src/
├── index.ts
├── converter/
├── template/
├── types/
└── utils/

Development

npm run build
npm test

Additional test commands:

  • npm run test:math

  • npm run test:images

  • npm run test:pages

  • npm run test:mermaid

License & Usage

This project is released under the MIT License.

In practical terms, MIT allows you to:

  • use this project in personal, internal, academic, or commercial scenarios

  • copy, modify, merge, publish, and distribute the code

  • build proprietary or open-source products on top of it

  • ship derivative works as long as the required copyright and license notice is preserved

Please keep in mind:

  • you must retain the original copyright notice and MIT license text in copies or substantial portions of the software

  • the software is provided "AS IS", without warranty of any kind

  • if you package this project into hosted services, desktop tools, plugins, or internal workflows, you are responsible for your own compliance, security review, and downstream usage constraints

See the full text in LICENSE.

Acknowledgments

Core Dependencies & Ecosystem

Community Inspiration

  • Inspired by the broader MCP community and ecosystem

Support

Available Tools

4 tools
create_table_from_csv从CSV创建表格B

将CSV数据转换为可用于文档的表格数据

ParametersJSON Schema
NameRequiredDescriptionDefault
csvDataYesCSV格式的数据
hasHeaderNo第一行是否为表头
delimiterNo分隔符,
styleNameNo表格样式名称minimal

Output Schema

ParametersJSON Schema
NameRequiredDescription
previewYes
successYes
rowCountYes
styleNameYes
columnCountYes

TDQS

B3.1/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 fully disclose behavioral traits. It states the tool converts CSV data to table data for documents, implying a transformation or creation operation, but lacks details on permissions, side effects, error handling, or output format. While the output schema exists, the description doesn't add behavioral context beyond the basic function, leaving gaps in understanding how the tool behaves in practice.

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 a single, efficient sentence: '将CSV数据转换为可用于文档的表格数据'. It is front-loaded with the core purpose, has no redundant words, and is appropriately sized for the tool's complexity. Every part of the sentence contributes to understanding the tool's function.

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

Completeness3/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 (4 parameters, no annotations, but with an output schema), the description is minimally adequate. It states what the tool does but lacks behavioral details, usage guidelines, and parameter insights. The presence of an output schema means return values are documented elsewhere, so the description doesn't need to cover that. However, for a tool with no annotations, more context on behavior and usage would improve completeness.

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 description does not mention any parameters, focusing only on the overall function. However, the input schema has 100% description coverage, with clear documentation for all four parameters (csvData, hasHeader, delimiter, styleName). Since the schema provides comprehensive parameter information, the baseline score is 3, as the description adds no extra semantic value but doesn't need to compensate for schema gaps.

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's purpose: '将CSV数据转换为可用于文档的表格数据' (Convert CSV data into table data that can be used in documents). It specifies the verb 'convert' and the resource 'CSV data', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_table_from_json', which would be needed for a score of 5.

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. It doesn't mention sibling tools such as 'create_table_from_json' or 'list_table_styles', nor does it specify prerequisites or contexts for usage. This lack of comparative or contextual information limits its helpfulness for an AI agent.

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

create_table_from_json从JSON创建表格B

将JSON数组数据转换为可用于文档的表格数据

ParametersJSON Schema
NameRequiredDescriptionDefault
jsonDataYesJSON格式的数据（数组）
columnsNo要包含的列名（可选，默认全部）
styleNameNo表格样式名称minimal

Output Schema

ParametersJSON Schema
NameRequiredDescription
previewYes
successYes
rowCountYes
styleNameYes
columnCountYes

TDQS

B3.1/5.0
Behavior2/5

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 the conversion action but doesn't describe what happens during processing: whether the transformation preserves all data, how errors are handled, what the output format looks like, or any performance characteristics. For a data transformation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.

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 a single, efficient sentence that directly states the tool's core function without unnecessary words. It's appropriately sized for a straightforward data transformation tool and gets straight to the point about what the tool accomplishes.

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

Completeness3/5

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

Given that an output schema exists, the description doesn't need to explain return values. However, for a data transformation tool with no annotations, the description should provide more context about the transformation process, error handling, and output characteristics. The current description is minimal but functional - adequate for the basic purpose but lacking depth for confident usage.

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 description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema - it mentions JSON array data generally but doesn't elaborate on format requirements, validation rules, or usage examples. With complete schema documentation, the baseline score of 3 is appropriate.

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's purpose: converting JSON array data into table data for documents. It specifies both the input (JSON array) and output (table data), making the verb+resource relationship explicit. However, it doesn't distinguish this tool from its sibling 'create_table_from_csv', which performs a similar conversion from a different data format.

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. There's no mention of when this tool is appropriate versus 'create_table_from_csv' for CSV data, 'list_table_styles' for style information, or 'markdown_to_docx' for document conversion. The description only states what the tool does, not when to choose it.

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

list_table_styles列出表格样式B

获取所有可用的预定义表格样式

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
countYes
stylesYes

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It states this is a retrieval operation ('获取'), implying it's likely read-only and non-destructive, but doesn't explicitly confirm safety aspects. It doesn't disclose behavioral traits like rate limits, authentication needs, response format, or whether it returns all styles at once. The description adds minimal value beyond the basic purpose.

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 a single, efficient sentence in Chinese that directly states the tool's purpose without any fluff or redundancy. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place.

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

Completeness3/5

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

Given the tool's simplicity (0 parameters, output schema exists), the description is adequate but minimal. It covers the basic purpose but lacks context about the returned data (e.g., format, scope of 'all') and behavioral details. With no annotations and an output schema, the description should ideally hint at what the output contains, but it doesn't. It meets minimum viability for a simple retrieval tool.

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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is applied for tools with zero parameters, as the description correctly avoids unnecessary parameter explanations.

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's purpose with a specific verb ('获取' meaning 'get') and resource ('预定义表格样式' meaning 'predefined table styles'). It distinguishes this as a retrieval operation rather than a creation or conversion tool like its siblings (create_table_from_csv, create_table_from_json, markdown_to_docx). However, it doesn't explicitly differentiate from potential similar 'get' operations that might exist elsewhere.

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. It doesn't mention prerequisites, timing considerations, or how it relates to sibling tools (e.g., whether these styles are used by the creation tools). The agent must infer usage from the purpose alone.

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

markdown_to_docxMarkdown 转 WordB

将Markdown文档转换为Word文档（DOCX格式），支持样式配置、模板系统和多种图像嵌入方式（本地文件、网络图片、Base64编码）

ParametersJSON Schema
NameRequiredDescriptionDefault
markdownNoMarkdown格式的文本内容（与inputPath二选一）
inputPathNoMarkdown文件路径（与markdown二选一）
filenameYes输出的Word文档文件名，必须以.docx结尾
outputPathNo输出目录，默认为当前工作目录
templateNo模板配置。使用预设模板可以快速应用专业样式，也可以与styleConfig组合使用
styleConfigNo样式配置对象。支持主题系统（theme）、水印（watermark）、页眉页脚（headerFooter）、自动目录（tableOfContents）、表格样式（tableStyles）、图片样式（imageStyles）等。可与template组合使用以覆盖模板的默认样式

Output Schema

ParametersJSON Schema
NameRequiredDescription
pathYes
sizeYes
messageNo
successYes
filenameYes

TDQS

B3.3/5.0
Behavior2/5

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 support for style configuration, templates, and image embedding, but lacks critical behavioral details such as whether this is a read-only or destructive operation, error handling, performance characteristics, or output location behavior. For a complex conversion tool, this is a significant gap.

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 extremely concise - a single sentence that efficiently communicates the core functionality and key features. Every word earns its place, with no redundant information. The structure is front-loaded with the primary purpose followed by supporting features.

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

Completeness3/5

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

Given the tool's complexity (6 parameters, nested objects) and the presence of an output schema, the description is moderately complete. It covers the basic conversion purpose and mentions key features, but lacks guidance on usage scenarios, behavioral constraints, and parameter interactions. The output schema reduces the need to describe return values, but more context about the tool's operation would be helpful.

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 description adds minimal parameter semantics beyond the schema. It mentions 'style configuration, template system, and multiple image embedding methods' which loosely maps to the 'styleConfig', 'template', and image handling capabilities, but doesn't explain parameter interactions or provide usage examples. With 100% schema description coverage, the baseline is 3 as the schema does most of the documentation work.

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 specific verb ('convert') and resource ('Markdown document to Word document'), specifying the output format (DOCX). It distinguishes from siblings by focusing on document conversion rather than table creation or listing operations, making the purpose unambiguous and well-defined.

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. It does not mention prerequisites, constraints, or scenarios where this conversion is appropriate compared to other document processing tools. Usage context is implied but not explicitly stated.

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

A3.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: two tools convert different data formats (CSV and JSON) to tables, one lists available styles, and one converts Markdown to DOCX. There is no overlap or ambiguity between these functions, making tool selection straightforward for an agent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case (e.g., create_table_from_csv, markdown_to_docx). The naming is predictable and readable, with no deviations in style or convention across the set.

Tool Count5/5

With 4 tools, this server is well-scoped for its purpose of converting data and Markdown to Word documents. Each tool earns its place by covering distinct aspects of the workflow, avoiding bloat or thinness in functionality.

Completeness4/5

The tool set covers core operations for the domain: data conversion (CSV/JSON to tables), style management, and Markdown-to-DOCX conversion. A minor gap exists in lacking direct table manipulation or editing tools, but agents can work around this by using the provided tools in sequence.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Appeared in Searches

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/jackdark425/aigroup-mdtoword-mcp'

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