提供文档管理功能的开源MCP实现。中文文档
从各种来源抓取并索引文档
支持多种文档格式
全文搜索功能
基于资源的文档访问
基于工具的文档管理
enable_doc - 启用特定文档的抓取
disable_doc - 禁用对特定文档的抓取
crawl_docs - 开始抓取已启用的文档
build_index - 为文档构建搜索索引
search_docs - 搜索文档
list_enabled_docs - 列出已启用的文档
list_all_docs - 列出所有可用的文档
该项目旨在通过提供以下内容来复制 Cursor 的 @Docs 功能：
文档索引：
从各种来源抓取并索引文档
支持多种文档格式（HTML、Markdown 等）
自动重新索引以使文档保持最新
文档访问：
在所有索引文档中搜索
与 MCP 协议集成以实现 AI 上下文
自定义文档管理：
通过enable_doc工具添加新的文档源
通过list_enabled_docs工具管理已启用的文档
使用crawl_docs工具强制重新抓取
┌───────────────────────────────────────────────────────┐
│ open-docs-mcp Server │
├───────────────────┬───────────────────┬───────────────┤
│ Crawler Module │ Search Engine │ MCP Server │
├───────────────────┼───────────────────┼───────────────┤
│ - Web crawling │ - Full-text index │ - Resources │
│ - Doc conversion │ - Relevance score │ - Tools │
│ - Storage │ - Query parsing │ - Prompts │
└───────────────────┴───────────────────┴───────────────┘Related MCP server: @sanderkooger/mcp-server-ragdocs
npx -y open-docs-mcp --docsDir ./docs要通过Smithery自动安装 Claude Desktop 的文档管理服务器：
npx -y @smithery/cli install @askme765cs/open-docs-mcp --client claude要与 Claude Desktop 一起使用，请添加服务器配置：
在 MacOS 上： ~/Library/Application Support/Claude/claude_desktop_config.json在 Windows 上： %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"open-docs-mcp": {
"command": "npx",
"args": [
"-y",
"open-docs-mcp",
"--docsDir",
"/path/to/docs"
]
}
}
}配置选项：
command ：Node.js 可执行文件
args ：传递给脚本的参数数组
--docsDir ：必需，指定文档目录路径
disabled ：设置为 true 以暂时禁用服务器
alwaysAllow ：无需确认即可使用的工具名称数组
npm run watch # Auto-rebuild on changes
npm run inspector # Debug with MCP Inspector欢迎提交 Pull 请求。对于重大变更，请先提交一个 issue 来讨论您想要修改的内容。
Build search index for docs
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Whether to force rebuild index |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits (e.g., destructive potential, permission requirements, effect on existing index). The verb 'build' implies non-destructive creation, but this is insufficient.
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 very short (5 words) but lacks any structure or additional context. While concise, it sacrifices completeness for brevity.
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 no annotations, no output schema, and a single optional parameter, the description is too minimal. It fails to explain what happens when the index is built, error conditions, or return values.
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 description adds no meaning beyond the input schema, which already describes 'force' as a boolean to force rebuild. Since schema coverage is 100%, a baseline of 3 applies.
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 'Build search index for docs', specifying the action and resource. It distinguishes from sibling tools like crawl_docs or search_docs, but lacks nuance like scope of index.
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?
No guidance on when to use this tool versus alternatives such as crawl_docs or search_docs. An agent cannot infer prerequisites or context from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start crawling enabled docs
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Whether to force re-crawl all docs, ignoring previous crawl records |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It simply says 'start crawling' without disclosing behavioral traits such as whether it is destructive, how long it takes, or if it modifies data beyond crawl records.
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 sentence with no wasted words, front-loading the action. It is appropriately sized but could include more detail without becoming verbose.
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?
For a tool with one parameter and no output schema, the description is incomplete. It does not explain the crawling process, side effects, return values, or prerequisites like whether docs must be enabled first.
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?
Schema description coverage is 100% for the single parameter 'force'. The description adds no additional meaning beyond the schema's description of the force parameter. Baseline 3 is appropriate.
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 'Start crawling enabled docs' clearly states the verb (Start crawling) and resource (enabled docs), specifying the scope. However, it does not differentiate from sibling tools like search_docs or list_enabled_docs, which could be confused.
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?
No guidance is provided on when to use this tool versus alternatives like build_index or search_docs. There are no exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disable crawling for a specific doc
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the doc to disable |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits (e.g., reversibility, permission needs, impact on ongoing crawls). It only states the action without additional context.
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 sentence that is concise and front-loaded. It contains no unnecessary words, though it is brief.
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?
For a simple one-parameter tool with no output schema, the description conveys the basic purpose. However, it lacks completeness regarding effects and usage context, which is expected given the sibling tools.
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?
Schema coverage is 100% with a parameter description. The tool description adds no extra meaning beyond that; baseline of 3 is appropriate as it neither harms nor significantly helps.
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 action ('disable') and the resource ('crawling for a specific doc'), distinguishing it from siblings like 'enable_doc' and 'crawl_docs'.
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?
No guidance on when to use this tool versus alternatives (e.g., enable_doc, crawl_docs). The description implies usage context but does not provide explicit when/when-not criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable crawling for a specific doc
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the doc to enable |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It only says 'enable crawling' without disclosing whether action is reversible, triggers immediate crawling, or requires special permissions. Minimal behavioral insight.
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?
One sentence, no unnecessary words, but it lacks substance. Conciseness is adequate but the description is too minimal to be fully helpful.
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?
For a simple 1-param tool with no output schema, the description is barely adequate. Does not explain the effect on the doc or relationship to siblings like 'disable_doc' or 'list_enabled_docs'.
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?
Schema coverage is 100% with a clear description for the only parameter 'name'. The tool description adds no extra meaning beyond the schema; baseline 3 is appropriate as schema does the work.
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 'Enable crawling for a specific doc' clearly states the action (enable) and resource (doc for crawling). It distinguishes from sibling 'disable_doc' by targeting enablement, but does not explain what 'crawling' entails in this context.
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?
No guidance on when to use this tool versus alternatives like 'crawl_docs' or 'disable_doc'. Missing prerequisites or conditions (e.g., doc must exist, must be disabled first). Usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available docs including disabled ones
| Name | Required | Description | Default |
|---|---|---|---|
| verbose | No | Whether to show detailed information |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It indicates a read-only listing operation, but does not explicitly state safety, side effects, or permissions. The word 'list' implies non-destructive, but transparency is adequate but not detailed.
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 concise sentence that front-loads the essential information: the action, scope, and key differentiator. No extraneous words.
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?
For a simple listing tool with one parameter and no output schema, the description is complete. It covers the purpose and the critical distinction of including disabled docs, which is sufficient for an agent to use correctly.
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 input schema fully describes the 'verbose' parameter with 100% coverage. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
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 verb 'list' and the resource 'all available docs', and includes the key differentiator 'including disabled ones', distinguishing it from sibling tools like list_enabled_docs.
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 implies when to use this tool (to see all docs including disabled) versus alternatives, but does not explicitly state when not to use it or name the sibling. The context is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all enabled docs with their cache status
| Name | Required | Description | Default |
|---|---|---|---|
| verbose | No | Whether to show detailed information |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like read-only nature; it only states the function without additional context.
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 very concise and front-loaded, though it is a brief phrase rather than a full sentence; it is appropriately sized for the tool's simplicity.
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 simple tool (1 parameter, no output schema, no annotations), the description is adequate but lacks explicit contrast with sibling tools and behavioral details.
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?
Schema coverage is 100% and the 'verbose' parameter is well-described in the schema; the description adds no extra meaning beyond what the schema provides.
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 specifies the verb 'List' and the resource 'enabled docs' and includes 'with their cache status', distinguishing it from sibling 'list_all_docs'.
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 implies usage for fetching only enabled docs, but does not explicitly state when to use versus alternatives like 'list_all_docs'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search documentation
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query | |
| max_results | No | Maximum number of results | |
| doc_name | No | Filter by document category | |
| offset | No | Number of results to skip |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. The phrase 'Search documentation' gives no indication of whether this is a read-only operation, what resources are accessed, or potential side effects. It is essentially a tautology of the tool name, so the score is 2 (tautology).
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 extremely concise (only two words), with no wasted text. It is front-loaded and efficient, but the brevity sacrifices meaningful content. A score of 4 reflects that it is concise without being verbose, though it could be improved with more substance.
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 tool has 4 parameters, no annotations, and no output schema, the description is severely inadequate. It does not explain return values, pagination via offset, result limits via max_results, filtering via doc_name, or any behavioral aspects. This is completely inadequate for the agent to use the tool effectively, hence a score of 1.
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 input schema has 100% description coverage for all 4 parameters, so the baseline is 3. The description adds no additional parameter context beyond what is in the schema, so it does not exceed the baseline.
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 'Search documentation' clearly states the verb and resource, making the basic purpose understandable. However, it does not differentiate from sibling tools like 'list_all_docs' or 'build_index', and it lacks specificity about the kind of search (e.g., full-text, fuzzy). It is not misleading but is minimal.
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?
No guidance is provided on when to use this tool versus alternatives. The agent receives no context about whether to prefer 'search_docs' over 'list_all_docs' or 'crawl_docs'. This omission leaves the agent with no decision support, resulting in a score of 2 (no guidance).
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.
build_indexcrawl_docsdisable_docenable_doclist_all_docslist_enabled_docssearch_docsScored across 7 tools
Each tool targets a distinct action: building index, crawling, enabling/disabling docs, listing with different filters, and searching. No overlap in purpose.
Most tools follow verb_noun pattern (crawl_docs, disable_doc, etc.), but there is a minor inconsistency: 'disable_doc' and 'enable_doc' use singular 'doc' while others use plural 'docs'. Overall pattern is clear.
Seven tools is well-scoped for a documentation search server. Each tool serves a necessary function without bloat or deficiency.
The set covers core lifecycle: enabling/disabling docs, listing, crawling, indexing, and searching. Missing a manual add or delete doc tool, but these may be implicit in the crawling workflow.
MCP server for developer documentation, generated by doc2mcp.
MCP server for agentverse documentation, generated by doc2mcp.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
MCP server for developers documentation, generated by doc2mcp.
