What can you do with this server?

The document-converter-mcp server is a local-first MCP server for converting documents between Markdown, PDF, DOCX, and HTML formats using Pandoc and MarkItDown engines. Core Conversion Tools: * Markdown → PDF: Options for table of contents, page size (A4/Letter), themes, PDF engine (pdflatex, xelatex, lualatex, wkhtmltopdf, weasyprint, typst), CJK font support, and source sidecar preservation. * Markdown → DOCX: Options for table of contents and custom reference DOCX templates for styling. * Markdown → HTML: Options for standalone output, custom CSS, and self-contained single-file generation. * DOCX → Markdown: Uses Pandoc or MarkItDown, with image extraction, multiple Markdown flavors (GFM, CommonMark, Pandoc), and LLM-optimized output cleaning. * PDF → Markdown: Uses MarkItDown or Pandoc, with sidecar recovery to restore original Markdown from PDFs generated with preserveSource=true. * Batch Convert: Convert entire directories between formats (md/docx/pdf → md/docx/pdf/html) with recursive traversal, glob include/exclude filters, concurrency control, and dry-run mode. Additional Capabilities: * Environment Diagnostics (doctor tool): Check availability of Node.js, Pandoc, Python, MarkItDown, and PDF engines. * Workspace isolation: All file operations are confined to a configured directory, with path traversal prevention and sensitive file blocking. * No overwrite by default: Files are protected unless explicitly allowed. * cleanForLLM flag: Produces AI-friendly Markdown output across conversion tools. * Configuration file (.document-converter.json): Set workspace-level defaults overridable by tool arguments. * Structured JSON results: Consistent output format across all tools, including quality reports for PDF-to-Markdown conversions.

Which integrations are available for this server?

Allows converting Markdown to PDF using LaTeX engines such as pdflatex, xelatex, or lualatex. Allows converting Markdown to PDF using the Typst typesetting engine.

How do I use document-converter-mcp?

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., "@document-converter-mcp convert my report.pdf to markdown" 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.

document-converter-mcp

by guanweiqiang

Overview Schema Related Servers Score Discussions

TypeScript

Local

@lifeng688/document-converter-mcp

A local-first MCP server for converting documents between Markdown, PDF, DOCX, and HTML, with environment diagnostics and workspace-level configuration.

English: This project focuses on AI-friendly document conversion, not pixel-perfect layout reconstruction.
中文: 本项目重点是 AI 友好的文档转换，而不是像素级版式还原。

Features

7 conversion tools: Markdown <-> PDF, Markdown <-> DOCX, Markdown <-> HTML, PDF -> Markdown
doctor tool: Diagnose local environment (Node.js, Pandoc, Python, MarkItDown, PDF engines)
Configuration file: .document-converter.json for workspace-level defaults
Dual engine support: Pandoc (primary) + MarkItDown (enhanced PDF/DOCX extraction)
Safe file access: Workspace-isolated path validation, sensitive file blocking, no-overwrite-by-default
Secure command execution: Spawn-based, no shell injection, structured errors with timeouts
AI-friendly output: Optional cleanForLLM flag for cleaner Markdown
Batch processing: Convert entire directories with concurrency control, dry run, include/exclude filters
PDF style options: Margin, section numbering, syntax highlighting, metadata
HTML style options: Themes, embedded CSS, self-contained output, syntax highlighting
DOCX image extraction: Extract embedded images with metadata reporting
PDF sidecar recovery: Accurate Markdown restoration from PDFs generated with preserveSource: true
Structured results: Consistent JSON response format across all tools

Related MCP server: mcp-document-converter

Supported Formats

Source	Targets
Markdown (`.md`)	PDF, DOCX, HTML
DOCX (`.docx`)	Markdown
PDF (`.pdf`)	Markdown

Installation

Prerequisites

Node.js >= 18.0.0
Pandoc >= 3.0
Python 3 >= 3.8 (optional, for MarkItDown)

PDF Engine (required for Markdown -> PDF)

Pandoc can convert Markdown to PDF, but it requires an external PDF engine.

Engine	Install	Notes
`pdflatex` (default)	MiKTeX (Windows), TeX Live (Linux/macOS)	Most common, ~2 GB install
`xelatex`	TeX Live / MiKTeX	Recommended for Chinese/CJK documents
`lualatex`	TeX Live / MiKTeX	Lua-based LaTeX engine
`wkhtmltopdf`	`apt install wkhtmltopdf` / `brew install wkhtmltopdf`	Lightweight HTML-to-PDF engine
`weasyprint`	`pip install weasyprint`	Python-based HTML-to-PDF
`typst`	`cargo install typst`	Modern, fast typesetting system

Chinese documents: Use pdfEngine: "xelatex" with a TeX Live / MiKTeX installation that includes the ctex package.
Windows: cjkMainFont: "Microsoft YaHei"
macOS: cjkMainFont: "Songti SC"
Linux: cjkMainFont: "Noto Sans CJK SC"

Install Pandoc

macOS:

brew install pandoc

Ubuntu/Debian:

sudo apt-get update && sudo apt-get install -y pandoc

Windows: Download from https://pandoc.org/installing.html

Verify:

