The Documentation MCP Server gives AI assistants structured access to documentation across Markdown and OpenAPI files, with both an MCP endpoint for AI clients and a web interface for browsing.
Full-text search (search_documentation): Search with relevance scoring, optional category filtering, configurable result limits, and hierarchical breadcrumb context.
Navigate documentation (navigate_to): Navigate to a specific URI (e.g., docs://guides/security) and retrieve parent, children, and breadcrumb context.
Table of contents (get_table_of_contents): Retrieve the complete documentation hierarchy as a tree, with an optional max depth parameter.
Retrieve a document (get_document): Fetch the full content and metadata for any document by its URI.
Tag-based search (search_by_tags): Find documents by metadata tags (OR logic) with optional category filtering and result limits.
List all tags (get_all_tags): Get all unique tags across documentation, with optional category filtering and document counts per tag.
Generate PDF : Export all documentation as a PDF (requires optional PDF dependency).
Enables AI assistants to navigate and search documentation organized in markdown files, supporting hierarchical structures and YAML frontmatter for metadata extraction.
Provides support for parsing and querying documentation written in the MDX format, allowing assistants to access structured content and associated metadata.
Supports the loading and querying of OpenAPI 3.x specifications in YAML format and enables the extraction of document metadata from YAML frontmatter.
Click on "Deploy 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., "@Documentation MCP Server search for the getting started guide and summarize the setup steps"
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 MCP server that gives AI assistants structured access to your documentation. Supports markdown with YAML frontmatter, OpenAPI specs, full-text search, a web interface, and PDF generation.
Install from PyPI:
pip install your-docs-mcpWith semantic search (recommended):
pip install "your-docs-mcp[vector]" --extra-index-url https://download.pytorch.org/whl/cpuWith PDF generation:
pip install "your-docs-mcp[pdf]"All features:
pip install "your-docs-mcp[vector,pdf]" --extra-index-url https://download.pytorch.org/whl/cpuPDF generation requires system packages:
macOS: brew install pandoc basictex
Ubuntu/Debian: sudo apt install pandoc texlive-xetex texlive-latex-extra
Related MCP server: Dedalus MCP Documentation Server
export DOCS_ROOT=/path/to/your/docs
your-docs-serverOpen http://localhost:8123 to browse your docs. The MCP server is also running for AI clients.
Claude Desktop - edit ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"docs": {
"command": "your-docs-mcp",
"env": {
"DOCS_ROOT": "/absolute/path/to/your/docs"
}
}
}
}VS Code - create .vscode/mcp.json:
{
"servers": {
"docs": {
"command": "your-docs-mcp",
"env": {
"DOCS_ROOT": "${workspaceFolder}/docs"
}
}
}
}Tool | Description |
| Full-text search with relevance scoring |
| Navigate to a doc by URI (e.g. |
| Get the full documentation hierarchy |
| Retrieve a document and its metadata |
| Filter docs by tags |
| List all tags across documentation |
| Generate a PDF of all documentation |
Markdown with YAML frontmatter:
---
title: Getting Started
tags: [guide, quickstart]
order: 1
---
# Getting Started
Your content here...OpenAPI 3.x (.yaml or .json) is also supported.
Key environment variables:
DOCS_ROOT=/path/to/docs # Required: documentation root directory
MCP_DOCS_CACHE_TTL=3600 # Cache TTL in seconds
MCP_DOCS_SEARCH_LIMIT=10 # Max search results
MCP_DOCS_WEB_PORT=8123 # Web server port
LOG_LEVEL=INFO # DEBUG, INFO, WARNING, ERRORyour-docs-server # MCP server + web interface
your-docs-mcp # MCP server only
your-docs-web # Web interface onlygit clone https://github.com/esola-thomas/your-docs-mcp
cd your-docs-mcp
pip install -e ".[dev,vector,pdf]" --extra-index-url https://download.pytorch.org/whl/cpu
pytest
ruff check .See the contributing guide for details on running tests, code style, and submitting pull requests. Open an issue to report bugs or request features.
MIT - see LICENSE for details.
Get a list of all unique tags defined across the documentation. Optionally filter by category and include document counts per tag.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional category to filter tags from | |
| include_counts | No | Include document count for each tag (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only describes the operation without disclosing side effects, permissions, or safety (e.g., read-only nature).
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, well-structured sentence that immediately conveys the core function and key options with no wasted 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 tool with 2 optional params and no output schema, the description adequately covers the operation but could benefit from mentioning the output format (e.g., list of tag objects).
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%, and the description merely restates the parameter purposes ('filter by category', 'include document counts') without adding meaningful insight beyond the schema.
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 'Get', the resource 'list of all unique tags', and the scope 'across the documentation', distinguishing it from siblings like search_by_tags or get_document.
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 listing all tags with optional filters, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives like search_by_tags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full content and metadata for a specific document by URI.
| Name | Required | Description | Default |
|---|---|---|---|
| uri | Yes | Document URI (e.g., 'docs://guides/getting-started') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Get full content and metadata' without disclosing behavioral traits like authentication, rate limits, or error handling. The return format is not described, and no output schema exists.
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 effectively communicates the tool's purpose without unnecessary 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?
The tool is simple with one parameter, and the description covers the basic purpose. However, the lack of output schema and behavioral details leaves some gaps for an agent, but given low complexity, it is minimally adequate.
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 the parameter 'uri' already described in the input schema. The description adds no new meaning beyond the schema's example and purpose.
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 uses a specific verb 'Get' and resource 'full content and metadata for a specific document by URI', clearly distinguishing it from sibling tools like search_by_tags and navigate_to.
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 retrieving a document by URI but does not explicitly state when to use this tool over alternatives, such as search tools for finding documents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the complete documentation hierarchy as a table of contents tree.
| Name | Required | Description | Default |
|---|---|---|---|
| max_depth | No | Maximum depth to include (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavior. It states it returns a 'tree' but omits details like the effect of the max_depth parameter, whether the operation is read-only, or the structure of the output. The description does not contradict annotations (none provided).
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 effectively communicates the tool's purpose. It is front-loaded and contains no unnecessary 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?
Despite low complexity (one optional parameter, no output schema), the description fails to mention the parameter or explain the tree structure. It is incomplete as it does not address how max_depth modifies the behavior or what the returned tree contains.
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 one parameter described. The description says 'complete' hierarchy but the max_depth parameter restricts depth, creating a slight inconsistency. The description adds no additional meaning beyond the schema's parameter 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?
The description clearly states 'Get the complete documentation hierarchy as a table of contents tree,' specifying the verb and resource. It distinguishes from sibling tools like get_document (single document retrieval) and search_by_tags (tag-based search) by focusing on the entire hierarchy.
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 provides no guidance on when to use this tool versus alternatives, nor does it mention context or exclusions. For example, it does not suggest using get_document for a specific page or search_documentation for queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search documentation by metadata tags and category.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | Yes | Tags to search for (OR logic) | |
| category | No | Category to filter by | |
| limit | No | Maximum results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state if the operation is read-only, if authentication is required, or what side effects (e.g., logging) occur. The behavior beyond the basic search action is opaque.
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 extraneous information. It is appropriately sized for a straightforward search tool, capturing the core functionality efficiently.
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 lack of annotations, output schema, and complex sibling tools, the description is insufficient. It does not explain return format, pagination, error handling, or how it integrates with tools like get_document. A more complete description would include what the results look like and any limitations.
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%, so the description adds no additional meaning beyond what is already in the input schema. It mentions 'tags' and 'category' but does not clarify the search logic (e.g., OR logic implied by tags description) or the default for limit. 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 clearly states the tool searches documentation by tags and category. It distinguishes itself from sibling tools like get_all_tags (retrieves tags) and search_documentation (likely full-text search), making the purpose specific. However, it could explicitly state that it returns documents or results, so not a perfect 5.
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 usage guidelines are provided. The description does not specify when to use this tool over alternatives like search_documentation or get_document. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage implicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search documentation with full-text search. Returns results with hierarchical context (breadcrumbs).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query string | |
| category | No | Optional category to filter results | |
| limit | No | Maximum number of results (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions returning results with breadcrumbs. It fails to disclose read-only nature, potential side effects, authentication needs, rate limits, or pagination behavior, leaving significant gaps for an agent.
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?
Two sentences, no redundant information, front-loaded with the core action. Every word earns its place.
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?
Adequately describes the tool's purpose and result format but lacks details on return structure, error handling, or usage context. Given no output schema, more explanation of the 'hierarchical context' would improve completeness.
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?
Input schema covers all 3 parameters with descriptions (query, category, limit), achieving 100% coverage. The description adds no further semantics beyond the schema, so baseline 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 it performs full-text search on documentation and returns results with hierarchical context, which distinguishes it from sibling tools like search_by_tags (tag-based search) and get_all_tags (listing tags).
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 explicit guidance on when to use this tool versus alternatives like search_by_tags; lacks when-not-to-use or prerequisite conditions. The description implies general full-text search but does not clarify specific usage scenarios.
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.
v1.0.1generate_pdf_releasev1.0.0generate_pdf_releaseget_all_tagsget_documentget_table_of_contentsnavigate_tosearch_by_tagssearch_documentationScored across 6 tools
Most tools are clearly distinct: search_documentation is full-text, search_by_tags is metadata-based, get_document retrieves content, and navigation tools handle hierarchy. There is slight overlap between search_documentation and search_by_tags, but the descriptions clarify the different search modes.
Tool names consistently use verb_noun pattern (search_documentation, navigate_to, get_table_of_contents, get_document, get_all_tags). search_by_tags follows the pattern, though 'navigate_to' is slightly less descriptive than the others but still consistent in style.
Six tools is well-scoped for a documentation server, covering search, navigation, and metadata retrieval without unnecessary redundancy. Each tool serves a distinct purpose in the documentation workflow.
The surface covers core documentation needs: full-text search, tag search, navigation, TOC, and document retrieval. Minor gaps include no obvious way to get related documents or search within a specific subtree, but the core workflows are complete.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Governed, auditable knowledge your team curates for its AI assistants, self-hostable
Ingest, manage, and retrieve documents for RAG-powered AI applications
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
