Jina AI Remote MCP Server

CLI version [](https://lmstudi.ai/install-mcp?name=jina-mcp-server\\\\&0g=eyJ1cmwiOiJodHRwczovL2jcS5qaW5h.mFhL3YvIiwiaGVhZGVycyI6eyJ1dXRob3JpemF0aW9uIjoiQmVhcmVyIppbmF5WUVRliBUEls...

(リンクURLは完全に保持)

リモートのModel Context Protocol (MCP) サーバーであり、Jina Reader API・Embeddings API・Reranker APIへのアクセスを提供します。URLからMarkdownへの変換、ウェブ検索、画像検索、埋め込み/リランクのツール群を備えています：

困ったとき：[Reader API]などのJina APIのレートリミットはhttps://jina.aiのAPIキーで解除できます。APIキーなしでもこれらのツールは動作しますが、レートが制限されます。詳しくはhttps://jina.ai/api-dashboard/rate-limitをご覧ください。

使用方法

[!WARNING] 一部のクライアントは環境変数をサポートしていないため、下記の設定の中の${JINA_API_KEY}を、実際のAPIキーjina_xxxに置き換える必要があるかもしれません。

[!NOTE] このサーバーはMCP Streamable HTTPトランスポートを使用しています。旧クライアントとの互換性のために/sseエンドポイントも別名として維持されています。詳細はFAQを参照してください。

リモートMCPサーバーをサポートするクライアントの場合：

{
  "mcpServers": {
    "jina-mcp-server": {
      "url": "https://mcp.jina.ai/v1",
      "headers": {
        "Authorization": "Bearer ${JINA_API_KEY}" // optional
      }
    }
  }
}

まだリモートッMCPサーバーをサポートしていないクライアントの場合は、リモートMCPサーバーに接続するためのローカルプロキシmcp-remoteが必要です。

{
  "mcpServers": {
    "jina-mcp-server": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://mcp.jina.ai/v1",
        "--header",
        "Authorization: Bearer ${JINA_API_KEY}"
      ]
    }
  }
}

Claude Codeの場合：

[!WARNING] /sseからアップグレードする場合？ 以前に--transport sseで追加した場合は、まずclaude mcp remove -s user jinaで削除し、その後に下記のコマンドで再追加してください。

claude mcp add -s user --transport http jina https://mcp.jina.ai/v1 \
  --header "Authorization: Bearer ${JINA_API_KEY}"

OpenAI Codexの場合：~/.codex/config.tomlを見つけて、次のように追加します：

[mcp_servers.jina-mcp-server]
command = "npx"
args = [
    "-y",
    "mcp-remote",
    "https://mcp.jina.ai/v1",
    "--header",
    "Authorization: Bearer ${JINA_API_KEY}"]

Related MCP server: Sentinel Core Agent

ツールを登録前にフィルタリングする

すべてのMCPツールは、ツール名・説明・スキーマ用にコンテキストウィンドウ内のトークンをLLMが事前に割り当てる必要があります。コンテキストウィンドウが小さいLLMでは、21個のツールをすべて登録すると、実際の作業を始める前に大量のスペースを消費します。

エンドポイントURLのクエリパラメータ（/v1?...）でサーバー側のフィルタリングをすると、除外したツールがMCPクライアントに登録されず、クライアントとLLMはそのツールを認識しないため、コンテキストウィンドウを節約できます。

クエリパラメータ

利用可能なタグ

優先順位

フィルターは次の順序で適用されます（優先度の高い順）：

1. exclude_tools - 指定されたツールを常に除外します

2. exclude_tags - 指定されたタグ内のツールを除外します

3. include_tools - 指定されたツールを含めます

4. include_tags - 指定されたタグ内のツールのみから開始します

例

並列ツールを除外します（約4ツール分のコンテキストトークンを節約）：

{
  "mcpServers": {
    "jina-mcp-server": {
      "url": "https://mcp.jina.ai/v1?exclude_tags=parallel",
      "headers": {
        "Authorization": "Bearer ${JINA_API_KEY}"
      }
    }
  }
}

検索ツールと読み取りツールのみを含めます：