pandoc --version

Install MarkItDown (optional, recommended for PDF -> Markdown)

pip install markitdown

Verify:

python3 -c "import markitdown; print('ok')"

PDF support requires optional dependencies:
# For PDF extraction only:
python -m pip install -U "markitdown[pdf]"

# For DOCX extraction:
python -m pip install -U "markitdown[docx]"

# For all optional converters (PDF, EPUB, HTML, DOCX, etc.):
python -m pip install -U "markitdown[all]"
markitdown installed does not guarantee PDF or DOCX support is available.

Install the Server

npm install -g @lifeng688/document-converter-mcp

Or use directly via npx:

npx @lifeng688/document-converter-mcp

For development, clone the repo and build locally:

git clone https://github.com/guanweiqiang/document-convert-mcp.git
cd document-convert-mcp
npm install
npm run build

MCP Client Configuration

Install the package globally first:

npm install -g @lifeng688/document-converter-mcp

Claude Desktop

Edit your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, or %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "document-converter": {
      "command": "npx",
      "args": ["-y", "@lifeng688/document-converter-mcp"],
      "env": {
        "DOC_CONVERTER_WORKSPACE": "E:/MCPWorkDir"
      }
    }
  }
}

Or if installed globally, use the local path:

{
  "mcpServers": {
    "document-converter": {
      "command": "document-converter-mcp",
      "env": {
        "DOC_CONVERTER_WORKSPACE": "E:/MCPWorkDir"
      }
    }
  }
}

Sample configs are in examples/:

mcp.json -- MCP Inspector config
claude-desktop-config.json -- Claude Desktop config

Configuration File

Place .document-converter.json in your workspace root to set defaults for all tools.

Example:

{
  "defaults": {
    "pdfEngine": "xelatex",
    "cjkMainFont": "Microsoft YaHei",
    "pageSize": "A4",
    "theme": "github",
    "cleanForLLM": true,
    "overwrite": false
  },
  "batch": {
    "maxConcurrency": 2,
    "continueOnError": true
  },
  "security": {
    "maxFileSizeMB": 50
  }
}

Precedence:

tool args > .document-converter.json > built-in defaults

Notes:

The config file is read from the workspace root only (not nested directories).
Config values cannot bypass pathGuard -- paths must still be within the workspace.
overwrite defaults to false in the config for safety; do not set it to true unless intentional.
For Chinese/CJK PDF generation, recommended config:
- Windows: "pdfEngine": "xelatex", "cjkMainFont": "Microsoft YaHei"
- macOS: "pdfEngine": "xelatex", "cjkMainFont": "Songti SC"
- Linux: "pdfEngine": "xelatex", "cjkMainFont": "Noto Sans CJK SC"

Tools

1. `doctor`

Check the local environment for document-converter-mcp dependencies.

This tool never fails due to missing dependencies -- missing tools appear as false in the output with warnings.

Checks:

Node.js version
Workspace path, existence, writability
Pandoc availability and version
Python availability
MarkItDown availability and PDF support
PDF engines: pdflatex, xelatex, lualatex, wkhtmltopdf, weasyprint, typst
Recommendations for missing dependencies

Example output:

{
  "success": true,
  "summary": "Environment check completed.",
  "data": {
    "node": { "available": true, "version": "v22.18.0" },
    "workspace": { "path": "E:/MCPWorkDir", "exists": true, "writable": true },
    "pandoc": { "available": true, "version": "pandoc 3.8.2" },
    "python": { "available": true, "command": "python" },
    "markitdown": { "available": true, "pdfSupport": true },
    "pdfEngines": {
      "pdflatex": true,
      "xelatex": true,
      "lualatex": true,
      "wkhtmltopdf": false,
      "weasyprint": false,
      "typst": false
    },
    "recommendations": []
  },
  "warnings": [],
  "error": null
}

2. `markdown_to_pdf`

Convert Markdown to PDF using Pandoc.

Note: Pandoc requires an external PDF engine (LaTeX distribution or alternative) to generate PDFs.

中文文档：pdflatex 不支持中文 Unicode 字符。中文 Markdown 转 PDF 请使用 pdfEngine: "xelatex"（推荐）并设置 cjkMainFont。

Parameter	Type	Required	Default	Description
`inputPath`	string	Yes	--	Input Markdown file path (relative to workspace)
`outputPath`	string	No	Auto-derived	Output PDF path
`title`	string	No	--	PDF document title
`toc`	boolean	No	false	Include table of contents
`pageSize`	enum	No	A4	Page size: `A4` or `Letter`
`theme`	enum	No	default	Theme: `default`, `github`, `academic`
`pdfEngine`	enum	No	Pandoc default	PDF engine: `pdflatex`, `xelatex`, `lualatex`, `wkhtmltopdf`, `weasyprint`, `typst`
`cjkMainFont`	string	No	--	CJK main font for Chinese/Japanese/Korean documents (e.g. `"Microsoft YaHei"`, `"SimSun"`, `"Noto Sans CJK SC"`)
`preserveSource`	boolean	No	false	Save original Markdown as sidecar files (`sample.pdf.source.md`, `sample.pdf.meta.json`) for accurate PDF-to-Markdown recovery
`strictMarkdown`	boolean	No	false	Reject input if Markdown has structural issues like unclosed code blocks
`overwrite`	boolean	No	false	Allow overwriting existing files
`margin`	string	No	--	Page margin in safe format (e.g. `'1in'`, `'2cm'`, `'20mm'`, `'72pt'`)
`numberSections`	boolean	No	false	Number section headings in the PDF
`highlightStyle`	string	No	--	Code highlight theme: `default`, `tango`, `pygments`, `kate`, `monochrome`, `github`, `darkblue`, `emacs`, `friendly`, `fruity`, `native`, `trac`, `borland`
`metadata`	object	No	--	Additional metadata key-value pairs

