API キーを必要とせずに、Claude などの LLM の複数の言語エコシステムからパッケージ ドキュメントを取得する MCP サーバー。
🌐 複数のプログラミング言語をサポート (JavaScript、Python、Java、.NET、Ruby、PHP、Rust、Go、Swift)
📦 パッケージのドキュメントを名前または URL で取得します
🔍 ドキュメントサイトをクロールして包括的な情報を抽出します
📄 README、API ドキュメント、コード例、リポジトリ情報を抽出します
🧠 LLM要約のための構造化データを提供する
💬 ドキュメント分析のための特別なプロンプトが含まれています
🔑 APIキーは不要- Claude DesktopとCursor IDEでネイティブに動作します
Related MCP server: Context7 MCP
Claudeデスクトップを開く→設定→開発者
「設定の編集」をクリックして以下を追加します。
{
"mcpServers": {
"docsFetcher": {
"command": "npx",
"args": [
"-y",
"@smithery/cli@latest",
"run",
"@cdugo/mcp-get-docs",
"--config",
"'{}'"
]
}
}
}カーソル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 : 🌍 複数の言語エコシステムにわたるパッケージのドキュメントを取得します
summary-library-docs : 📚 包括的なライブラリ概要を作成する
explain-dependency-error : 🐛 依存関係エラーの説明を生成する
「Express.js とは何ですか？どのように使用しますか？」
「Reactライブラリについて教えてください」
「Python でリクエストを使用するにはどうすればいいですか？」
「JavaScript で lodash のドキュメントを表示」
「Python の pandas と R の data.table を比較する」
"packageName='express'、language='javascript' の @fetch-package-docs"
"packageName='requests'、language='python' の @fetch-package-docs"
"packageName='http'、languages=['javascript'、'python'、'rust'] の @fetch-multilingual-docs"
"@summarize-library-docs で libraryName='express' を指定"
"packageName='dotenv' の @explain-dependency-error"
サーバーが表示されない: ✅ 構成内の絶対パスを確認してください
接続エラー: 🔄 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…