{
  "mcpServers": {
    "jina-mcp-server": {
      "url": "https://mcp.jina.ai/v1?include_tags=search,read",
      "headers": {
        "Authorization": "Bearer ${JINA_API_KEY}"
      }
    }
  }
}

特定のツールを除外します：

{
  "mcpServers": {
    "jina-mcp-server": {
      "url": "https://mcp.jina.ai/v1?exclude_tools=search_images,deduplicate_images",
      "headers": {
        "Authorization": "Bearer ${JINA_API_KEY}"
      }
    }
  }
}

トラブルシューティング

ツール呼び出しループにはまってしまいました - 何が起きたのですか？

これはLMStudioで、デフォルトのコンテキストウィンドウが4096で、gpt-oss-120bやqwen3-4b-thinkingのような思考モデルを使用している場合によくある問題です。思考とツール呼び出しが続くと、コンテキストウィンドウの上限に達した時点で、AIはタスクの最初の部分を見失い始めます。それがこのローリングコンテキストウィンドウに閉じ込められる仕組みです。

解決策は、ツール呼び出しの連鎖と思考プロセス全体を収められる十分なコンテキスト長でモデルを読み込むことです。

すべてのツールが見えません。

一部のMCPクライアントにはローカルキャッシュがあり、ツール定義を積極的に更新しません。利用可能なすべてのツールが表示されない場合や、ツールが古いように見える場合は、MCPクライアント設定からjina-mcp-serverを削除して再追加する必要があるかもしれません。これにより、クライアントはキャッシュされたツール定義を強制的に更新します。LMStudioでは、更新ボタンをクリックして新しいツールを読み込むことができます。

Claude DesktopがWindowsで「サーバーが切断されました」と表示する

CursorとClaude Desktop（Windows）にはバグがあり、npxを呼び出す際に引数内のスペースがエスケープされず、結果としてこれらの値が壊れてしまいます。次のようにして回避できます：

{
  // rest of config...
  "args": [
    "mcp-remote",
    "https://mcp.jina.ai/v1",
    "--header",
    "Authorization:${AUTH_HEADER}" // note no spaces around ':'
  ],
  "env": {
    "AUTH_HEADER": "Bearer <JINA_API_KEY>" // spaces OK in env vars
  }
},

CursorがこのMCPステータスに赤い点を表示する

おそらくCursorのUIバグですが、MCPは問題なく正しく動作します。赤い点が気になる場合は、オフ/オンを切り替えてMCPを「再起動」できます（実際には、これをリモートMCPとして使用しているため、本当の「サーバー再起動」ではなく、主にローカルプロキシの再起動です）。

私のLLMが一部のツールを決して使わない

MCPクライアントですべてのツールが有効になっているのに、LLMが一部のツールを決して使わない、または特定のツールを優先する場合、これはLLMが特定のツールセットでトレーニングされている場合によく見られます。例えば、parallel_*ツールが明示的に指示されない限り、LLMが自然に使用することはほとんどありません。一部の研究では、LLMはparallel_*を使用するようにトレーニングされる必要があるとされています。Qwen3-Nextのようなモデルは、並列性を達成するために配列内の複数のクエリを持つシングルトンバージョンを呼び出すことをネイティブに好みます（これも当社のMCPが現在サポートしています）。いずれにせよ、Cursorでは、.mdcファイルに次のルールを追加できます：

---
alwaysApply: true
---

When you are uncertain about knowledge, or the user doubts your answer, always use Jina MCP tools to search and read best practices and latest information. Use search_arxiv and read_url together when questions relate to theoretical deep learning or algorithm details. Use search_ssrn for social sciences, economics, law, and finance research. search_web, search_arxiv, and search_ssrn cannot be used alone - always combine with read_url or parallel_read_url to read from multiple sources. Remember: every search must be complemented with read_url to read the source URL content. For maximum efficiency, use parallel_* versions of search and read when necessary.

コンテンツが切り詰められるのはなぜですか？

Claude Code、Claude Desktop、Cursorは、MCPツールの応答に固定の25kトークン制限を課しています。これらのクライアントが大きな応答を完全に拒否するのを防ぐため、このサーバーはread_urlとparallel_read_urlにトークンガードレールを適用します。