Sidecar files (when preserveSource=true):

document.pdf.source.md -- Original Markdown content
document.pdf.meta.json -- Conversion metadata

3. `markdown_to_docx`

Convert Markdown to DOCX using Pandoc.

Parameter	Type	Required	Default	Description
`inputPath`	string	Yes	--	Input Markdown file path
`outputPath`	string	No	Auto-derived	Output DOCX path
`referenceDocx`	string	No	--	Word template file
`toc`	boolean	No	false	Include table of contents
`strictMarkdown`	boolean	No	false	Reject input if Markdown has structural issues
`overwrite`	boolean	No	false	Allow overwriting existing files

4. `docx_to_markdown`

Convert DOCX to Markdown using Pandoc or MarkItDown.

Parameter	Type	Required	Default	Description
`inputPath`	string	Yes	--	Input DOCX file path
`outputPath`	string	No	Auto-derived	Output Markdown path
`extractImages`	boolean	No	false	Extract embedded images from the DOCX
`imageDir`	string	No	Auto-derived	Directory for extracted images (must be within workspace). If omitted, defaults to `${outputBasename}_media`
`engine`	enum	No	pandoc	Engine: `pandoc` or `markitdown`
`markdownFlavor`	enum	No	gfm	Markdown dialect: `gfm` (GitHub Flavored), `commonmark`, or `pandoc`
`cleanForLLM`	boolean	No	false	Clean Markdown for AI consumption
`overwrite`	boolean	No	false	Allow overwriting existing files

Image extraction:

When extractImages=true, the response includes:

{
  "imageCount": 2,
  "imageDir": "out/document_media",
  "images": [
    {
      "filename": "media/image1.png",
      "sizeBytes": 12345
    }
  ]
}

Even if no images are found:

{
  "imageCount": 0,
  "imageDir": "out/document_media",
  "images": []
}

Supported image extensions: .png, .jpg, .jpeg, .gif, .webp, .svg, .bmp, .tif, .tiff.

Path safety: imageDir is validated against path traversal. Values like ../outside-media will be rejected with an error containing "Access denied" and "workspace".

5. `pdf_to_markdown`

Extract text from PDF to Markdown.

Warning: This is content extraction, not layout reconstruction. Scanned PDFs, complex tables, two-column papers, and mathematical formulas may not convert reliably. For scanned PDFs, OCR is required (not included).
PDF 转 Markdown 是内容提取，不是版式或语义结构还原。
普通 PDF 通常不保存 Markdown 语义。标题、表格、代码块、列表、阅读顺序都可能无法可靠恢复。

Parameter	Type	Required	Default	Description
`inputPath`	string	Yes	--	Input PDF file path
`outputPath`	string	No	Auto-derived	Output Markdown path
`engine`	enum	No	markitdown	Engine: `markitdown` or `pandoc`
`cleanForLLM`	boolean	No	false	Clean Markdown for AI consumption
`preferSourceSidecar`	boolean	No	true	First check for a `.source.md` sidecar file. If found, return original Markdown instead of extracting PDF text.
`overwrite`	boolean	No	false	Allow overwriting existing files

Sidecar recovery:

If the PDF was generated by this server with preserveSource: true, the original Markdown is available as sidecar files (document.pdf.source.md, document.pdf.meta.json). The default preferSourceSidecar: true will automatically find and return it.

Quality report:

Sidecar recovery mode:

{
  "quality": {
    "mode": "source-sidecar",
    "layoutPreserved": true,
    "headingsReliable": true,
    "tablesReliable": true,
    "codeBlocksReliable": true,
    "readingOrderReliable": true
  }
}

Plain text extraction mode:

{
  "quality": {
    "mode": "text-extraction",
    "layoutPreserved": false,
    "headingsReliable": false,
    "tablesReliable": false,
    "codeBlocksReliable": false,
    "readingOrderReliable": false
  }
}

6. `markdown_to_html`

Convert Markdown to HTML using Pandoc.

Parameter	Type	Required	Default	Description
`inputPath`	string	Yes	--	Input Markdown file path
`outputPath`	string	No	Auto-derived	Output HTML path
`cssPath`	string	No	--	External CSS file path (validated via workspace pathGuard)
`standalone`	boolean	No	true	Generate complete HTML document with head/body
`strictMarkdown`	boolean	No	false	Reject input if Markdown has structural issues
`overwrite`	boolean	No	false	Allow overwriting existing files
`theme`	string	No	--	Pandoc HTML theme: `default`, `github`, `academic`, `monochrome`, `bookish`, `mangoe`, `slaper`, `quarto`
`embedCss`	boolean	No	false	Embed CSS and resources into the HTML document
`selfContained`	boolean	No	false	Generate a self-contained single-file HTML
`highlightStyle`	string	No	--	Code highlight theme: `default`, `tango`, `pygments`, `kate`, `monochrome`, `github`, `darkblue`, `emacs`, `friendly`, `fruity`, `native`, `trac`, `borland`

