Mineru

mineru-mcp

MinerU のドキュメント解析 API 用 MCP サーバーと mineru-cloud CLI です。アーティファクトを完全に保持し、耐久性のある操作とポータブルな PDF バンドルに対応しています。

このチェックアウトに含まれる耐久性のある操作とバンドル機能は、まだリリースされていません。公開済みの [email protected] には含まれていないため、npm ユーザーはこれらの変更を含むリリースをお待ちください。

機能

• VLM モデル — 視覚言語モデルによるドキュメント解析
• Pipeline モデル — Pipeline モデルによるドキュメント解析
• ローカルファイルのアップロード — ディスク上のファイルをアップロードして一括解析
• 一括処理 — 1 回のリクエストで複数のドキュメントを送信
• ダウンロードと名前変更 — 元のファイル名を使って Markdown を抽出
• ページ範囲 — 指定したページのみを抽出
• 長いドキュメント — mineru_parse_long はページ範囲ごとに分割して送信し、mineru_merge_slices はそれらを結合
• CLI ツイン — mineru-cloud でシェルから同じツールを実行
• 言語と OCR のオプション — 言語を選択し、Pipeline モデルの OCR を有効化

ツール

ツール	説明
mineru_parse	ドキュメント URL を解析
mineru_status	タスクの進行状況を確認し、ダウンロード URL を取得
mineru_batch	複数の URL を解析
mineru_batch_status	ページネーション付きで一括処理の結果を取得
mineru_upload_batch	ローカルファイルをアップロードして一括解析
mineru_download_results	アーカイブを完全に保持し、すべてのメンバーを一覧化して、名前付きの互換コピーを作成
mineru_parse_long	長いドキュメントをページ範囲ごとのスライスに分けて送信
mineru_merge_slices	利用可能な Markdown を結合し、ページの出所が不明であることを明示した不変のスライスアーカイブを保持
mineru_capabilities	ローカルで把握している機能を読み取り、明示的な更新で機能を検出
mineru_submit	耐久性のあるローカルジャーナルと重複リクエスト防止機能を使って送信
mineru_operation_status	記録された操作を読み取り、明示的な更新でリモートの状態を確認
mineru_resume	記録された安全なチェックポイントから続行
mineru_cancel	ローカル処理を停止。リモートでのキャンセルには対応していません
mineru_bundle	操作で保持されたバンドルを検証して返す

インストール

新規インストールには Node.js 24 を使用してください。互換性のため、Node.js 18 以降も引き続きサポートされています。クラウドコマンドには MinerU API キー が必要です。オフラインでのバンドル作成には認証情報は必要ありません。

ローカル出力の保持、バンドル、耐久性のある操作には macOS または Linux が必要です。これらのパスではディレクトリに制約されたファイルシステム操作を使用し、Windows ではフェイルクローズします。以下の Windows クライアント設定は、ローカル保持への対応を意味するものではありません。

CLI のインストール（ワンライナー）

# Claude Code
claude mcp add mineru-mcp -e MINERU_API_KEY=your-api-key -- npx -y mineru-mcp

# Codex CLI (OpenAI)
codex mcp add mineru --env MINERU_API_KEY=your-api-key -- npx -y mineru-mcp

# Gemini CLI (Google)
gemini mcp add -e MINERU_API_KEY=your-api-key mineru npx -y mineru-mcp

Claude Desktop

claude_desktop_config.json に追加します。

OS	設定パス
macOS	~/Library/Application Support/Claude/claude_desktop_config.json
Windows	%APPDATA%\Claude\claude_desktop_config.json
Linux	~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "mineru": {
      "command": "npx",
      "args": ["-y", "mineru-mcp"],
      "env": {
        "MINERU_API_KEY": "your-api-key"
      }
    }
  }
}

VS Code

.vscode/mcp.json（ワークスペース）に追加するか、コマンドパレットを開いて MCP: Open User Configuration（グローバル）を選択します。

{
  "servers": {
    "mineru": {
      "command": "npx",
      "args": ["-y", "mineru-mcp"],
      "env": {
        "MINERU_API_KEY": "your-api-key"
      }
    }
  }
}

注：VS Code では、最上位のキーに "mcpServers" ではなく "servers" を使用します。他の VS Code 派生版（Trae、Void、PearAI など）も通常、同じ形式を使用します。

