A
licenseA
qualityF
maintenanceIntegrates Jina.ai's Grounding API with LLMs for real-time, fact-based web content grounding and analysis, enhancing LLM responses with precise, verified information.
1
31 npm
1
MIT
MCP JinaAI Reader Server
by spences10
mcp-jinaai-阅读器
⚠️ 通知
此存储库不再维护。
该工具的功能现已在mcp-omnisearch中提供，它将多个 MCP 工具组合在一个统一的包中。
请改用mcp-omnisearch 。
一个模型上下文协议 (MCP) 服务器，用于集成 Jina.ai 的阅读器 API 与 LLM。该服务器提供高效全面的 Web 内容提取功能，并针对文档和 Web 内容分析进行了优化。
Related MCP server: Jina AI Remote MCP Server
特征
📚 通过 Jina.ai Reader API 进行高级网页内容提取
🚀 快速高效的内容检索
📄 完整提取文本并保留结构
🔄 针对法学硕士 (LLM) 优化的简洁格式
🌐 支持各种内容类型，包括文档
🏗️ 基于模型上下文协议
配置
此服务器需要通过您的 MCP 客户端进行配置。以下是不同环境的示例：
克莱恩配置
将其添加到您的 Cline MCP 设置中：
{
"mcpServers": {
"jinaai-reader": {
"command": "node",
"args": ["-y", "mcp-jinaai-reader"],
"env": {
"JINAAI_API_KEY": "your-jinaai-api-key"
}
}
}
}带有 WSL 配置的 Claude 桌面
对于 WSL 环境，将其添加到您的 Claude Desktop 配置中：
{
"mcpServers": {
"jinaai-reader": {
"command": "wsl.exe",
"args": [
"bash",
"-c",
"JINAAI_API_KEY=your-jinaai-api-key npx mcp-jinaai-reader"
]
}
}
}环境变量
服务器需要以下环境变量：
JINAAI_API_KEY：您的 Jina.ai API 密钥（必需）
API
服务器实现了具有可配置参数的单个 MCP 工具：
读取网址
使用 Jina.ai Reader 将任何 URL 转换为 LLM 友好文本。
参数：
url（字符串，必需）：要处理的 URLno_cache（布尔值，可选）：绕过缓存以获取最新结果。默认为 falseformat（字符串，可选）：响应格式（“json”或“stream”）。默认为“json”timeout（数字，可选）：等待网页加载的最长时间（秒）target_selector（字符串，可选）：CSS 选择器用于关注特定元素wait_for_selector（字符串，可选）：用于等待特定元素的 CSS 选择器remove_selector（字符串，可选）：用于排除特定元素的 CSS 选择器with_links_summary（布尔值，可选）：收集响应末尾的所有链接with_images_summary（布尔值，可选）：在响应末尾收集所有图像with_generated_alt（布尔值，可选）：向缺少标题的图像添加替代文本with_iframe（布尔值，可选）：在响应中包含 iframe 内容
发展
设置
克隆存储库
安装依赖项：
npm install构建项目：
npm run build以开发模式运行：
npm run dev出版
更新 package.json 中的版本
构建项目：
npm run build发布到 npm：
npm publish贡献
欢迎贡献代码！欢迎提交 Pull 请求。
执照
MIT 许可证 - 有关详细信息，请参阅LICENSE文件。
致谢
基于模型上下文协议
由Jina.ai 阅读器 API提供支持
Available Tools
1 toolread_urlB
Convert any URL to LLM-friendly text using Jina.ai Reader
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to process | |
| no_cache | No | Bypass cache for fresh results | |
| format | No | Response format (json or stream) | json |
| timeout | No | Maximum time in seconds to wait for webpage load | |
| target_selector | No | CSS selector to focus on specific elements | |
| wait_for_selector | No | CSS selector to wait for specific elements | |
| remove_selector | No | CSS selector to exclude specific elements | |
| with_links_summary | No | Gather all links at the end of response | |
| with_images_summary | No | Gather all images at the end of response | |
| with_generated_alt | No | Add alt text to images lacking captions | |
| with_iframe | No | Include iframe content in response |
TDQS
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic function without disclosing behavioral traits like rate limits, authentication needs, error handling, or performance characteristics. It mentions the external service (Jina.ai Reader) but doesn't explain implications of using a third-party service.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that clearly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality, making every word earn its place.
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?
For a complex tool with 11 parameters and no output schema, the description is insufficient. It doesn't explain what 'LLM-friendly text' means in practice, doesn't describe the response format, and provides no guidance on parameter interactions or error cases. The lack of output schema increases the need for more descriptive context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing comprehensive parameter documentation. The description adds no parameter-specific information beyond the schema, maintaining the baseline score. It doesn't explain relationships between parameters or provide usage examples.
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 tool's purpose with specific verb ('Convert') and resource ('any URL') while specifying the method ('using Jina.ai Reader') and output format ('LLM-friendly text'). It distinguishes this as a URL-to-text conversion tool with no siblings to differentiate from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('Convert any URL to LLM-friendly text') but provides no explicit guidance on when to use this tool versus alternatives, prerequisites, or limitations. With no sibling tools, the baseline is adequate but lacks specific usage scenarios.
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 tool update
v1.0.0- First observed
read_url
TDQS
B3.4/5.0
Scored across 1 tool
Disambiguation5/5
With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool's purpose is clearly defined and distinct by default.
Naming Consistency5/5
A single tool inherently has perfect naming consistency, as there are no other tools to compare against. The tool name 'read_url' follows a clear verb_noun pattern.
Tool Count2/5
One tool is too few for a server with a purpose that could reasonably support more operations, such as handling different URL types or providing metadata extraction. This minimal set feels thin and under-scoped for the domain.
Completeness2/5
The server's domain appears to be URL content reading, but the single tool only covers basic text conversion. There are obvious gaps, such as no tools for handling errors, extracting structured data, or managing different content formats, which limits agent effectiveness.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
Jina AI Reader/Search MCP — turn any URL into clean LLM-ready markdown, plus web search.
Clean Markdown and AI-readability scoring for any URL. Built for AI agents.
Cloud scraping & crawling API for AI agents. Turn any URL into clean, LLM-ready markdown.
Convert any webpage to clean LLM-ready markdown, extraction-first, with article and news modes.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceProvides access to Jina AI's web reading, search, embeddings, and reranking capabilities. Enables URL content extraction, web/arXiv/image search, document deduplication, and relevance ranking through natural language.Apache 2.0
- AlicenseNot gradedqualityCmaintenanceProvides web content extraction, search capabilities (web, arXiv, SSRN, images), semantic deduplication, and reranking through Jina AI's Reader, Embeddings, and Reranker APIs.1Apache 2.0
- AlicenseNot gradedqualityDmaintenanceProvides tools for web content extraction, search, embeddings, reranking, and image processing via Jina AI APIs, enabling intelligent data retrieval and analysis.Apache 2.0