theme=github is ideal for README-style documentation. embedCss=true embeds CSS directly into the HTML. selfContained=true produces a single HTML file with all resources inline.

7. `batch_convert`

Convert all matching files in a directory from one format to another.

Parameter	Type	Required	Default	Description
`inputDir`	string	Yes	--	Source directory (relative to workspace)
`outputDir`	string	Yes	--	Destination directory (relative to workspace)
`from`	enum	Yes	--	Source format: `md`, `markdown`, `docx`, `pdf`
`to`	enum	Yes	--	Target format: `md`, `markdown`, `docx`, `pdf`, `html`
`recursive`	boolean	No	false	Traverse subdirectories
`overwrite`	boolean	No	false	Overwrite existing files
`cleanForLLM`	boolean	No	false	Clean Markdown output for LLM consumption
`dryRun`	boolean	No	false	Generate a conversion plan without writing files
`include`	string[]	No	--	Only convert files matching these glob patterns (e.g. `["report-*.md"]`)
`exclude`	string[]	No	--	Skip files matching these glob patterns (e.g. `["draft-*"]`)
`maxConcurrency`	number	No	1	Max concurrent conversions (1-8). Useful for low-memory machines.
`continueOnError`	boolean	No	true	Continue processing other files when one fails

Dry run example:

{
  "inputDir": "docs/source",
  "outputDir": "docs/published",
  "from": "md",
  "to": "pdf",
  "dryRun": true
}

Returns a plan with plannedCount but does not write any files.

Return structure:

{
  "success": true,
  "summary": "Batch conversion completed: 4 succeeded, 0 failed, 0 skipped.",
  "total": 4,
  "plannedCount": 4,
  "skippedCount": 0,
  "successCount": 4,
  "failedCount": 0,
  "durationMs": 1201,
  "results": [...]
}

Usage Examples

Run doctor

Tool: doctor
Args: {}

Create `.document-converter.json`

{
  "defaults": {
    "pdfEngine": "xelatex",
    "cjkMainFont": "Microsoft YaHei",
    "overwrite": false
  }
}

Markdown to Chinese PDF using config

With .document-converter.json setting pdfEngine: "xelatex" and cjkMainFont: "Microsoft YaHei":

Tool: markdown_to_pdf
Args: {
  "inputPath": "docs/chinese-report.md",
  "title": "季度报告",
  "toc": true,
  "pageSize": "A4",
  "preserveSource": true,
  "overwrite": true
}

Markdown to PDF with `preserveSource`

Tool: markdown_to_pdf
Args: {
  "inputPath": "docs/report.md",
  "outputPath": "docs/report.pdf",
  "preserveSource": true,
  "overwrite": true
}

Generates docs/report.pdf.source.md and docs/report.pdf.meta.json for accurate recovery.

PDF to Markdown using source sidecar

Tool: pdf_to_markdown
Args: {
  "inputPath": "docs/report.pdf",
  "preferSourceSidecar": true
}

Automatically finds and returns the original Markdown from the sidecar file.

Markdown to HTML with GitHub theme

Tool: markdown_to_html
Args: {
  "inputPath": "docs/readme.md",
  "theme": "github",
  "standalone": true,
  "selfContained": true
}

Batch convert with dry run

Tool: batch_convert
Args: {
  "inputDir": "docs/articles",
  "outputDir": "docs/html",
  "from": "md",
  "to": "html",
  "dryRun": true
}

Batch convert with include/exclude

Tool: batch_convert
Args: {
  "inputDir": "docs/articles",
  "outputDir": "docs/published",
  "from": "md",
  "to": "pdf",
  "recursive": true,
  "include": ["report-*.md"],
  "exclude": ["draft-*", "internal-*"],
  "maxConcurrency": 2,
  "continueOnError": true,
  "overwrite": true
}

DOCX to Markdown with image extraction

Tool: docx_to_markdown
Args: {
  "inputPath": "docs/presentation.docx",
  "extractImages": true,
  "imageDir": "docs/presentation_media",
  "overwrite": true
}

Returns imageCount, imageDir, and images array in the response.

Security

This server implements strict security measures:

Workspace isolation: All file access is confined to a configured workspace directory (DOC_CONVERTER_WORKSPACE env var)
Path traversal prevention: .. sequences and absolute path escapes are blocked
Sensitive file blocking: .env, .ssh/, .npmrc, etc. are never accessible
File size limits: Input files over 50 MB are rejected by default (configurable via config file)
No shell injection: All commands use spawn() with argument arrays
No overwrite by default: Existing files are protected unless explicitly allowed
Config file cannot bypass pathGuard: Configuration defaults respect the same path safety rules as tool arguments

