The DocsFetcher MCP Server fetches and processes package documentation from multiple language ecosystems for LLMs without requiring API keys.
🌐 Multi-language Support: Fetches documentation for JavaScript, Python, Java, .NET, Ruby, PHP, Rust, Go, and Swift packages.
🔧 Fetching Tools:
fetch-url-docs: Fetches documentation from a specific URL
fetch-package-docs: Fetches docs for a package with optional language specification
fetch-library-docs: Smart tool accepting either package name or URL
fetch-multilingual-docs: Fetches docs across multiple language ecosystems
📚 Data Extraction: Provides README, API docs, code examples, and repository info
🧠 LLM Integration: Offers structured data for summarization with specialized analysis prompts
🔑 No API Keys: Works natively with Claude Desktop and Cursor IDE
Can retrieve specific documentation for the Express.js framework, as explicitly mentioned in the example queries.
Fetches comprehensive documentation for JavaScript packages, including READMEs, API docs, and code examples to provide structured data for LLM summarization.
Can retrieve documentation for the Lodash JavaScript utility library, as mentioned in the example queries.
Crawls and extracts documentation for .NET packages, providing structured information about .NET libraries.
Can fetch documentation for the pandas data analysis library in Python, as specifically referenced in the example queries.
Retrieves documentation for PHP packages, extracting comprehensive information to help understand PHP library functionality.
Retrieves documentation for Python packages, extracting READMEs, API references, and usage examples to facilitate better understanding of Python libraries.
Can fetch detailed documentation for the React library, as specifically referenced in the example queries.
Fetches documentation for Ruby gems, providing structured information about Ruby packages for easier consumption by LLMs.
Extracts documentation for Rust packages, crawling documentation sites to provide comprehensive information about Rust libraries.
Fetches documentation for Swift packages, extracting detailed information to assist with Swift library understanding.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@DocsFetcher MCP Server fetch documentation for the pandas Python library"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that fetches package documentation from multiple language ecosystems for LLMs like Claude without requiring API keys.
🌐 Supports multiple programming languages (JavaScript, Python, Java, .NET, Ruby, PHP, Rust, Go, Swift)
📦 Fetches documentation for packages by name or URL
🔍 Crawls documentation sites to extract comprehensive information
📄 Extracts README, API docs, code examples, and repository info
🧠 Provides structured data for LLM summarization
💬 Includes specialized prompts for documentation analysis
🔑 No API key required - works natively with Claude Desktop and Cursor IDE
Related MCP server: Context7 MCP
Open Claude Desktop → Settings → Developer
Click "Edit Config" and add:
{
"mcpServers": {
"docsFetcher": {
"command": "npx",
"args": [
"-y",
"@smithery/cli@latest",
"run",
"@cdugo/mcp-get-docs",
"--config",
"'{}'"
]
}
}
}Open Cursor IDE → Settings → MCP -> Add New MCP Servier
Add:
Name: docsFetcher
Command: npx -y @smithery/cli@latest run @cdugo/mcp-get-docs --config "{}"📋 Node.js 18 or later
git clone https://github.com/cdugo/package-documentation-mcp
cd package-documentation-mcp
npm install
npm run buildOnce installed, you can run the server locally with:
# From the project root directory
npm startFor development with auto-restart on file changes:
npm run devThe server will start on the default port (usually 3000). You should see output like:
🚀 DocsFetcher MCP Server running!
📋 Ready to fetch documentationTo specify a custom port:
PORT=8080 npm startfetch-url-docs: 🔗 Fetch docs from a specific URL
fetch-package-docs: 📦 Fetch docs for a package with optional language specification
fetch-library-docs: 🧠 Smart tool that works with either package name or URL
fetch-multilingual-docs: 🌍 Fetch docs for a package across multiple language ecosystems
summarize-library-docs: 📚 Create a comprehensive library summary
explain-dependency-error: 🐛 Generate dependency error explanations
"What is Express.js and how do I use it?"
"Tell me about the React library"
"How do I use requests in Python?"
"Show me documentation for lodash in JavaScript"
"Compare pandas in Python and data.table in R"
"@fetch-package-docs with packageName='express' and language='javascript'"
"@fetch-package-docs with packageName='requests' and language='python'"
"@fetch-multilingual-docs with packageName='http' and languages=['javascript', 'python', 'rust']"
"@summarize-library-docs with libraryName='express'"
"@explain-dependency-error with packageName='dotenv'"
Server not showing up: ✅ Verify absolute path in configuration
Connection errors: 🔄 Restart Claude Desktop or Cursor IDE
Fetch failures: ⚠️ Some packages may have non-standard documentation
Language support: 🌐 If a language isn't working, try using the package's direct URL
MIT
| 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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
@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.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cdugo/package-documentation-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
