The open-docs-mcp server is an open-source MCP implementation for document management that allows you to:
Crawl and index documentation from various sources in multiple formats
Enable/disable crawling for specific documentation sources
Force re-crawl enabled documents
Search documentation with filters and pagination
Build or rebuild search index
List all available documents including disabled ones
List enabled documents with their cache status
Integrate with MCP protocol for AI context and resource-based document access
These features essentially replicate Cursor's @Docs functionality through the MCP API.
Supports indexing and searching of Markdown-formatted documentation, enabling access to content in this format through the document management system.
Runs as a Node.js application, with specific version requirements (>=16.0.0) to enable the document management functionality.
Built with TypeScript 4.9.5, providing type safety and modern language features for the document management implementation.
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., "@open-docs-mcp search for React hooks documentation"
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 open-source MCP implementation providing document management functionality. 中文文档
Crawl and index documentation from various sources
Support for multiple document formats
Full-text search capabilities
Resource-based access to documents
Tool-based document management
enable_doc - Enable crawling for a specific doc
disable_doc - Disable crawling for a specific doc
crawl_docs - Start crawling enabled docs
build_index - Build search index for docs
search_docs - Search documentation
list_enabled_docs - List enabled docs
list_all_docs - List all available docs
This project aims to replicate Cursor's @Docs functionality by providing:
Document Indexing:
Crawl and index documentation from various sources
Support for multiple document formats (HTML, Markdown, etc.)
Automatic re-indexing to keep docs up-to-date
Document Access:
Search across all indexed documentation
Integration with MCP protocol for AI context
Custom Docs Management:
Add new documentation sources via enable_doc tool
Manage enabled docs via list_enabled_docs tool
Force re-crawl with crawl_docs tool
┌───────────────────────────────────────────────────────┐
│ 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 ./docsTo install Document Management Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @askme765cs/open-docs-mcp --client claudeTo use with Claude Desktop, add the server config:
On MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"open-docs-mcp": {
"command": "npx",
"args": [
"-y",
"open-docs-mcp",
"--docsDir",
"/path/to/docs"
]
}
}
}Configuration Options:
command: Node.js executable
args: Array of arguments to pass to the script
--docsDir: Required, specifies docs directory path
disabled: Set to true to temporarily disable the server
alwaysAllow: Array of tool names that can be used without confirmation
npm run watch # Auto-rebuild on changes
npm run inspector # Debug with MCP InspectorPull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.
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. Dates show when Glama detected each change.
build_indexcrawl_docsdisable_docenable_doclist_all_docslist_enabled_docssearch_docsEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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 dev documentation, generated by doc2mcp.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/askme765cs/open-docs-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
