Un servidor MCP que obtiene documentación de paquetes de múltiples ecosistemas de idiomas para LLM como Claude sin necesidad de claves API.
🌐 Admite múltiples lenguajes de programación (JavaScript, Python, Java, .NET, Ruby, PHP, Rust, Go, Swift)
📦 Obtiene documentación de los paquetes por nombre o URL
🔍 Rastrea sitios de documentación para extraer información completa
📄 Extrae README, documentos de API, ejemplos de código e información del repositorio
🧠 Proporciona datos estructurados para el resumen de LLM
💬 Incluye indicaciones especializadas para el análisis de la documentación
🔑 No se requiere clave API : funciona de forma nativa con Claude Desktop y Cursor IDE
Related MCP server: Context7 MCP
Abra Claude Desktop → Configuración → Desarrollador
Haga clic en "Editar configuración" y agregue:
{
"mcpServers": {
"docsFetcher": {
"command": "npx",
"args": [
"-y",
"@smithery/cli@latest",
"run",
"@cdugo/mcp-get-docs",
"--config",
"'{}'"
]
}
}
}Abra Cursor IDE → Configuración → MCP -> Agregar nuevo servidor MCP
Agregar:
Name: docsFetcher
Command: npx -y @smithery/cli@latest run @cdugo/mcp-get-docs --config "{}"📋 Node.js 18 o posterior
git clone https://github.com/cdugo/package-documentation-mcp
cd package-documentation-mcp
npm install
npm run buildUna vez instalado, puedes ejecutar el servidor localmente con:
# From the project root directory
npm startPara el desarrollo con reinicio automático al cambiar archivos:
npm run devEl servidor se iniciará en el puerto predeterminado (normalmente el 3000). Debería ver un resultado como este:
🚀 DocsFetcher MCP Server running!
📋 Ready to fetch documentationPara especificar un puerto personalizado:
PORT=8080 npm startfetch-url-docs : 🔗 Obtener documentos de una URL específica
fetch-package-docs : 📦 Obtiene la documentación de un paquete con especificación de idioma opcional
fetch-library-docs : 🧠 Herramienta inteligente que funciona con el nombre del paquete o la URL
fetch-multilingual-docs : 🌍 Obtener documentación para un paquete en varios ecosistemas de idiomas
summary-library-docs : 📚 Crea un resumen completo de la biblioteca
explain-dependency-error : 🐛 Generar explicaciones de errores de dependencia
¿Qué es Express.js y cómo lo uso?
"Cuéntame sobre la biblioteca React"
"¿Cómo uso solicitudes en Python?"
Muéstrame la documentación de lodash en JavaScript.
Comparación de pandas en Python y data.table en R.
"@fetch-package-docs con nombre_paquete='express' e idioma='javascript'"
"@fetch-package-docs con nombre_paquete='requests' y lenguaje='python'"
"@fetch-multilingual-docs con nombre_paquete='http' e idiomas=['javascript', 'python', 'rust']"
"@summarize-library-docs con nombreDeLibraria='express'"
"@explain-dependency-error con nombre_del_paquete='dotenv'"
El servidor no aparece : ✅ Verifique la ruta absoluta en la configuración
Errores de conexión : 🔄 Reinicie Claude Desktop o Cursor IDE
Errores de obtención : ⚠️ Algunos paquetes pueden tener documentación no estándar
Compatibilidad de idiomas : 🌐 Si un idioma no funciona, intenta usar la URL directa del paquete
Instituto Tecnológico de Massachusetts (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.
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…