Cursor

~/.cursor/mcp.json（グローバル）または .cursor/mcp.json（プロジェクト）に追加します。

{
  "mcpServers": {
    "mineru": {
      "command": "npx",
      "args": ["-y", "mineru-mcp"],
      "env": {
        "MINERU_API_KEY": "your-api-key"
      }
    }
  }
}

Windsurf

~/.codeium/windsurf/mcp_config.json（Windows：%USERPROFILE%\.codeium\windsurf\mcp_config.json）に追加します。

{
  "mcpServers": {
    "mineru": {
      "command": "npx",
      "args": ["-y", "mineru-mcp"],
      "env": {
        "MINERU_API_KEY": "your-api-key"
      }
    }
  }
}

Cline

Cline パネルの MCP Servers アイコンを開き、Configure > Advanced MCP Settings を選択してから、次の内容を追加します。

{
  "mcpServers": {
    "mineru": {
      "command": "npx",
      "args": ["-y", "mineru-mcp"],
      "env": {
        "MINERU_API_KEY": "your-api-key"
      }
    }
  }
}

Cherry Studio

Settings > MCP Servers > Add Server で、Type を STDIO、Command を npx、Args を -y mineru-mcp に設定し、環境変数 MINERU_API_KEY を追加します。または、JSON/Code モードに貼り付けます。

{
  "mineru": {
    "name": "MinerU",
    "command": "npx",
    "args": ["-y", "mineru-mcp"],
    "env": {
      "MINERU_API_KEY": "your-api-key"
    },
    "isActive": true
  }
}

Witsy

Settings > MCP Servers で新しいサーバーを追加し、Type を stdio、Command を npx、Args を -y mineru-mcp に設定して、環境変数 MINERU_API_KEY に API キーを設定します。

Codex CLI（TOML 設定）

または、~/.codex/config.toml を直接編集します。

[mcp_servers.mineru]
command = "npx"
args = ["-y", "mineru-mcp"]

[mcp_servers.mineru.env]
MINERU_API_KEY = "your-api-key"

Gemini CLI（JSON 設定）

または、~/.gemini/settings.json を直接編集します。

{
  "mcpServers": {
    "mineru": {
      "command": "npx",
      "args": ["-y", "mineru-mcp"],
      "env": {
        "MINERU_API_KEY": "your-api-key"
      }
    }
  }
}

Windows

Windows では、npx にシェルラッパーが必要です。"command": "npx" を次のように置き換えます。

{
  "command": "cmd",
  "args": ["/c", "npx", "-y", "mineru-mcp"],
  "env": {
    "MINERU_API_KEY": "your-api-key"
  }
}

Windows で CLI ツールを使用する場合：

claude mcp add mineru-mcp -e MINERU_API_KEY=your-api-key -- cmd /c npx -y mineru-mcp
codex mcp add mineru --env MINERU_API_KEY=your-api-key -- cmd /c npx -y mineru-mcp

ChatGPT

ChatGPT がサポートしているのは、HTTPS 経由のリモート MCP サーバーのみです。このようなローカルの stdio サーバーは直接サポートされていません。HTTP トランスポートを使用するには、パブリック URL の背後にデプロイする必要があります。

CLI：mineru-cloud

すべてのツールはシェルコマンドとしても使用できます。CLI はインメモリトランスポート経由で MCP サーバーをプロセス内で実行するため、両者の動作にずれは生じません。環境変数は共通です（MINERU_API_KEY、MINERU_BASE_URL、MINERU_DEFAULT_MODEL）。

mineru-cloud list                                    # commands + options (from the tool schemas)
mineru-cloud parse --url https://arxiv.org/pdf/2303.08774 --pages 1-10
mineru-cloud status --task-id <id> --wait            # --wait polls every 10s until done/failed
mineru-cloud batch --urls '["https://…/a.pdf","https://…/b.pdf"]'
mineru-cloud download-results --batch-id <id> --output-dir ./papers --wait

# Long document: slice, then stitch
mineru-cloud parse-long --url https://…/book.pdf --total-pages 520 --name book
mineru-cloud merge-slices --batch-id <id> --output-dir ./books --wait

オプションはツールのパラメーターに対応し、_ は - に置き換えます（--total-pages、--output-dir）。数値、true／false、JSON 配列は型変換されます。インストール方法：bun add -g mineru-mcp（または npm i -g）。