項目は、収まる限り元の順序で全体が保持されます。収まらない最初の項目は収まるプレフィックスに切り詰められ、それ以降はすべて破棄されます。切り詰められた内容や省略された内容を示す短い[jina-mcp] ...メモが追加され、モデルが完全なドキュメントではなく部分的なドキュメントを見ていることを認識できるようにします。単一の項目が予算を超えていても、少なくとも1つの項目は常に残ります。

サーバーは意図的に制限をちょうどではなく下回ることを目指しています。そうする必要があるのです：サーバーはcl100kでトークンを数える一方、クライアントは独自のトークナイザーで数え、切り詰めは比例的な文字推定であり、クライアントは生のテキストではなくシリアライズされたJSONペイロードを測定します。そのため、サーバーはトークン予算に加えて、許可トークンあたり3バイトのハード上限を強制します。これは、ASCII散文（約3.6バイト/トークン）とCJK（約3バイト/トークン）の両方でトークナイザーに関係なく成立します。拒否された応答は何も提供しないため、低めに見積もる方が安上がりなミスです。

任意のクライアントは、エンドポイントURLのmax_tokensで独自の予算を設定できます（例：https://mcp.jina.ai/v1?max_tokens=50000）。max_tokens=0は切り詰めを完全に無効にします。OpenAI Codex（tool_output_token_limit）など、設定可能な制限を持つクライアントは、それ以外はそのままにされます。

並列ツールと配列を使用したシングルトンツールの使い分け

Claude Codeは最近、並行操作のためにparallel_*ツール（parallel_search_web、parallel_read_urlなど）を好むようになりました。ただし、Qwen3-Nextのようなモデルは、配列内の複数のクエリを持つシングルトンツールを呼び出すことを好みます。どちらのアプローチも機能します：シングルトンバージョン（search_web、search_arxiv、search_ssrn、read_url）は、query/urlパラメータに単一の文字列または文字列の配列のいずれかを受け入れます。配列が与えられると、これらのツールは内部的にすべてのクエリを自動的に並列実行し、parallel_*ツールを明示的に呼び出すのと同じ並行動作を生成します。モデルが好むスタイルを使用してください。配列は5エントリに制限されており、これはparallel_*ツールが強制するのと同じ制限です。

エンドポイントが/sseと呼ばれるのに、Streamable HTTPを使用するのはなぜですか？

/sseエンドポイントURLは、既存ユーザーとの後方互換性のために維持されています。推奨エンドポイントは現在/v1です。両方とも同じStreamable HTTPトランスポート（spec 2025-03-26の新しいMCP標準）を使用しており、非推奨のSSEトランスポートではありません。

これはシームレスに機能します。なぜなら：

• Claude Desktop、Cursor、Windsurfはmcp-remoteを使用し、http-first戦略がデフォルトです（最初にStreamable HTTPを試します）

• Claude Codeは両方のトランスポートをネイティブにサポートしています

• LM StudioはStreamable HTTPエンドポイントへの直接接続をサポートしています

応答ストリーミングは引き続きSSE形式（Content-Type: text/event-stream）を使用しますが、プロトコル層（セッション管理、初期化）はStreamable HTTP仕様に従います。すべての主要なMCPクライアントが互換性があります。

mcp-remoteを使用したクライアント側ツールフィルタリング

ローカルプロキシとしてmcp-remoteを使用している場合、その--ignore-toolフラグを使用してクライアント側でツールをフィルタリングすることもできます：

{
  "mcpServers": {
    "jina-mcp-server": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://mcp.jina.ai/v1",
        "--header",
        "Authorization: Bearer ${JINA_API_KEY}",
        "--ignore-tool", "parallel_search_web",
        "--ignore-tool", "parallel_search_arxiv",
        "--ignore-tool", "parallel_read_url"
      ]
    }
  }
}

このアプローチは、ツールがMCPクライアントに到達する前にプロキシレベルでフィルタリングします。ただし、クエリパラメータによるサーバー側フィルタリング（ツールフィルタリングを参照）の方が、ソースからのトークン使用量を削減するため、より効率的です。

質問を念頭に置いてページを読む

