mcp-jina-ai
济南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:本地安装
克隆存储库
安装依赖项:
npm install构建服务器:
npm run build将此配置添加到您的 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 toolsfact_checkC
Fact-check a statement using Jina AI's grounding engine
| Name | Required | Description | Default |
|---|---|---|---|
| deepdive | No | ||
| statement | Yes |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| format | No | ||
| no_cache | No | ||
| with_links | No | ||
| with_images | No | ||
| with_generated_alt | No |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | ||
| query | Yes | ||
| retain_images | No | none | |
| return_format | No | markdown | |
| with_generated_alt | No |
TDQS
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.
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.
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.
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.
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.
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.
3 tool updates
v1.0.1- First observed
fact_check - First observed
read_webpage - First observed
search_web
TDQS
Scored across 3 tools
Each tool targets a distinct operation: fact-checking a statement, reading a webpage, and searching the web. No overlap in purpose.
All tool names follow a consistent verb_noun pattern using snake_case: fact_check, read_webpage, search_web.
With three tools, the set is well-scoped for a web and grounding server, covering the core tasks without extraneous tools.
The tool surface covers the essential workflow: search, retrieve, and verify. No obvious gaps given the server's apparent purpose.
Maintenance
Related MCP Connectors
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
An MCP server that integrates with Discord to provide AI-powered features.
MCP server for OpenAI API (chat completions, image generation, embeddings) via AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
Related MCP Servers
- AlicenseAqualityDmaintenanceAn MCP server that enables Claude to perform web searches using Perplexity's API with intelligent model selection based on query intent and support for domain and recency filtering.64MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that integrates with Sonar API to provide Claude with real-time web search capabilities for comprehensive research.7 npmMIT
- AlicenseDqualityFmaintenanceMCP server that provides Claude AI assistants with the ability to search the web, get news, and perform research using the You.com API.42MIT
- AlicenseNot gradedqualityBmaintenanceMCP server that bridges ChatGPT Plus/Pro to Claude Code, enabling chat, deep research, and image generation via your own account.172 PyPI50MIT