See docs/security.md for full details.

Recommended Workflows

Good

Markdown -> PDF -- High-quality PDF output with Pandoc
Markdown -> DOCX -- High-quality Word output
Markdown -> HTML -- High-quality HTML output
DOCX -> Markdown -- Good text extraction with image metadata
PDF -> Markdown -- For text extraction only. Use preferSourceSidecar: true for PDFs generated by this server.

Not recommended

Markdown -> PDF -> Markdown for structure recovery
- PDFs do not preserve Markdown semantics (headings, tables, code blocks, lists, reading order)
- The round-trip will lose structural information
- Use preserveSource: true instead when generating the PDF

Conversion Quality

This project focuses on AI-friendly document conversion, not pixel-perfect layout reconstruction.

See docs/conversion-quality.md for format-specific quality notes and engine comparisons.

Development

# Install dependencies
npm install

# Build TypeScript
npm run build

# Run in development mode (hot reload)
npm run dev

# Type check without emitting
npm run typecheck

License

MIT

Available Tools

6 tools

batch_convertBatch Convert DocumentsB

Read-only

Convert all matching files in a directory from one format to another. Individual file failures do NOT abort the entire batch. Arguments:

inputDir (string, required): Source directory (relative to workspace)
outputDir (string, required): Destination directory (relative to workspace)
from (enum, required): Source format — 'md', 'markdown', 'docx', or 'pdf'
to (enum, required): Target format — 'md', 'markdown', 'docx', 'pdf', or 'html'
recursive (boolean, optional): Traverse subdirectories. Defaults to false
overwrite (boolean, optional): Overwrite existing files. Defaults to false
cleanForLLM (boolean, optional): Clean Markdown output for LLM consumption

ParametersJSON Schema

Name	Required	Description
`inputDir`	Yes	Source directory path (relative to workspace)
`outputDir`	Yes	Destination directory path (relative to workspace)
`from`	Yes	Source file format
`to`	Yes	Target file format
`recursive`	No	Traverse subdirectories recursively
`overwrite`	No	Overwrite existing output files. Defaults to false.
`cleanForLLM`	No	Clean Markdown output for LLM consumption

TDQS

B3.3/5.0

Behavior1/5

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

Description contradicts annotations: 'Convert' implies mutation but readOnlyHint=true declares read-only. Also no mention of error handling beyond individual failures not aborting batch.

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?

Description is structured but verbose; parameter list duplicates schema content. Could be more concise while preserving key behavioral notes.

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?

Covers all seven parameters and highlights batch failure behavior, but lacks description of return values or error handling beyond individual failures, leaving some context incomplete.

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?

Schema coverage is 100%, but description adds meaning: clarifies paths are relative to workspace, lists allowable enum values, and specifies defaults for optional boolean 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 clearly states the verb 'Convert' and the resource 'all matching files in a directory', distinguishing it from sibling single-format conversion tools.

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 implies use for batch conversions but does not explicitly specify when to use this tool versus sibling single-file tools or mention any exclusions or prerequisites.

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

docx_to_markdownConvert DOCX to MarkdownA

Read-onlyIdempotent

Convert a DOCX file to Markdown format using Pandoc or MarkItDown. Arguments:

inputPath (string, required): Path to the input DOCX file
outputPath (string, optional): Output path. Defaults to same name with .md
extractImages (boolean, optional): Extract embedded images. Defaults to false
imageDir (string, optional): Directory to store extracted images
engine (enum, optional): Conversion engine — 'pandoc' or 'markitdown'. Defaults to 'pandoc'
markdownFlavor (enum, optional): Markdown dialect for Pandoc output — 'gfm', 'commonmark', or 'pandoc'. Defaults to 'gfm'
cleanForLLM (boolean, optional): Clean up the Markdown for LLM consumption. Defaults to false
overwrite (boolean, optional): Allow overwriting. Defaults to false

ParametersJSON Schema

Name	Required	Description
`inputPath`	Yes	Path to the input DOCX file (relative to workspace)
`outputPath`	No	Output Markdown path (relative to workspace). Auto-derived if omitted.
`extractImages`	No	Extract embedded images from the DOCX
`imageDir`	No	Directory to store extracted images (relative to workspace)
`engine`	No	Conversion engine to use
`markdownFlavor`	No	Markdown dialect for Pandoc output. Defaults to 'gfm'.
`cleanForLLM`	No	Clean up the Markdown output for LLM consumption
`overwrite`	No	Allow overwriting existing output file. Defaults to false.

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, but the description indicates writing output, contradicting readOnlyHint. However, the description discloses all defaults and parameter behaviors, adding value beyond annotations.

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 concise with a clear first sentence and a well-organized parameter list. It is efficient but could be more structured with separate sections.

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

Completeness4/5

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

Given 8 parameters, no output schema, and full schema coverage, the description covers all parameters with defaults. Lacks examples or error handling but sufficient for a conversion 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?

Schema coverage is 100%, but the description adds defaults for parameters like engine, markdownFlavor, overwrite, etc., providing extra semantics beyond the schema descriptions.

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 converts DOCX to Markdown, specifying the verb 'Convert' and the resources. It differentiates from siblings like pdf_to_markdown and markdown_to_docx.

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 does not provide explicit guidance on when to use this tool vs alternatives like batch_convert or when not to use it. It defaults to single file conversion without mention of batch processing.

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

