Skip to main content
Glama
Tongzhao9417

MinerU MCP Server

by Tongzhao9417
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

MinerU MCP Server

基于 FastMCP 3.x 的 MCP 服务器，将 MinerU 的文档转 Markdown API 暴露为 MCP 工具。

支持 PDF、Word、PPT 及图片格式（JPG、PNG）的解析。

工具

工具

说明

parse_documents

将文件转换为 Markdown（支持本地路径和 URL，可批量处理）

get_ocr_languages

获取 OCR 支持的语言列表

Related MCP server: Markitdown MCP Server

安装

pip install mineru-mcp-server

从源码安装：

git clone https://github.com/Tongzhao9417/mineru_mcp.git
cd mineru_mcp
pip install -e .

核心依赖仅 3 个：fastmcp>=3.0.0、python-dotenv>=1.0.0、httpx>=0.24.0

环境变量

在项目根目录创建 .env 文件（参考 .env.example），或直接设置环境变量：

变量

说明

默认值

MINERU_API_KEY

MinerU API 密钥（官网申请）

必填

MINERU_API_BASE

远程 API 基础 URL

https://mineru.net

OUTPUT_DIR

转换结果保存路径

./downloads

USE_LOCAL_API

是否使用本地 API

false

LOCAL_MINERU_API_BASE

本地 API 地址（USE_LOCAL_API=true 时生效）

http://localhost:8080

MCP 客户端配置

Claude Code / Claude Desktop

{
  "mcpServers": {
    "mineru-mcp": {
      "command": "mineru-mcp-server",
      "env": {
        "MINERU_API_KEY": "your-api-key"
      }
    }
  }
}

从源码运行

{
  "mcpServers": {
    "mineru-mcp": {
      "command": "uv",
      "args": ["--directory", "/path/to/mineru_mcp", "run", "mineru-mcp-server"],
      "env": {
        "MINERU_API_KEY": "your-api-key"
      }
    }
  }
}

直接运行

# stdio 模式（默认，MCP 客户端自动管理）
mineru-mcp-server

# HTTP 模式（独立服务，多客户端可连接）
mineru-mcp-server --transport streamable-http --port 8001

推荐使用 streamable-http 传输模式（MCP 规范推荐），SSE 已被标记为 deprecated。

parse_documents 参数

参数

类型

说明

默认值

file_sources

string

文件路径或 URL，多个用逗号分隔

必填

enable_ocr

bool

启用 OCR

false

language

string

文档语言（ch/en 等）

ch

page_ranges

string

页码范围，如 "2,4-6"（仅远程 API）

None

常见问题

API 返回 401：检查 MINERU_API_KEY 是否正确设置。

找不到文件：请使用绝对路径。

调用超时：大文档处理耗时较长，建议分批处理或使用本地 API 模式。

License

MIT

Available Tools

2 tools
get_ocr_languagesB

获取 OCR 支持的语言列表。

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

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 the full burden of behavioral disclosure. It only states what the tool does (get a list) without any additional context about permissions, rate limits, response format, or other behavioral traits. This leaves significant gaps for a tool that likely returns structured data.

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. It is front-loaded with no wasted words, making it highly concise and well-structured for its simple 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 low complexity (0 parameters, simple read operation) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and a sibling tool, it could benefit from more context about usage or behavior to be fully complete.

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 tool has 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, so it meets the baseline expectation. No compensation is required for missing parameter info.

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: '获取 OCR 支持的语言列表' (Get the list of languages supported by OCR). It specifies the verb '获取' (get) and resource 'OCR 支持的语言列表' (OCR-supported language list). However, it doesn't explicitly differentiate from its sibling tool 'parse_documents', which appears to be a different operation (parsing vs. listing).

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 the sibling tool 'parse_documents' or any other context for usage. The agent must infer usage based on the purpose alone, with no explicit when/when-not instructions.

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

parse_documentsA

统一接口，将文件转换为Markdown格式。支持本地文件和URL，会根据USE_LOCAL_API配置自动选择合适的处理方式。

ParametersJSON Schema
NameRequiredDescriptionDefault
file_sourcesYes文件路径或URL，支持以下格式: - 单个路径或URL: "/path/to/file.pdf" 或 "https://example.com/document.pdf" - 多个路径或URL(逗号分隔): "/path/to/file1.pdf, /path/to/file2.pdf" 或 "https://example.com/doc1.pdf, https://example.com/doc2.pdf" - 混合路径和URL: "/path/to/file.pdf, https://example.com/document.pdf" (支持pdf、ppt、pptx、doc、docx以及图片格式jpg、jpeg、png)
enable_ocrNo启用OCR识别,默认False
languageNo文档语言，默认"ch"中文，可选"en"英文等ch
page_rangesNo指定页码范围，格式为逗号分隔的字符串。例如："2,4-6"：表示选取第2页、第4页至第6页；"2--2"：表示从第2页一直选取到倒数第二页。（远程API）,默认None

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior3/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 explains the tool's automatic processing behavior based on configuration and mentions supported file formats, but doesn't cover important aspects like error handling, rate limits, authentication requirements, or what happens with large files. The description adds some context but leaves significant behavioral 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 appropriately concise with two sentences that each serve a purpose: stating the core function and explaining the processing approach. It's front-loaded with the main purpose, though the second sentence could be slightly more streamlined.

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 the tool has an output schema (which handles return values), 100% schema description coverage, and no annotations, the description provides adequate context about what the tool does and how it processes files. However, for a document parsing tool with multiple parameters and no annotations, more behavioral context about limitations or edge cases would be beneficial.

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 thoroughly. The description mentions support for local files and URLs but doesn't add meaningful parameter semantics beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.

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's purpose: '将文件转换为Markdown格式' (convert files to Markdown format). It specifies the unified interface approach and distinguishes itself from the sibling tool get_ocr_languages by focusing on document parsing rather than language retrieval.

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 description provides clear context about when to use this tool: for converting files to Markdown, supporting both local files and URLs, with automatic processing based on USE_LOCAL_API configuration. However, it doesn't explicitly state when NOT to use it or mention alternatives beyond the sibling tool.

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.5/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: get_ocr_languages retrieves a list of supported languages for OCR, while parse_documents converts files to Markdown format. There is no overlap in functionality, making it easy for an agent to select the appropriate tool without confusion.

Naming Consistency5/5

Both tools follow a consistent verb_noun naming pattern (get_ocr_languages and parse_documents), using snake_case throughout. This predictability enhances readability and usability for agents, with no deviations in style.

Tool Count2/5

With only 2 tools, the server feels thin for a document processing domain that might include OCR and parsing. While the tools cover specific tasks, the scope suggests potential gaps (e.g., no tools for editing, saving, or managing documents), making it borderline too few for comprehensive functionality.

Completeness3/5

The tools cover basic OCR language retrieval and document parsing, but there are notable gaps in the document processing lifecycle. For example, there are no tools for creating, updating, or deleting documents, which could limit agent workflows and lead to dead ends in more complex tasks.

Maintenance

ActivityInactive
ResponsivenessNo issues

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/Tongzhao9417/mineru_mcp'

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