Skip to main content
Glama

济南AI MCP服务器

铁匠徽章 铁匠徽章

一个 MCP 服务器,通过 Claude 提供对 Jina AI 强大 Web 服务的访问。该服务器实现了三个主要工具:

  • 网页阅读与内容提取

  • 网络搜索

  • 事实核查/基础

特征

工具

read_webpage

  • 以针对 LLM 优化的格式从网页中提取内容

  • 支持多种输出格式(默认、Markdown、HTML、文本、屏幕截图、页面快照)

  • 包含链接和图像的选项

  • 能够为图像生成替代文本

  • 缓存控制选项

search_web

  • 使用 Jina AI 的搜索 API 搜索网页

  • 可配置的结果数量(默认值:5)

  • 支持图像保留和替代文本生成

  • 多种返回格式(markdown、text、html)

  • 返回包含标题、描述和内容的结构化结果

fact_check

  • 使用 Jina AI 的接地引擎对陈述进行事实核查

  • 提供事实性评分和支持证据

  • 可选深度模式,可进行更彻底的分析

  • 返回带有关键引文和支持/矛盾分类的参考文献

Related MCP server: sysauto Ask MCP Server

设置

先决条件

您需要 Jina AI API 密钥才能使用此服务器。请访问https://jina.ai/免费获取。

安装

有两种方法可以使用该服务器:

通过 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

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

Related MCP Connectors

Related MCP Servers