markdown_to_docxConvert Markdown to DOCXB

Read-onlyIdempotent

Convert a Markdown file to DOCX (Word) format using Pandoc. Arguments:

inputPath (string, required): Path to the input Markdown file
outputPath (string, optional): Output path. Defaults to same name with .docx
referenceDocx (string, optional): Path to a reference DOCX template for styling
toc (boolean, optional): Include a table of contents in the DOCX
strictMarkdown (boolean, optional): If true, reject files with structural issues (unclosed code blocks). Defaults to false
overwrite (boolean, optional): Allow overwriting. Defaults to false

ParametersJSON Schema

Name	Required	Description
`inputPath`	Yes	Path to the input Markdown file (relative to workspace)
`outputPath`	No	Output DOCX path (relative to workspace). Auto-derived if omitted.
`referenceDocx`	No	Path to a reference DOCX template file for styling
`toc`	No	Include a table of contents in the DOCX. Defaults to false.
`strictMarkdown`	No	If true, reject input if Markdown has structural issues like unclosed code blocks.
`overwrite`	No	Allow overwriting existing output file. Defaults to false.

TDQS

B3.1/5.0

Behavior1/5

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

Annotations claim readOnlyHint=true, but the tool creates an output file, contradicting read-only behavior. Description does not clarify side effects, file creation, or error handling. Annotation contradiction detected.

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?

Purpose is front-loaded in a single sentence, followed by a structured parameter list. However, the list duplicates schema details and could be more succinct.

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?

Lacks return value details, error handling, or behavior on success/failure. With no output schema, agent has no information about what the tool returns.

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?

Schema coverage is 100%, but description adds defaults (e.g., 'Defaults to false' for toc, strictMarkdown, overwrite) and clarifies auto-derivation for outputPath, providing value beyond 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?

Clearly states 'Convert a Markdown file to DOCX (Word) format using Pandoc.' Verb and resource are specific, and the tool is distinct from siblings like batch_convert, docx_to_markdown, etc.

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 like markdown_to_pdf or batch_convert. No conditions, exclusions, or prerequisites mentioned.

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

markdown_to_htmlConvert Markdown to HTMLA

Read-onlyIdempotent

Convert a Markdown file to HTML format using Pandoc. Arguments:

inputPath (string, required): Path to the input Markdown file
outputPath (string, optional): Output path. Defaults to same name with .html
cssPath (string, optional): Path to a CSS stylesheet to embed
standalone (boolean, optional): Generate a complete HTML document with head/body. Defaults to true
strictMarkdown (boolean, optional): If true, reject files with structural issues (unclosed code blocks). Defaults to false
overwrite (boolean, optional): Allow overwriting. Defaults to false

ParametersJSON Schema

Name	Required	Description
`inputPath`	Yes	Path to the input Markdown file (relative to workspace)
`outputPath`	No	Output HTML path (relative to workspace). Auto-derived if omitted.
`cssPath`	No	Path to a CSS stylesheet file (relative to workspace)
`standalone`	No	Generate a standalone HTML document with head/body
`strictMarkdown`	No	If true, reject input if Markdown has structural issues like unclosed code blocks.
`overwrite`	No	Allow overwriting existing output file. Defaults to false.

TDQS

A3.7/5.0

Behavior2/5

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

The description adds parameter details (defaults, strictMarkdown behavior) but fails to correct the contradictory annotation readOnlyHint=true, which is misleading for a write operation. This inconsistency reduces transparency.

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 well-structured with a clear list of arguments, each with name, type, and purpose. It is concise without unnecessary fluff, though slightly longer due to parameter details.

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

Completeness4/5

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

For a conversion tool with no output schema, the description covers essential aspects: input/output paths, options like CSS and strictness, and defaults. It lacks error handling details but is otherwise complete given the tool's simplicity.

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?

Schema coverage is 100%, but description adds value by listing defaults for optional parameters (e.g., standalone=true, overwrite=false) and elaborating on behavior like strictMarkdown rejection, enhancing understanding 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 clearly states the tool converts Markdown to HTML using Pandoc, specifying verb and resource. It distinguishes from sibling tools like batch_convert and markdown_to_pdf by focusing on single-file conversion to HTML.

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?

Usage context is implied through the tool name and description, but there is no explicit guidance on when to use this tool versus alternatives like batch_convert for multiple files or markdown_to_pdf for PDF output.

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

markdown_to_pdfConvert Markdown to PDFB

Read-onlyIdempotent

Convert a Markdown file to PDF format using Pandoc. Arguments:

