문서 관리 기능을 제공하는 오픈 소스 MCP 구현입니다.
다양한 소스에서 크롤링 및 인덱싱 문서
다양한 문서 형식 지원
전체 텍스트 검색 기능
문서에 대한 리소스 기반 액세스
도구 기반 문서 관리
enable_doc - 특정 문서에 대한 크롤링을 활성화합니다.
disable_doc - 특정 문서에 대한 크롤링을 비활성화합니다.
crawl_docs - 활성화된 문서 크롤링 시작
build_index - 문서 검색 인덱스 빌드
search_docs - 문서 검색
list_enabled_docs - 활성화된 문서 목록
list_all_docs - 사용 가능한 모든 문서 나열
이 프로젝트는 다음을 제공하여 Cursor의 @Docs 기능을 복제하는 것을 목표로 합니다.
문서 인덱싱 :
다양한 소스에서 크롤링 및 인덱싱 문서
다양한 문서 형식 지원(HTML, Markdown 등)
문서를 최신 상태로 유지하기 위한 자동 재색인화
문서 접근 :
색인된 모든 문서 검색
AI 컨텍스트를 위한 MCP 프로토콜과의 통합
사용자 정의 문서 관리 :
enable_doc 도구를 통해 새로운 문서 소스를 추가합니다.
list_enabled_docs 도구를 통해 활성화된 문서 관리
crawl_docs 도구를 사용하여 강제로 다시 크롤링
지엑스피1
Related MCP server: @sanderkooger/mcp-server-ragdocs
npx -y open-docs-mcp --docsDir ./docsSmithery를 통해 Claude Desktop용 문서 관리 서버를 자동으로 설치하려면:
npx -y @smithery/cli install @askme765cs/open-docs-mcp --client claudeClaude 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 : 필수, docs 디렉토리 경로를 지정합니다.
disabled : 서버를 일시적으로 비활성화하려면 true로 설정합니다.
alwaysAllow : 확인 없이 사용할 수 있는 도구 이름 배열
npm run watch # Auto-rebuild on changes
npm run inspector # Debug with MCP Inspector풀 리퀘스트는 환영합니다. 중요한 변경 사항이 있는 경우, 먼저 이슈를 열어 변경 사항을 논의해 주세요.
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.
