Skip to main content
Glama
deenesjakoruzh
opendatalab

MinerU Open MCP (Official)

by opendatalab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

MinerU Open MCP

MinerU-Ecosystem MCP server

MinerUのドキュメント解析機能をMCPツールとして公開する公式MinerU MCPサーバーです。MCP互換のAIクライアントに接続して、PDF、Wordドキュメント、PowerPointファイル、画像をMarkdownに変換できます。

APIキーは不要です — Flashモードはすぐに利用可能で、登録不要で無料ですが、制限が低く設定されています。MINERU_API_TOKENを設定すると、より高い制限と追加の出力形式が利用可能になります。

サンドボックス環境を持つMCPクライアントに関する注意 - 一部のMCPクライアントでは、入力ボックスにドラッグしたファイルは一時ディレクトリにサンドボックス化されます。ローカルファイルをアップロードして解析する必要がある場合は、サーバーがファイルを見つけられない場合に備えて、プロンプトに対象ファイルのフルパスを指定してください。

⚡ 最速の実行方法 — uvx (インストール不要)

mineru-open-mcpはPyPIで公開されています。uvがインストールされていれば、個別のインストール手順なしで直接実行できます。

MCPクライアントの設定

stdio — Claude Desktop, Cursor, Windsurf

MCPクライアントはmineru-open-mcpをサブプロセスとして自動的に起動します。

uvxを使用する場合（推奨 — 常に最新バージョンが実行されます）:

{
  "mcpServers": {
    "mineru": {
      "command": "uvx",
      "args": ["mineru-open-mcp"],
      "env": {
        "MINERU_API_TOKEN": "your_key_here"
      }
    }
  }
}

APIキーをお持ちでない場合？ サーバーはFlashモードで動作します。無料でMarkdown出力のみ可能です。詳細はFlashモードのドキュメントをご覧ください。

mineru-open-mcpがPATHにない場合？ フルパス（例: "/Users/you/.local/bin/mineru-open-mcp"）を使用するか、上記で説明したuvxアプローチを使用してください（自動的に処理されます）。

Related MCP server: MinerU MCP Server

使用例

例1: ローカルのPDFドキュメントをページ範囲指定で解析する

ユーザープロンプト: "このPDFの3〜5ページ目をMarkdownに解析して: <your_path_to_file>" 動作:

  • MinerUがPDFをアップロードして解析します

  • テーブル（HTML）と数式（Latex）が保持されたクリーンなMarkdownを返します

  • 長さが許容される場合はチャット内にMarkdownテキストを返し、出力パスと、必要に応じてzipファイルのURLも返します

  • MCPクライアントが内容を要約します

例2: ファイルをホストしているリモートURLを解析する

ユーザープロンプト: "この論文の内容を抽出して: https://arxiv.org/pdf/2509.22186" 動作:

  • MinerUが論文をMarkdownに解析します

  • MCPクライアントがテーブルを整形して解説します

例3: ローカルのPDFファイルを個別のページ範囲で解析する

ユーザープロンプト: "の1〜5ページ、の2〜9ページ、の3ページ目をMarkdownに解析して" 動作:

  • MinerUが各ファイルを個別にアップロードして解析します

  • 対象形式の出力、ダウンロード用のzip URL、Markdownの要約、保存先のディレクトリを返します

  • MCPクライアントがその内容を使用してさらなる分析を行います

例4: 高度なカスタム設定

ユーザープロンプト1: "パイプラインモデルを使用してこの韓国語ファイルを解析して: your_path_here" ユーザープロンプト2: "your_path_hereを解析して、Markdownをyour_output_dirに保存して" 動作:

  • パイプラインモデルはMinerUサービスが提供する別のモデルです（ちなみに、デフォルトはvlmモデルです）

  • プロンプトを構成することで、モデル、OCR言語、またはOUTPUT_DIRとは異なる独立した出力ディレクトリを指定できます

  • リクエストはparse_documentsツールにパラメータ化され、MinerUが残りの処理を行います。