デフォルトではread_urlはページ全体を返し、モデルは1つの質問に答えるためにそのすべてのトークンを支払います。questionを渡すと、ページは代わりにパッセージに分割され、Reranker v3.5でスコアリングされ、上位ランクのパッセージのみが返されます — これはsearch_web_deepが結果ページに対して実行するパイプラインとまったく同じで、すでに持っているURLで利用できます。

3つすべてがオプションであり、questionが他の2つを制御するため、既存の呼び出しはバイト単位で変更されません。

// full page: 13,713 bytes, 233 ms
{ "url": "https://jina.ai/news/what-late-chunking-really-is-and-what-its-not-part-ii/" }

// one passage: 756 bytes (5.5%), 569 ms
{ "url": "https://jina.ai/news/what-late-chunking-really-is-and-what-its-not-part-ii/",
  "question": "Which embedding models support late chunking?", "topk": 2 }

質問に基づく応答にはquestion、snippets、snippet_source: contentが含まれ、contentは省略されます。抽出を実行できない場合 — 空のページ、読み取れないページ、またはランク付けに使用するAPIキーがない場合 — ランク付けされた回答を装ったプレフィックスではなく、snippet_source: full_contentとその旨を示すnoteを含む完全な本文が返されます。

調整前に知っておくべき3つのこと：

• スコアは信頼度シグナルを兼ねています。 ページが答えない質問をすると、本物のヒットよりも桁違いに低いスコアになります（測定値：0.02対0.51〜0.81）。上位スコアが低い場合は「このページには書かれていない」ことを意味し、「ランキングが失敗した」ことを意味しません。

• コードブロックとテーブルはランキング前に削除されます。 チャンカーはナビゲーション要素とともにそれらを削除し、定型文が語彙的重複で勝つのを防ぎます。トレードオフとして、インストールコマンドや仕様テーブルは対象パッセージにならないため、*「Xのインストール方法」*はこのパラメータにはあまり適していません。

• レイテンシは通常の読み取りの約2倍です。パッセージ抽出がフェッチと並行して実行され、再ランク呼び出しが追加されるためです。parallel_read_urlは、いずれかのエントリにquestionがある場合、独自のタイムアウト下限を60秒に引き上げます。

search_webとsearch_web_deepの違いは何ですか？

search_webは検索エンジンが選んだスニペットを返します — 約20語で、多くの場合、質問に答えることのないキーワードを含む断片です。search_web_deepはReaderを介して各ページも読み取り、文の境界で約100語のパッセージに分割し、すべてのページのすべてのパッセージを1回のリストワイズReranker呼び出しでスコアリングするため、任意のページのパッセージが他のパッセージを上回ることができます。snippet_source=auto（デフォルト）は、各ページのエンジンスニペットを追加の候補として入力し、各結果のsnippet_sourceフィールドがどれが勝ったかを示します。contentはそれに入力されず、読み取れなかったページは省略されるため、numより少ない結果を返す場合があります。

ライブサーバーからのモード別トップ5。スニペットは開始と終了を保持し、中央は(...n chars...)に置き換えられ、長さがわかるようになっています：

英語 — what is the latest model from jina ai

中国語 — jina ai 最新的模型是什么

• エンジンのスニペットがより良い回答になることもある。 英語 auto の上位3件は serp として返され、短く、最初の結果はどの抽出パッセージよりも直接的にそのクエリに答えています。一方で content は jina.ai のホームページへのナビを優先します。後段で完全なパッセージが必要でなければ、auto を優先してください。

• 再ランカーは新しさではなく関連性を評価します。 中国語の deep の2回の実行はどちらも、最新 のモデルを問うクエリに対して2023年の jina-embeddings-v2 の記事を最初にランク付けしています。tbs で期間を絞るか、各結果の date を確認してください。

• パッセージは常に約100語で統一されているわけではありません。 ナビゲーションが多いページには分割に使える文の句読点がないため、英語 content の最初の2件は各パッセージの上限である約2,000文字に達しています。

開発者ガイド

ローカル開発

# Clone the repository
git clone https://github.com/jina-ai/MCP.git
cd MCP

# Install dependencies
npm install

# Start development server
npm run start

Cloudflare Workers にデプロイ

これにより、MCP サーバーが次のような URL にデプロイされます: jina-mcp-server.<your-account>.workers.dev/v1