オフライン成果物バンドル

既存のプロバイダー ZIP と元の PDF を使って、移植可能な Scholia v1.0.1 バンドルを作成します。このコマンドはオフラインで実行され、API キーは不要です。

mineru-cloud bundle --source /absolute/source.pdf --archive /absolute/result.zip \
  --output /absolute/bundles --json

このコマンドは bundle_dir を返します。これは bundle.json、元の PDF、バイト単位で同一の ZIP を含む不変のディレクトリです。インポートするには、ディレクトリ全体を移動してください。同じ入力を再度指定すると、既存のバイト列を検証して同じバンドルを返します。任意の --batch-id と --model を指定すると、呼び出し元が指定したメタデータを記録できます。--binding caller_asserted を指定すると、条件付きの関連付けを記録します。既定値は unknown です。どちらを選んでも、プロバイダーが該当する PDF のバイト列を解析したことは証明されません。このコマンドは、ファイル名からページ範囲、要求されたオプション、プロバイダーのバージョンを推測しません。

このバンドルの対象となるのは PDF ソースのみです。既存の PDF 以外のクラウドコマンドも引き続き利用でき、診断用インベントリを生成します。安全でないアーカイブは、インポート可能なバンドルの外にある隔離領域に保持されます。ZIP64、暗号化されたアーカイブ、特殊ファイル、判別不能な旧形式のファイル名エンコーディング、安全でないパスや競合するパスは拒否されます。

完全なダウンロードと構造化ステータス

download-results は各 ZIP を {name}/archives/<sha256>.zip に保持し、不明な形式も含むすべてのメンバーを網羅した inventory.json を書き込みます。また、選択が曖昧でない場合は、従来形式の {name}.md、{name}_content.json、画像のコピーも作成します。Markdown ファイルが見つからない場合や選択が曖昧な場合でも、アーカイブは破棄されません。シェルの unzip 実行ファイルは使用しません。インベントリのハッシュは展開されたバイト列を逐次処理して計算します。選択された互換性用コピーには、別途 64 MiB のサイズ制限が適用されます。

ライフサイクルコマンドで --json を使用すると、操作 ID、正規化された状態、ポーリング可否、件数、エラーを構造化形式で取得できます。--wait は、表示ページ外のエントリを含むバッチ全体で、型付きの状態を使用します。最大 30 分間、10 秒ごとにポーリングします。失敗したエントリがあっても、ほかの保留中のエントリは表示されます。不明なプロバイダーの状態は、明示的に不明として扱われます。終了ステータスは、失敗の場合は 1、一部の結果または不明な結果の場合は 2 です。既存の 8 つの MCP ツール名と、それぞれの CLI コマンドは引き続き利用できます。

スライスのマージでは、各アーカイブがハッシュを含むディレクトリに保持されます。後続のマージ後も、以前の画像リンクは有効です。マージされたコンテンツ JSON は、ページオフセットを仮定したフラットな配列ではなく、アーカイブ参照を含むスライスのレシートです。Markdown が見つからない場合やスライスが失敗した場合は、部分的な結果であることが明示されます。それ以外の場合でも、網羅範囲と元の PDF ページの出所は不明のままです。

永続的なスタンドアロン操作

追加された 6 つのコマンドは、MCP と実装を共有しています。

mineru-cloud capabilities --api v4 --json
mineru-cloud submit --file /absolute/source.pdf --api v4 --model vlm --output-dir /absolute/results --json
mineru-cloud operation-status --operation-id ID --json
mineru-cloud resume --operation-id ID --wait --wait-timeout-seconds 1800 --json
mineru-cloud cancel --operation-id ID --json
mineru-cloud bundle --operation-id ID --json

MINERU_STATE_DIR はジャーナルのルートを指定します。デフォルトは ~/.local/share/mineru-cloud です。復旧のため、このディレクトリは保持してください。ジャーナルには、 ソースのバイト列、リクエストのフィンガープリント、リモート ID、完了した出力のハッシュ、 フェーズのチェックポイントが保持されます。認証情報と署名付き URL はプロセスメモリ内に留まります。 完全に重複する送信は、記録済みの操作に合流します。割り当て ID またはジョブ ID が失われた場合は 照合が必要で、自動再送信は行われません。保存済みのバッチ ID がある曖昧な V4 アップロードは、 そのバッチのポーリングを再開します。V1 では、不確かな完了処理を続行する前に既知のアップロードを 確認します。

