Skip to main content
Glama
zhengjie9510

mineru-docparse-mcp

by zhengjie9510

mineru-docparse-mcp

MCP Server that converts Word / PDF / PPT / Excel to Markdown, powered by the MinerU DocParse API.

This project is a protocol wrapper — it does not parse documents itself. You need a running MinerU DocParse service, defaulting to http://localhost:8000. See the MinerU repository for deployment instructions.

Installation

pip install mineru-docparse-mcp

Related MCP server: MCP Document Parse Tool

Setup with Claude Code

The output directory is a server-side setting (not a per-request parameter), so MINERU_OUTPUT_DIR must be configured in advance:

{
  "mcpServers": {
    "mineru": {
      "command": "uvx",
      "args": ["mineru-docparse-mcp"],
      "env": {
        "MINERU_API_URL": "http://localhost:8000",
        "MINERU_OUTPUT_DIR": "/Users/yourname/Documents/mineru-output"
      }
    }
  }
}

Once configured, Claude will automatically invoke the tools below. All parsed results are saved to MINERU_OUTPUT_DIR.

Tools

Tool

Description

mineru_parse_document

Convert PDF/Word/PPT/Excel to Markdown, saved to disk

mineru_health_check

Check MinerU service health

Output format: Results are saved exactly as returned by MinerU. When response_format_zip=true (the default) output is saved as .zip; when false as .json. File name matches the source file — if a file with the same name already exists, a timestamp is appended to avoid overwriting.

API Parameters

mineru_parse_document mirrors the MinerU /file_parse endpoint:

Parameter

Type

Default

Description

file_path

string

required

Local document path (absolute or relative)

backend

enum

hybrid-engine

Parsing backend, see "backend options" below

lang_list

string[]

["ch"]

OCR language list, only for pipeline backend

effort

medium | high

medium

hybrid backends only. medium: faster, no chart analysis; high: higher accuracy with chart analysis, slower

parse_method

auto | txt | ocr

auto

PDF parsing method for pipeline/hybrid: auto-detect / text extraction / OCR

formula_enable

bool

true

Enable formula parsing (LaTeX)

table_enable

bool

true

Enable table parsing

image_analysis

bool

true

Enable image/chart analysis (VLM/hybrid backends only)

server_url

string | null

null

OpenAI-compatible server URL, required for *-http-client backends

return_md

bool

true

Include Markdown content in response

return_middle_json

bool

false

Include intermediate JSON in response

return_model_output

bool

false

Include raw model output JSON in response

return_content_list

bool

false

Include content list JSON in response

return_images

bool

false

Include extracted images in response

response_format_zip

bool

