Docs Fetch MCP Server
文档获取 MCP 服务器
一个模型上下文协议 (MCP) 服务器,用于获取具有递归探索功能的 Web 内容。该服务器使 LLM 能够自主探索网页和文档,以了解特定主题。
概述
Docs Fetch MCP 服务器为 LLM 提供了一种简单但功能强大的方法来检索和探索 Web 内容。它支持:
从任何网页获取干净、可读的内容
递归探索链接页面直至指定深度
同域链接遍历以收集全面信息
智能过滤导航链接,聚焦内容丰富的页面
当用户希望 LLM 通过浏览文档或网络内容来了解特定主题时,此工具特别有用。
Related MCP server: Spider MCP Server
特征
内容提取:从网页中干净地提取主要内容,消除导航、广告和不相关元素等干扰
链接分析:识别并提取页面中的链接,评估其相关性
递归探索:跟踪指向同一域内相关内容的链接,直至指定深度
并行处理:通过并发请求和适当的错误处理有效地抓取内容
强大的错误处理:优雅地处理网络问题、超时和畸形页面
双策略方法:首先使用快速 axios 请求,然后使用 puppeteer 作为更复杂页面的后备
超时预防:实施全局超时处理,确保在 MCP 时间限制内可靠运行
部分结果:即使某些页面无法完全加载,仍返回可用内容
用法
服务器公开一个 MCP 工具:
fetch_doc_content
获取网页内容,并能够探索指定深度的链接页面。
参数:
url(字符串,必需):要获取的网页的 URLdepth(数字,可选,默认值:1):目录/链接探索的最大深度(1-5)
返回:
{
"rootUrl": "https://example.com/docs",
"explorationDepth": 2,
"pagesExplored": 5,
"content": [
{
"url": "https://example.com/docs",
"title": "Documentation",
"content": "Main page content...",
"links": [
{
"url": "https://example.com/docs/topic1",
"text": "Topic 1"
},
...
]
},
...
]
}安装
克隆此存储库:
git clone https://github.com/wolfyy970/docs-fetch-mcp.git
cd docs-fetch-mcp安装依赖项:
npm install构建项目:
npm run build在 Claude 客户端中配置您的 MCP 设置:
{
"mcpServers": {
"docs-fetch": {
"command": "node",
"args": [
"/path/to/docs-fetch-mcp/build/index.js"
],
"env": {
"MCP_TRANSPORT": "pipe"
}
}
}
}依赖项
@modelcontextprotocol/sdk:MCP 服务器 SDKpuppeteer:用于网页交互的无头浏览器axios:用于发出请求的 HTTP 客户端
发展
要在开发模式下运行服务器:
npm run dev执照
麻省理工学院
Available Tools
1 toolfetch_doc_contentC
Fetch web page content with the ability to explore linked pages up to a specified depth
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Maximum depth of directory/link exploration (default: 1) | |
| url | Yes | URL of the web page to fetch |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the core functionality (fetching and exploring links) but lacks details on permissions, rate limits, error handling, or what the response looks like (e.g., format, size limits). This leaves significant gaps for a tool that interacts with external web resources.
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, efficient sentence that clearly states the tool's purpose and key feature (exploring linked pages). It is front-loaded with the main action and includes no redundant information, making it highly concise and well-structured.
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 the complexity of fetching web content with link exploration, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication needs, rate limits, or response format, which are critical for effective tool use in this context.
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 schema description coverage is 100%, so the schema already documents both parameters ('url' and 'depth') with descriptions and constraints. The description adds minimal value by implying the depth parameter relates to link exploration, but it doesn't provide additional syntax or format details beyond what the schema specifies.
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's purpose with a specific verb ('fetch') and resource ('web page content'), and it adds valuable context about exploring linked pages. However, since there are no sibling tools mentioned, it doesn't need to differentiate from alternatives, which keeps it from reaching a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or exclusions. It mentions the ability to explore linked pages up to a specified depth, but this is more about functionality than usage context.
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
fetch_doc_content
TDQS
Scored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'fetch_doc_content' has a clear and distinct purpose, making it impossible for an agent to confuse it with other tools.
Since there is only one tool, it inherently follows a consistent naming pattern. The tool name 'fetch_doc_content' uses a verb_noun structure, which is clear and predictable, and there are no other tools to cause inconsistency.
A single tool is too few for a server named 'Docs Fetch MCP Server', which implies a domain involving document fetching and exploration. While the tool is well-described, one tool feels thin and insufficient for comprehensive operations like managing fetched content or handling different document types, limiting the server's utility.
The tool surface is severely incomplete for the inferred domain of document fetching. It only provides a fetch operation with depth control, missing essential functions such as listing fetched documents, updating or deleting cached content, searching within documents, or handling errors, which are necessary for a complete workflow.
Maintenance
Related MCP Connectors
Web data for agents. Extract web pages, crawl websites, discover URLs, and search the web.
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
Hosted browser for agents: open pages, search the web, extract data, read PDFs and take screenshots.
Crawls any documentation or SaaS site and compiles a standards-compliant /llms.txt manifest and J.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides AI agents and coding assistants with advanced web crawling and RAG capabilities, allowing them to scrape websites and leverage that knowledge through various retrieval strategies.2MIT
- FlicenseNot gradedqualityDmaintenanceEnables crawling and extracting clean content from documentation websites with optional LLM-powered analysis for intelligent summaries, code example extraction, and content classification.-
- AlicenseNot gradedqualityCmaintenanceEnables LLMs to fetch and extract web content using browser automation, OCR, and multiple extraction methods, handling JavaScript rendering and anti-scraping techniques.17MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI assistants to query and retrieve topic-specific knowledge from recursively crawled and indexed web pages.198 npm11MIT