一度にライターロックを保持できるプロセスは 1 つだけです。通常のデッドプロセスのロックは、 所有者トークンの確認によって回収できます。ロック回復手順が中断された場合、または PID が再利用された場合は、 明示的なビジー／回復エラーを返して処理を停止します。このファイルシステムジャーナルは、 Scholia の SQLite リースおよび予約システムとは別のものです。Scholia のワーカーのスケジューリングや メンテナンスに関する保証を主張するものではありません。

operation-status は、--refresh が指定されていない限りローカルの情報を読み取ります。resume は 安全なチェックポイントから処理を続行します。最終化では、プロバイダーに接続せず、保存済みの出力を使用します。 ローカルでキャンセルしても、リモート処理はキャンセルされず、アップロード済みデータも削除されません。 リモートキャンセルと、失われた ID の自動関連付けは引き続きサポートされません。 完了済みバンドルには、アーカイブと、形式が不明なものも含めたすべての分離出力が保持されます。 プロバイダーのトランスポート完了は、PDF の全ページが網羅されていることを保証するものではありません。

V4 の永続化される submit --pages 1-2,5 は、正のページ番号と両端を含む範囲を受け付けます。 リクエストの上限は 16 KiB、カンマ区切りの区間は 1,024 個です。0、 降順の範囲、および JavaScript の安全な整数範囲外の数値は、 ソースの取得やプロバイダーへの呼び出しの前にエラーになります。元のテキストは操作の識別情報と プロバイダーオプションに保持されます。新しいバンドルには、ソートされ統合された要求区間が記録されますが、 すべて網羅状況は不明です。この指定だけでは、完了ページや欠落ページ、ページマップ、 またはドキュメント全体の網羅性は確定しません。

以前の範囲指定操作を完全に同じ内容で再実行した場合、網羅状況が不明な要求範囲も含め、 元のバンドルのバイト列が保持されます。後から出力を検証して復旧できた場合は、 正規化された範囲指定と元の先行バンドルのハッシュを含む後継バンドルを公開できます。 新しい範囲指定バンドルには別のライター ID が使われます。使用済みアドレスとの競合や、 記録されたバンドルの欠落がある場合は、以前のレシートを書き換えずに処理を停止します。 現在の受け入れ上限を超える以前のセレクターは、検証済みの既存レガシーレシートを再実行する場合に限り使用できます。 新しいバンドルや拡張バンドルを公開したり、プロバイダーへの操作を許可したりすることはできません。

上限回数のダウンロードを試みても 1 つの出力が取得できない場合、操作は検証済みの成功結果と 型付きの失敗詳細を含む部分バンドルを公開します。bundle --operation-id ID で、その保持された証拠を返せます。 後から明示的に resume を実行すると、同じ操作から欠落した出力を復旧し、後継バンドルを公開できます。 以前のバンドルは不変のままです。部分的な結果は、ドキュメントを再送信する許可にはなりません。

新しい操作コマンドは、CLI JSON と MCP の structuredContent で構造化された Result エンベロープを使用し、 互換性のため既存のフラット化されたフィールドも維持します。CLI の終了コードは、ok の場合は 0、 partial または error の場合は 1、引数が無効な場合は 2 です。従来の 8 つのコマンドは、 これまでどおり error=1、partial=2 の終了コードを維持します。オフラインの bundle --source ... --archive ... も、既存の created/existing レシート形式を維持します。 終了コードが 0 以外でも再送信が許可されたとは解釈せず、status、state、および復旧の詳細を確認してください。

プロセス再起動テストでは、実際のソース、送信インテント、出力保持、最終化の各チェックポイントで ワーカーを強制終了します。最初のジャーナルが作成される前に生成された検証済みのソース孤立データは 安全に取り込めますが、不確かなリモート送信は取り込めません。ソースと出力の書き込みは、 ジャーナルから参照される前に同期されます。これらのテストで確認できるのは、プロセスのクラッシュ時の 挙動に限られ、あらゆる電源障害やネットワークファイルシステムに対する耐久性を保証するものではありません。 最新の V1 アダプターは、uploads、parse/jobs、files/{id}/content を使用します。 古い agent/parse API は使用しません。明示的な機能更新では、 health と独立した tiers エンドポイントに問い合わせます。V4 モデルが V1 ティアに マッピングされることはありません。V1 での範囲指定解析はサポートされていません。 エンドポイント固有の検証が完了するまで、ホスト型 V1 の実行はデフォルトで無効です。 フィクスチャテストではアダプターを注入できます。