streamable-http — WebベースのMCPクライアント

サーバーを手動で起動し、クライアントから接続します：

MINERU_API_TOKEN=your_key mineru-open-mcp --transport streamable-http --port 8001
{
  "mcpServers": {
    "mineru": {
      "type": "streamableHttp",
      "url": "http://127.0.0.1:8001/mcp"
    }
  }
}

機能

  • parse_documents — ローカルファイルやリモートURLをMarkdownに変換します。入力はPDF、画像（png/jpg/jpeg/jp2/webp/gif/bmp）、Doc、Docx、Ppt、PPTxをサポートしています。Flashモードはxlsxもサポートしています。

  • get_ocr_languages — MinerUがサポートするすべてのOCR言語をリストアップします

  • Flashモード — APIキーなしで動作します（無料、Markdown出力のみ、PDF/画像/Docx/PPTx/xls/xlsxをサポート）。すべての機能を利用するにはMINERU_API_TOKENを提供してください（Flashモードが無効になります）。

  • 出力動作 — 単一ファイルの解析はデフォルトでインラインMarkdownを返します。バッチ解析は結果をディスクに保存し、ファイルメタデータを返します。サイズが大きすぎるインラインコンテンツもローカルに保存され、extract_path経由で返されます。

  • 2つの転送モード — stdio、streamable-http

環境変数

変数

説明

デフォルト

MINERU_API_TOKEN

MinerU APIトークン。全機能を利用するにはMinerUで申請してください。指定がない場合はFlashモードが有効になります。

—

OUTPUT_DIR

バッチ解析やサイズが大きすぎるインラインコンテンツなど、解析結果をローカルに保存する必要がある場合に使用するディレクトリ

~/mineru-downloads

プライバシーポリシー

mineru-open-mcpは、ドキュメントを解析するために公式のMinerU API (mineru.net) に接続します。

  • 送信データ: ドキュメントの内容（解析のために提供したファイルまたはURL）

  • データ保存: 解析結果はMinerUサーバーによって一時的にキャッシュされますが、学習には使用されません

  • サードパーティ: MinerU API (mineru.net) — OpenDatalabプライバシーポリシーを参照してください

  • ローカルデータ: 解析結果は指定された出力ディレクトリに保存されます。ログファイル（ENABLE_LOG=trueの場合のみ）はMINERU_LOG_DIRに保存されます。

  • 連絡先: OpenDataLab@pjlab.org.cn (またはMinerU-EcosystemでIssueを作成してください)

Available Tools

2 tools
get_ocr_languagesList OCR language codesA
Read-only

Return supported MinerU OCR and script language codes (e.g. ch, en, japan, latin). Read-only; no uploads. Use before setting the language argument on parse_documents for scanned or multilingual documents. Do not use for file conversion; call parse_documents instead.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds 'Read-only; no uploads,' which reinforces and complements the annotations without contradiction.

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?

Three succinct sentences with no wasted words. Purpose, behavioral note, and usage guidance are each in separate, front-loaded sentences.

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

Completeness5/5

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

For a zero-parameter tool with an output schema, the description adequately covers its purpose, when to use it, and behavioral constraints. No missing information.

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?

Tool has zero parameters, so schema coverage is 100%. No parameter information needed; baseline is 4. Description correctly omits param details.

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 returns supported OCR language codes, specifying verb 'Return' and resource 'MinerU OCR and script language codes'. It distinguishes from the sibling tool parse_documents.

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

Usage Guidelines5/5

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

Explicitly states when to use ('before setting the language argument on parse_documents for scanned or multilingual documents') and when not to ('Do not use for file conversion'), with a direct alternative (parse_documents).

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

parse_documentsParse documents to MarkdownA