inputPath (string, required): Path to the input Markdown file (relative to workspace)
outputPath (string, optional): Path for the output PDF. Defaults to same name with .pdf extension
title (string, optional): Document title for the PDF metadata
toc (boolean, optional): Include a table of contents
pageSize (enum, optional): Page size — 'A4' or 'Letter'. Defaults to 'A4'
theme (enum, optional): Theme — 'default', 'github', or 'academic'. Currently informational
pdfEngine (enum, optional): PDF engine — 'pdflatex', 'xelatex', 'lualatex', 'wkhtmltopdf', 'weasyprint', or 'typst'. Leave unset to let Pandoc choose
cjkMainFont (string, optional): CJK main font used by xelatex for Chinese/Japanese/Korean PDF output. Example: 'Microsoft YaHei', 'SimSun', 'Noto Sans CJK SC'
preserveSource (boolean, optional): When true, save the original Markdown as a sidecar file (e.g. sample.pdf.source.md) for accurate PDF-to-Markdown recovery. Defaults to false
strictMarkdown (boolean, optional): If true, reject files with structural issues (unclosed code blocks). Defaults to false
overwrite (boolean, optional): Allow overwriting existing output. Defaults to false

ParametersJSON Schema

Name	Required	Description
`inputPath`	Yes	Path to the input Markdown file (relative to workspace)
`outputPath`	No	Path for the output PDF file (relative to workspace). Auto-derived if omitted.
`title`	No	Document title for PDF metadata
`toc`	No	Include a table of contents
`pageSize`	No	Page size for the PDF
`theme`	No	Visual theme (via CSS)
`pdfEngine`	No	PDF rendering engine to use. Leave unset to let Pandoc choose automatically.
`cjkMainFont`	No	CJK main font for Chinese/Japanese/Korean PDF output (used by xelatex). Example: 'Microsoft YaHei', 'SimSun', 'Noto Sans CJK SC'.
`preserveSource`	No	When true, save the original Markdown as a sidecar file (e.g. sample.pdf.source.md) for accurate PDF-to-Markdown recovery. Defaults to false.
`strictMarkdown`	No	If true, reject input if Markdown has structural issues like unclosed code blocks.
`overwrite`	No	Allow overwriting existing output file. Defaults to false.

TDQS

B3.1/5.0

Behavior1/5

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

Annotations include readOnlyHint=true, but the description implies creating an output file (conversion to PDF). This is a contradiction. The description fails to clarify side effects like file creation, overwriting, or the use of external tools (Pandoc).

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 front-loaded with the purpose sentence, but the rest is a parameter list that largely repeats the schema. It could be more concise by grouping related options or removing redundant explanations.

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?

Covers all 11 parameters with some added context. However, lacks behavioral information (e.g., what happens if output exists, dependencies on Pandoc installation) and usage scenarios. Output schema is absent, but schema coverage is high.

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?

Schema coverage is 100%. The description adds value by stating defaults (pageSize defaults to 'A4'), providing examples (cjkMainFont), and clarifying behavior (leave pdfEngine unset for auto). This exceeds the baseline 3.

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?

Clearly states it converts a Markdown file to PDF using Pandoc. The verb 'Convert' and resource 'Markdown file to PDF format' are specific. This distinguishes it from sibling tools like markdown_to_html or docx_to_markdown.

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 explicit guidance on when to use this tool versus alternatives like batch_convert. The description only lists parameters without context for selection.

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

pdf_to_markdownConvert PDF to MarkdownA

Read-onlyIdempotent

Extract text content from a PDF file into Markdown format.

IMPORTANT: This is CONTENT EXTRACTION, not layout reconstruction.

Scanned PDFs, complex tables, two-column papers, and mathematical formulas may not convert reliably.
For scanned PDFs, an OCR engine is required (not included).
Default engine is MarkItDown (better text extraction). Falls back to Pandoc if unavailable.

Arguments:

inputPath (string, required): Path to the input PDF file
outputPath (string, optional): Output path. Defaults to same name with .md
engine (enum, optional): Engine — 'markitdown' (default) or 'pandoc'
cleanForLLM (boolean, optional): Clean up Markdown for LLM consumption
preferSourceSidecar (boolean, optional): When true (default), first check for a source sidecar file (sample.pdf.source.md) and return it instead of extracting PDF text. This is the only reliable way to recover original Markdown structure.
overwrite (boolean, optional): Allow overwriting. Defaults to false

ParametersJSON Schema

Name	Required	Description
`inputPath`	Yes	Path to the input PDF file (relative to workspace)
`outputPath`	No	Output Markdown path (relative to workspace). Auto-derived if omitted.
`engine`	No	Conversion engine. Defaults to 'markitdown'.
`cleanForLLM`	No	Clean up the Markdown output for LLM consumption
`preferSourceSidecar`	No	When true (default), first check for a source sidecar file (.source.md) generated by markdown_to_pdf with preserveSource=true. If found, return the original Markdown instead of extracting PDF text. This is the only reliable way to recover structure.
`overwrite`	No	Allow overwriting existing output file. Defaults to false.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations (readOnly, idempotent) are consistent. Description adds behavioral details: engine fallback, sidecar checking, default overwrite false, and conversion limitations. 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.

Conciseness4/5

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

Well-structured with clear sections: intent, warnings, parameter details. Each sentence carries weight; no redundancy. Slightly verbose but justified given complexity.

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?

Lacks output schema, but description explains output is Markdown. Missing details on exact format (page breaks, metadata), error handling, or performance. Acceptable given parameter coverage and annotations.

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?