新しいネットワーク呼び出しには、パブリック HTTPS アドレスが必要です。 DNS の結果は接続時に検証され、固定されます。リダイレクトは再検証され、API 認証情報は引き継がれません。 転送 URL には、明示的に指定されたヘッダーのみが送信されます。プライベート／セルフホスト型エンドポイントには、 別途実装された信頼ポリシーが必要であり、ここでは有効になっていません。 新しい submit が現在受け付けるのは PDF です。元の 8 つのコマンドでは引き続き PDF 以外もサポートされます。 このスタンドアロンのマイルストーンには、アカウントのクォータ予約、自動スケジューラー、 不確定な操作を関連付けるためのオペレーター UI はありません。

公式プロトコルリファレンスは、固定された V1 ガイド、 固定されたサンプル、 および固定された API サーバースキーマです。 現行のガイドは 2026 年 9 月 30 日に確認しました。すべての新しい実行動作は フィクスチャテスト済みです。ライブプロバイダーでの検証、バージョンの更新、リリースは主張していません。

設定

環境変数	デフォルト	説明
MINERU_API_KEY	（必須）	MinerU API の Bearer トークン
MINERU_BASE_URL	https://mineru.net/api/v4	API のベース URL
MINERU_DEFAULT_MODEL	pipeline	デフォルトのモデル：pipeline または vlm

API キーは mineru.net で取得できます。

使用方法

単一の URL を解析する

mineru_parse({
  url: "https://example.com/document.pdf",
  model: "vlm",        // optional: "pipeline" (default) or "vlm"
  pages: "1-10,15",    // optional: page ranges
  ocr: true,           // optional: enable OCR (pipeline only)
  formula: true,       // optional: formula recognition
  table: true,         // optional: table recognition
  language: "en",      // optional: language code
  formats: ["html"]    // optional: extra export formats
})

タスクの進行状況を確認する

mineru_status({
  task_id: "abc-123",
  format: "concise"    // optional: "concise" (default) or "detailed"
})

簡潔な出力：done | abc-123 | https://cdn-mineru.../result.zip

複数の URL をまとめて解析する

mineru_batch({
  urls: ["https://example.com/doc1.pdf", "https://example.com/doc2.pdf"],
  model: "vlm"
})

バッチ処理の進行状況を確認する

mineru_batch_status({
  batch_id: "batch-123",
  limit: 10,           // optional: max results (default: 10)
  offset: 0,           // optional: skip first N results
  format: "concise"    // optional: "concise" or "detailed"
})

ローカルファイルをアップロードする

mineru_upload_batch({
  directory: "/path/to/pdfs",  // scan directory for supported files
  // OR
  files: ["/path/to/doc1.pdf", "/path/to/doc2.pdf"],  // explicit file list
  model: "vlm",        // optional
  formula: true,       // optional
  table: true,         // optional
  language: "en",      // optional
  formats: ["html"]    // optional
})

追跡用に batch_id が返されます。各ファイルの元の名前は data_id を通じて保持されます（スペースはアンダースコアになります）。

結果を Markdown としてダウンロードする

mineru_download_results({
  batch_id: "batch-123",       // from mineru_upload_batch or mineru_batch
  output_dir: "/path/to/output",
  overwrite: false             // optional: overwrite existing files
})

出力ファイル名は data_id に基づいて生成されます（例：my_paper_title.md）。元のファイル名に含まれるスペースはアンダースコアになります。

一般的なローカルファイルのワークフロー

mineru_upload_batch → mineru_batch_status (poll) → mineru_download_results

サポートされている形式

• PDF、DOC、DOCX、PPT、PPTX
• PNG、JPG、JPEG

ローカルの制限とプロバイダーの情報