Convert PDF, Office (DOCX, PPTX), spreadsheets (XLSX in Flash mode), images, and http(s) URLs to Markdown using the MinerU cloud API (content is uploaded to mineru.net; do not use for data that must stay on-device). Does not modify source files; may write Markdown under output_dir when saving results. Auth: without MINERU_API_TOKEN, Flash mode applies (Markdown-only, about 20 pages and 10 MB per file; service rate limits). With MINERU_API_TOKEN, higher limits and optional formats per plan. Use for extraction and conversion. Use get_ocr_languages only to list OCR language codes, not to parse files. Not for fully offline parsing. Parameters: file_sources is paths/URLs or objects with source and pages for PDF ranges; language is an OCR code (default ch); enable_ocr defaults to auto (null); set model to html only if every source is a web page URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_sourcesYesFiles to parse. Each entry is either: - a plain string: a local file path or URL - a dict {"source": "...", "pages": "N-M"}: with an optional page range Page range: "N" (single page) or "N-M" (for example "1-10"). PDF only. Duplicate sources are allowed, for example the same PDF with different ranges. Examples: ["report.pdf"] [{"source": "report.pdf", "pages": "1-5"}] [{"source": "a.pdf", "pages": "1-3"}, {"source": "a.pdf", "pages": "10-15"}] ["https://example.com/doc.pdf", "local.docx"]
enable_ocrNoOCR mode: null (default) - auto-detect: the server decides whether OCR is needed. true - force OCR on when the user mentions poor scan quality. false - disable OCR. Omit this parameter unless the user explicitly mentions scan quality issues.
languageNoOCR language code. Omit if unknown; the server defaults to "ch" (Chinese + English). Infer from the document filename when possible, for example "manual_en.pdf" -> "en". Common codes: "ch", "en", "japan", "korean", "latin", "arabic", "cyrillic", "devanagari". Full list: call get_ocr_languages.
modelNoParsing model. Set to "html" only when all file_sources are web page URLs. Otherwise omit it and let MinerU auto-select the appropriate model. Ignored in Flash mode.
output_dirNoDirectory used when parsed results need to be saved locally, such as batch parsing or oversized inline content. Defaults to the server-configured directory.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.9/5.0
Behavior5/5

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

Discloses data uploaded to mineru.net (beyond annotations), non-destructive nature, and potential file writes. Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) are consistent with description; no contradiction.

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?

Concise multi-sentence description with logical flow: function, caveats, usage guidance, parameter tips. No redundancy; each sentence adds value.

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

Completeness5/5

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

Covers complex tool with 5 params, auth modes, output behavior, and offline limitation. Output schema exists, so return value details are not needed. Complete for agent decision-making.

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%, so baseline 3. Description adds value by summarizing key usage hints for parameters (e.g., file_sources examples, enable_ocr auto-detection, model='html' condition). Minor improvement over schema alone.

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 'PDF, Office, spreadsheets, images, and URLs to Markdown'. It distinguishes from sibling tool get_ocr_languages by noting its exclusive use for listing OCR codes, not parsing.

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

Usage Guidelines5/5

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

Explicitly states when to use ('Use for extraction and conversion'), when not ('Not for fully offline parsing'), and mentions alternative (get_ocr_languages). Also covers auth-dependent behaviors and rate limits.

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.

  1. 2 tool updatesv1.0.18
    • Addedget_ocr_languages
    • Addedparse_documents
  2. 2 tool updatesv1.0.16
    • Removedget_ocr_languages
    • Removedparse_documents
  3. 2 tool updatesv1.0.15
    • First observedget_ocr_languages
    • First observedparse_documents
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.6/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have entirely distinct purposes: one lists OCR language codes, the other performs document parsing. There is no overlap or ambiguity.

Naming Consistency5/5

Both tool names follow a clear verb_noun pattern (get_ocr_languages, parse_documents), ensuring predictability and consistency.

Tool Count3/5

With only two tools, the server is at the lower end of reasonable scope. While it covers core functionality, additional tools for status checking or format listing would improve completeness.

Completeness3/5

The tool set covers the primary use case (document conversion) and a helper for language codes, but lacks operations like checking conversion status or listing all supported formats, creating minor gaps.

Maintenance

ActivityInactive
ResponsivenessWithin a week

Resources

Related MCP Connectors

Related MCP Servers