Schema coverage is 100%, but description adds meaningful nuance: engine defaults and fallback, outputPath auto-naming, sidecar file pattern, and cleaning purpose. Goes beyond schema documentation.

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 extracts text content from PDF to Markdown, with a specific verb and resource. It distinguishes from siblings by emphasizing content extraction vs layout reconstruction and noting limitations (scanned PDFs, complex tables).

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?

Provides explicit warnings about unreliable conversions (scanned PDFs, tables, math) and OCR requirements. Also explains sidecar behavior as the only reliable recovery method. Lacks explicit comparison to sibling tools but imparts clear context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv1.0.0Jun 19, 2026
- First observedbatch_convert
- First observeddocx_to_markdown
- First observedmarkdown_to_docx
- First observedmarkdown_to_html
- First observedmarkdown_to_pdf
- First observedpdf_to_markdown

Install Server

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

TDQS

A3.6/5.0

Disambiguation4/5

Tools are mostly distinct: batch_convert handles directory-wide conversions, while others are single-file conversions for specific pairs. However, an agent could be unsure whether to use batch_convert or a specific tool for a single file, causing minor overlap.

Naming Consistency4/5

Most tools follow source_to_target pattern (docx_to_markdown, markdown_to_docx, etc.), but batch_convert deviates from this pattern with a verb_noun style. Still consistent enough for predictability.

Tool Count5/5

With 6 tools covering common document conversions and a batch option, the count is well-scoped for the server's purpose. No excess or deficiency.

Completeness3/5

Notable gaps exist: no source HTML conversion, no direct docx-to-html or pdf-to-docx conversion. While batch_convert supports many conversions, it lacks HTML as a source. This may cause dead ends for some workflows.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

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

file2markdown A
ai.file2markdown
Convert documents and web pages to clean Markdown: PDF, DOCX, XLSX, EPUB, scanned files, any URL.
Browser Automation Documentation Access Web Scraping
41
mcp
com.mdtidy
Clean, repair, and convert AI-generated Markdown to HTML/PDF/DOCX/PNG; save and share documents.
Content Management Systems Developer Tools
2
agentmd A
io.github.djrobson5
Convert PDF, DOCX, HTML, and URLs to clean, LLM-ready markdown with tables preserved
Documentation Access Web Scraping
21
netcafe-docflow A
com.ainetcafe
Markdown in, any format out. PDFs merged, split, watermarked. Runs on our own doc engines.
Developer Tools Documentation Access
1311

Related MCP Servers

Document Reading and Converter
File Systems Developer Tools
mffrydman
F
license
Not graded
quality
D
maintenance
Enables document conversion between PDF, DOCX, and Markdown formats to facilitate reading and editing complex files in AI tools like Claude Desktop or Cursor. It utilizes marker-pdf and pandoc to provide structured text versions of documents, helping to manage context and support unsupported file types.
Updated a year ago (2025-06-25 20:28 UTC)
1
-
mcp-document-converter
Developer Tools Workplace & Productivity
xt765
A
license
Not graded
quality
C
maintenance
Converts documents between multiple formats (Markdown, HTML, DOCX, PDF, Text) enabling AI agents to easily transform documents.
Updated 6 months ago (2026-03-02 05:56 UTC)
12
MIT
markitdown-mcp
File Systems Search Research & Data
alfredoanton82
F
license
Not graded
quality
D
maintenance
Converts documents (PDF, DOCX, XLSX, PPTX, HTML, TXT, MD) to Markdown and stores them locally with search and retrieval capabilities.
Updated 3 months ago (2026-06-13 10:38 UTC)
-
packforai-mcp
Data Platforms Research & Data
ibrtokmecheng
A
license
A
quality
C
maintenance
Converts PDF, DOCX, PPTX, XLSX, CSV, and JSON into clean, compact, AI-ready Markdown, reducing tokens up to 65%.
Updated 2 months ago (2026-07-07 12:02 UTC)
1
47
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/guanweiqiang/document-converter-mcp'

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

@lifeng688/document-converter-mcp

Features

Supported Formats

Installation

Prerequisites

PDF Engine (required for Markdown -> PDF)

Install Pandoc

Install MarkItDown (optional, recommended for PDF -> Markdown)

Install the Server

MCP Client Configuration

Claude Desktop

Configuration File

Tools

1. doctor

2. markdown_to_pdf

3. markdown_to_docx

4. docx_to_markdown

5. pdf_to_markdown

6. markdown_to_html

7. batch_convert

Usage Examples

Run doctor

Create .document-converter.json

Markdown to Chinese PDF using config

Markdown to PDF with preserveSource

PDF to Markdown using source sidecar

Markdown to HTML with GitHub theme

Batch convert with dry run

Batch convert with include/exclude

DOCX to Markdown with image extraction

Security

Recommended Workflows

Good

Not recommended

推荐工作流

推荐

不推荐

Conversion Quality

Development

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `doctor`

2. `markdown_to_pdf`

3. `markdown_to_docx`

4. `docx_to_markdown`

5. `pdf_to_markdown`

6. `markdown_to_html`

7. `batch_convert`

Create `.document-converter.json`

Markdown to PDF with `preserveSource`