レガシーのバッチコマンドでは項目数が最大 200 件に制限されます。レガシーのローカルアップロードでは、 200 MiB を超えるファイルは拒否されます。parse-long では、要求する各スライスが 200 ページに制限されます。 これらは現在の実装上のガードであり、プロバイダーアカウントの現在の制限、クォータ、キューの優先度、 サポート対象プランを検証したものではありません。クラウドタスクを承認する場合は、これらを個別に確認してください。 このチェックアウトの合成テストでは、ホスト型解析の精度、速度、言語対応範囲は測定されません。

リリース 1.1.6

MCP SDK 1.29.x と Node.js 18 に対応した Hono アダプターを維持することで、新規インストール時の Node.js 18 HTTP 互換性を復元します。SDK 1.30 では、Node.js 20 を必要とするアダプターが許可されます。 バージョン 1.1.5 はロック済み依存関係のチェックに合格しましたが、公開パッケージのチェックで、 新規インストール時の HTTP 初期化エラーが明らかになりました。 CI は、リポジトリのロックファイルを使わずにパッケージ化された成果物をインストールし、 Node.js 18 で両方のトランスポートをテストするようになりました。SDK の互換性に関する上限は意図的なものです。 新しい SDK を採用する前に、この利用側のインストールゲートで再検討してください。

リリース 1.1.5

メンテナンスリリース：依存関係の更新を監査し、Express 5 と Zod 4 への互換性を確保し、 両方のトランスポートに対する回帰テストを追加しました。MCP ハンドシェイクと HTTP 起動メッセージが、 古い 1.0.2 の値ではなくパッケージのバージョンを報告するようになりました。ツールの入力と ドキュメント処理の動作に変更はありません。

開発

正規の貢献者向け引き継ぎ、タスクの権限、復旧時の不変条件、および Scholia のフィクスチャと統合テストのペアについては、AGENTS.md をお読みください。

開発には Bun 1.4.2 と、推奨される Node.js 24 ランタイムを使用してください。

bun install --frozen-lockfile
bun audit
bun run build
bun run test
bun run test:package

テストでは、合成フィクスチャとローカルの MinerU API のダブルを使用します。ビルド済みの stdio サーバーと HTTP サーバー、永続的な操作の復旧、アーティファクトの正確な保持、バンドルの同一性、およびファイルシステムの封じ込めを、実際の認証情報やプロバイダーへの呼び出しなしで検証します。一時フィクスチャには、macOS と Linux で正規のシステム一時ディレクトリを使用します。これらのチェックでは、実際のプロバイダーを使用した場合の解析精度は確認できません。

main への PR、バージョンタグのプッシュ、および手動でのレジストリ復旧時に、CI は依存関係を監査し、ビルドを実行して、Node.js 24 で macOS と Linux の両方において全テストスイートを実行します。各プラットフォームではさらに、リポジトリのロックファイルなしで新しいパッケージアーカイブをインストールし、Node.js 18 でテストします。このコンシューマーインストールゲートにより、Node 18 の互換性目標を維持します。Dependabot は Bun のマニフェストとロックファイルをまとめて更新します。main への通常のプッシュでは、このワークフローは実行されません。

公開

明示的なリリース許可を得たうえで、package.json、server.json のトップレベルのバージョン、および対応する npm パッケージのバージョンを更新し、上記のチェックを完了してマージした後、対応する vX.Y.Z タグをプッシュしてください。公開前に、CI はタグとこれらすべてのバージョンが一致していることを確認します。既存の ci チェックでは、macOS/Linux のすべての検証ジョブが成功しないと、別の公開ジョブを実行できません。CI は指定されたチェックアウトを一度だけ解決し、その同一のコミットを検証して公開します。公開には Node.js 24 と GitHub OIDC を使用します。npm に公開し、該当するパッケージバージョンが利用可能になるのを待ってから、MCP Registry に登録します。 npm への公開後にレジストリ登録が失敗した場合は、既存の不変なタグを使って登録のみを再試行してください。

gh workflow run publish-mcp.yml --ref main -f registry_tag=vX.Y.Z

vX.Y.Z を、すでに公開済みのタグに置き換えてください。復旧処理では refs/tags/vX.Y.Z を解決し、そのタグのチェックアウトを検証して、npm への公開をスキップし、MCP Registry への登録のみを再試行します。

ライセンス

MIT

リンク

• MinerU — 文書解析サービス
• MinerU GitHub — オープンソース版
• MCP Specification — Model Context Protocol