true (this project's default; API default is false)

Return results as ZIP (false returns JSON)

return_original_file

bool

false

Include processed original file in ZIP (response_format_zip=true only)

client_side_output_generation

bool

false

Defer final Markdown/content-list generation to the client

start_page_id

int

0

Starting page (0-indexed)

end_page_id

int

99999

Ending page (0-indexed)

Backend Options

Value

Description

pipeline

General-purpose, multilingual, no hallucination

vlm-engine

Local compute, high accuracy, Chinese/English only

vlm-http-client

Remote compute (OpenAI-compatible), high accuracy, Chinese/English only

hybrid-engine (default)

Local compute, hybrid parsing, multilingual, tune with effort

hybrid-http-client

Primarily remote compute + light local, hybrid parsing, multilingual

Language Options (lang_list)

ch (Chinese/English/Japanese/Traditional/Latin), ch_server, korean, ta (Tamil), te (Telugu), ka (Kannada), th (Thai), el (Greek), arabic, east_slavic, cyrillic, devanagari. Only applies to the pipeline backend; ignored by others.

Server Configuration (Environment Variables)

These are server startup settings — configure them in the env field of your MCP config, not as per-request parameters.

Variable

Default

Description

MINERU_API_URL

http://localhost:8000

MinerU service URL

MINERU_OUTPUT_DIR

none (required)

Directory for parsed results (absolute or relative paths)

MINERU_API_TIMEOUT

600

Request timeout in seconds — increase for large files

MCP_TRANSPORT

stdio

Transport mode: stdio (local subprocess) or streamable-http (remote)

MCP_HOST

127.0.0.1

Listen address (HTTP mode only); set to 0.0.0.0 to expose externally

MCP_PORT

8001

Listen port (HTTP mode only)

Remote Deployment (Optional)

To run the MCP server on a dedicated machine accessible by multiple clients, use HTTP mode:

MCP_TRANSPORT=streamable-http MCP_PORT=8001 MINERU_OUTPUT_DIR=/data/mineru-output uvx mineru-docparse-mcp

Clients connect via URL:

{
  "mcpServers": {
    "mineru": {
      "type": "streamableHttp",
      "url": "http://<server-address>:8001/mcp"
    }
  }
}

Omitting MCP_TRANSPORT defaults to local stdio mode (the "Setup with Claude Code" flow above), which is sufficient for personal use.

FAQ

"MINERU_OUTPUT_DIR environment variable not configured" — This is a required server setting, not an API parameter. Set it in the env field of your MCP config and restart the MCP connection.

"Cannot connect to MinerU service" — Verify MINERU_API_URL is reachable: curl $MINERU_API_URL/health. In stdio mode, environment variables must be set in the MCP config env field; shell export won't work.

Large files timeout — Increase MINERU_API_TIMEOUT or narrow the start_page_id/end_page_id range to parse in batches.

Want JSON instead of ZIP — Set response_format_zip to false; results will be saved as .json instead of .zip.

License

MIT

Available Tools

2 tools
mineru_health_checkA

检查 MinerU DocParse API 服务是否正常运行。

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior2/5

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

No annotations are provided, and the description is minimal—it does not disclose behavioral traits such as side effects, authentication needs, or rate limits, which is a gap for a tool with no annotations.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with no unnecessary words, achieving maximum conciseness.

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 simple health-check tool with no parameters and an output schema present, the description adequately states its purpose, though it could hint at usage context (e.g., check before parsing).

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?

There are zero parameters and schema coverage is 100%, so the baseline is 4; the description adds no param information, but none is needed.

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 checks the health of the MinerU DocParse API service, using a specific verb ('check') and resource, and it is distinct from the sibling tool that parses documents.

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 usage for health checking but does not explicitly state when to use versus alternatives (e.g., before parsing), and provides no exclusions or prerequisites.

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

mineru_parse_documentC

将 PDF · DOCX · PPTX · XLSX · 图片 · 网页转为结构化 Markdown / JSON

上传文件到 MinerU DocParse API 进行内容提取

ParametersJSON Schema
NameRequiredDescriptionDefault
paramsYesmineru_parse_document 的输入参数,对应官方 POST /file_parse 接口。 字段及默认值与官方 OpenAPI schema 一致,仅 response_format_zip 默认改为 True。

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.9/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. It mentions uploading to an API but does not disclose side effects, authentication requirements, rate limits, or non-destructive nature. Transparency is minimal.

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 (two sentences), front-loading the core function and supported formats. Every word adds value, though it could be slightly more structured.

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 (multiple backends, many parameters, nested input), the description is too brief. It lacks a high-level overview of backends, output behavior, and potential caveats, leaving the agent to infer from the schema alone.

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 baseline 3 is appropriate. The tool description does not add detail beyond the schema, but the nested params description within the input schema provides comprehensive parameter meanings.

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 converts PDF, DOCX, PPTX, XLSX, images, and web pages to structured Markdown/JSON, and uploads to the MinerU DocParse API for extraction. It differentiates from the sibling health check tool by its specific parsing function.

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, nor are there any prerequisites or exclusions. The description only defines the action without contextual usage advice.

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.

  1. 2 tool updatesv1.0.0
    • First observedmineru_health_check
    • First observedmineru_parse_document

TDQS

A3.5/5.0
Disambiguation5/5

The two tools serve completely distinct purposes: one checks API health, the other parses documents. There is no overlap or ambiguity.

Naming Consistency5/5

Both tools follow a consistent 'mineru_verb_noun' pattern using snake_case, which is clear and predictable.

Tool Count3/5

Only two tools exist, which is borderline low for a typical server. However, for a focused document parsing service with a health check, it may be acceptable.

Completeness4/5

The set covers the essential operations for the server's purpose: health check and document parsing. Minor gaps like format listing or status checking are absent but workable.

Maintenance

ActivitySlowing
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

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/zhengjie9510/mineru-docparse-mcp'

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