MCP 服务器可以从多种语言生态系统中为 Claude 等 LLM 获取包文档，而无需 API 密钥。
🌐 支持多种编程语言（JavaScript、Python、Java、.NET、Ruby、PHP、Rust、Go、Swift）
📦 通过名称或 URL 获取包的文档
🔍 爬取文档网站以提取全面的信息
📄 提取 README、API 文档、代码示例和存储库信息
🧠 为 LLM 摘要提供结构化数据
💬 包含用于文档分析的专门提示
🔑无需 API 密钥- 可与 Claude Desktop 和 Cursor IDE 原生兼容
Related MCP server: Context7 MCP
打开 Claude Desktop → 设置 → 开发者
点击“编辑配置”并添加：
{
"mcpServers": {
"docsFetcher": {
"command": "npx",
"args": [
"-y",
"@smithery/cli@latest",
"run",
"@cdugo/mcp-get-docs",
"--config",
"'{}'"
]
}
}
}打开 Cursor IDE → 设置 → MCP -> 添加新的 MCP 服务器
添加：
Name: docsFetcher
Command: npx -y @smithery/cli@latest run @cdugo/mcp-get-docs --config "{}"📋 Node.js 18 或更高版本
git clone https://github.com/cdugo/package-documentation-mcp
cd package-documentation-mcp
npm install
npm run build安装完成后，您可以使用以下命令在本地运行服务器：
# From the project root directory
npm start对于文件更改时自动重启的开发：
npm run dev服务器将在默认端口（通常为 3000）上启动。您应该看到如下输出：
🚀 DocsFetcher MCP Server running!
📋 Ready to fetch documentation指定自定义端口：
PORT=8080 npm startfetch-url-docs ：🔗 从特定 URL 获取文档
fetch-package-docs ：📦 获取具有可选语言规范的包的文档
fetch-library-docs ：🧠 可与包名称或 URL 配合使用的智能工具
fetch-multilingual-docs ：🌍 获取跨多种语言生态系统的软件包文档
总结库文档：📚 创建全面的库摘要
explain-dependency-error ：🐛 生成依赖错误解释
“什么是 Express.js 以及如何使用它？”
“告诉我有关 React 库的信息”
“如何在 Python 中使用请求？”
“向我展示 JavaScript 中 lodash 的文档”
“比较 Python 中的 pandas 和 R 中的 data.table”
“@fetch-package-docs 的 packageName='express' 和 language='javascript'”
“@fetch-package-docs 的 packageName='requests' 和 language='python'”
“@fetch-multilingual-docs 的 packageName='http' 和 languages=['javascript', 'python', 'rust']”
“@summarize-library-docs with libraryName='express'”
“@explain-dependency-error 软件包名称为‘dotenv’”
服务器未显示：✅ 验证配置中的绝对路径
连接错误：🔄 重新启动 Claude Desktop 或 Cursor IDE
获取失败：⚠️ 某些软件包可能有非标准文档
语言支持：🌐 如果某种语言无法使用，请尝试使用软件包的直接 URL
麻省理工学院
| Name | Required | Description | Default |
|---|---|---|---|
| library | Yes | Name of the package or URL of the library documentation to fetch | |
| language | No | Programming language or repository type if providing a package name (e.g., javascript, python, java, dotnet) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| packageName | Yes | Name of the package to fetch documentation for | |
| languages | Yes | List of programming languages or repository types to check (e.g., javascript, python, java) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| packageName | Yes | Name of the package to fetch documentation for | |
| language | No | Programming language or repository type (e.g., javascript, python, java, dotnet) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the library documentation to fetch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
fetch-library-docsfetch-multilingual-docsfetch-package-docsfetch-url-docsScored across 4 tools
The tools have overlapping purposes as they all fetch documentation, but the different targets (library, multilingual, package, URL) provide some distinction. However, without descriptions, it's unclear if 'library' and 'package' might overlap or if 'multilingual' is a subset of other categories, leading to potential confusion for agents.
All tool names follow a consistent verb_noun pattern with 'fetch-' prefix and hyphen-separated words (e.g., fetch-library-docs). There are no deviations in naming style, making the set predictable and easy to parse.
With 4 tools, the count is reasonable for a documentation fetching server, suggesting a focused scope. It's slightly thin but not inadequate, as each tool appears to target a specific documentation source type.
Inferring the domain as documentation retrieval, the surface lacks obvious operations like search, update, or delete, and there's no tool for general or unspecified docs fetching. The absence of descriptions makes it hard to assess gaps fully, but the limited set suggests significant coverage issues for broader documentation workflows.
@latest documentation and code examples to 9000+ libraries for LLMs and AI code editors in a singl…
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.
Package intelligence for AI agents across npm, PyPI, crates.io and deps.dev. No API keys.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…