Skip to main content
Glama
enesjakozh
JoeBuildsStuff

mcp-jina-ai

by JoeBuildsStuff
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Jina AI MCP サーバー

鍛冶屋のバッジ 鍛冶屋のバッジ

Claudeを介してJina AIの強力なウェブサービスへのアクセスを提供するMCPサーバー。このサーバーは3つの主要ツールを実装しています。

  • Webページの読み取りとコンテンツの抽出

  • ウェブ検索

  • ファクトチェック/根拠

特徴

ツール

read_webpage

  • LLM に最適化された形式で Web ページからコンテンツを抽出します

  • 複数の出力形式をサポート (デフォルト、マークダウン、HTML、テキスト、スクリーンショット、ページショット)

  • リンクと画像を含めるオプション

  • 画像の代替テキストを生成する機能

  • キャッシュ制御オプション

search_web

  • Jina AIの検索APIを使用してウェブを検索する

  • 設定可能な結果数（デフォルト: 5）

  • 画像保持と代替テキスト生成のサポート

  • 複数の戻り形式（マークダウン、テキスト、HTML）

  • タイトル、説明、コンテンツを含む構造化された結果を返します

fact_check

  • Jina AIのグラウンディングエンジンを使用してステートメントをファクトチェックする

  • 事実スコアと裏付けとなる証拠を提供する

  • より徹底的な分析のためのオプションのディープダイブモード

  • 重要な引用と支持/反論の分類を含む参考文献を返します

Related MCP server: sysauto Ask MCP Server

設定

前提条件

このサーバーを使用するには、Jina AI APIキーが必要です。https ://jina.ai/から無料で取得できます。

インストール

このサーバーを使用するには 2 つの方法があります。

Smithery経由でインストール

Smithery経由で Claude Desktop 用の Jina AI を自動的にインストールするには:

npx -y @smithery/cli install jina-ai-mcp-server --client claude

オプション 1: NPX (推奨)

この構成を Claude Desktop 構成ファイルに追加します。

{
  "mcpServers": {
    "jina-ai-mcp-server": {
      "command": "npx",
      "args": [
        "-y",
        "jina-ai-mcp-server"
      ],
      "env": {
        "JINA_API_KEY": "<YOUR_KEY>"
      }
    }
  }
}

オプション2: ローカルインストール

  1. リポジトリをクローンする

  2. 依存関係をインストールします:

npm install

  1. サーバーを構築します。

npm run build

  1. この構成を Claude Desktop 構成に追加します。

{
  "mcpServers": {
    "jina-ai-mcp-server": {
      "command": "node",
      "args": [
        "/path/to/jina-ai-mcp-server/dist/index.js"
      ],
      "env": {
        "JINA_API_KEY": "<YOUR_KEY>"
      }
    }
  }
}

設定ファイルの場所

MacOSの場合:

~/Library/Application Support/Claude/claude_desktop_config.json

Windowsの場合:

%APPDATA%/Claude/claude_desktop_config.json

デバッグ

MCPサーバーはstdio経由で通信するため、デバッグが困難になる場合があります。MCP Inspectorの使用をお勧めします。

npm run inspector

インスペクターは、ブラウザでデバッグ ツールにアクセスするための URL を提供します。

APIレスポンスタイプ

すべてのツールは、次の内容を含む構造化された JSON 応答を返します。

  • ステータスコードとメタデータ

  • 要求された出力タイプに基づいてフォーマットされたコンテンツ

  • 使用情報（トークン数）

  • 該当する場合: 画像、リンク、追加のメタデータ

詳細なスキーマ情報については、 schemas.tsを参照してください。

Available Tools

3 tools
fact_checkC

Fact-check a statement using Jina AI's grounding engine

ParametersJSON Schema
NameRequiredDescriptionDefault
deepdiveNo
statementYes

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries full burden but only states the action. It does not disclose whether the tool returns a verdict, an explanation, or requires additional context. No mention of side effects or limitations.

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?

Extremely concise, single sentence, front-loaded with the main purpose. However, it sacrifices informative details that could be added without much length.

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 no output schema, no annotations, and 2 parameters, the description lacks details on return values, error cases, and parameter behavior. It is insufficient for an agent to fully understand the tool's usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description adds no meaning to parameters. The 'deepdive' boolean parameter is not explained. The description only mentions 'statement' implicitly.

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 'fact-check', the resource 'a statement', and the specific engine 'Jina AI's grounding engine'. It distinguishes itself from sibling tools 'read_webpage' and 'search_web' by focusing on verification rather than retrieval.

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 on when to use this tool versus alternatives. For instance, it does not clarify that fact-check should be used for verifying claims while search_web or read_webpage are for general information gathering.

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

read_webpageC

Extract content from a webpage in a format optimized for LLMs

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
formatNo
no_cacheNo
with_linksNo
with_imagesNo
with_generated_altNo

TDQS

C2.6/5.0
Behavior2/5

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

No annotations provided. Description lacks disclosure of caching, rate limits, error behavior, or format implications. 'Optimized for LLMs' is vague.

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

Conciseness3/5

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

Very concise single sentence but at cost of completeness. Front-loads purpose but does not earn its place with meaningful detail.

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

Completeness1/5

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

Given 6 parameters, no output schema, and no annotations, the description is severely incomplete. Does not cover return values, parameter details, or behavioral aspects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. Description does not explain any of the 6 parameters (e.g., format, no_cache, with_links). Fails to compensate for missing schema descriptions.

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?

Description clearly states verb 'extract', resource 'content from a webpage', and purpose 'optimized for LLMs'. It distinguishes from siblings like 'fact_check' and 'search_web'.

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 on when to use vs siblings or when not to use. Lacks context for selection.

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

search_webC

Search the web using Jina AI's search API

ParametersJSON Schema
NameRequiredDescriptionDefault
countNo
queryYes
retain_imagesNonone
return_formatNomarkdown
with_generated_altNo

TDQS

C2.4/5.0
Behavior2/5

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

With no annotations, the description must carry the full burden. It only states 'search the web' without disclosing behavioral traits like rate limits, result count limits, or idempotency. The minimal info does not cover core behavioral expectations.

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

Conciseness3/5

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

The description is a single sentence, which is concise but overly minimal. It lacks structure and does not effectively organize details; brevity here sacrifices completeness.

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 5 parameters, no output schema, no annotations, and sibling tools, the description is incomplete. It fails to explain return format, parameter effects, or differentiate from related tools, leaving significant gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 5 parameters with 0% description coverage. The description adds no meaning beyond the schema fields. Parameters like 'count', 'retain_images', and 'return_format' are left unexplained, forcing the agent to guess their semantics.

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 searches the web using Jina AI's API, identifying the verb and resource. However, it does not differentiate from sibling tools like fact_check or read_webpage, missing an opportunity to clarify scope.

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. The description lacks explicit context or exclusions, leaving the agent to infer usage independently.

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. 3 tool updatesv1.0.1
    • First observedfact_check
    • First observedread_webpage
    • First observedsearch_web
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

B3.3/5.0

Scored across 3 tools

Disambiguation5/5

Each tool targets a distinct operation: fact-checking a statement, reading a webpage, and searching the web. No overlap in purpose.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case: fact_check, read_webpage, search_web.

Tool Count5/5

With three tools, the set is well-scoped for a web and grounding server, covering the core tasks without extraneous tools.

Completeness5/5

The tool surface covers the essential workflow: search, retrieve, and verify. No obvious gaps given the server's apparent purpose.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches