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., "@Docs MCP Server Create a quickstart guide for our new CLI and save it to docs/quickstart.md"
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.
A Model Context Protocol server for generating professional, structured documentation using The Good Docs Project templates and authoring guidelines.
The Docs Model Context Protocol server offers tools to improve the developer experience when creating technical documentation with agentic AI tools. Developers no longer need to worry about documentation formatting, missing sections, or inconsistent style. Simply prompt your agent, and the Docs MCP server locates the appropriate template, retrieves official authoring guidelines, and scaffolds or writes the document directly to your project.
Related MCP server: mcp-docs-tools
Scaffolds 25+ industry-standard documentation types developed by The Good Docs Project (API reference, quickstarts, concepts, how-to guides, changelogs, architecture guides, and more)
Provides access to official authoring guides, writing processes, and real-world reference examples
Delivers the comprehensive Good Docs Project Style Guide and writing tips (voice, tone, terminology, and readability standards)
Integrates directly with agentic AI tools (Claude Desktop, VS Code, Cursor, Cline, Claude Code, Antigravity) with zero local setup required via npx
Enables safe writing of generated markdown documentation directly to project files
The template bundle is pre-compiled into the package, keeping the download size under 180 KB with fast startup times.
You do not need to memorize or specify any template names. When you give a prompt such as "Create documentation for this feature" or "Document our Redis caching system":
Codebase Understanding: The AI agent inspects your code to understand what the feature, API, or system does.
Semantic Template Matching: The agent invokes the search_templates tool. The server applies semantic intent scoring across template names, tags, and summaries (for example, mapping "feature" to architecture/concepts, "endpoints" to API references, or "install/setup" to quickstarts and installation guides).
Guideline & Template Retrieval: The agent fetches the matched template and its official Good Docs Project authoring guide.
Drafting & Saving: The agent populates the template with real details from your codebase and writes the completed markdown document directly into your project.
If you do want a specific document type (e.g. "Create a quickstart guide" or "Write an API reference"), the agent will honor your specific choice.
list_templates: Lists all available documentation templates from The Good Docs Project with IDs, names, and summaries.
search_templates: Searches for the best documentation template based on keywords, document type, or task description.
get_template: Retrieves the raw Markdown template, official authoring guide, writing process instructions, and examples for a specific template ID.
get_style_guide: Provides access to The Good Docs Project style guide and technical writing guidelines (voice, tone, terminology, formatting, and readability).
generate_document_skeleton: Generates a tailored document skeleton based on a template, substituting project metadata into the structured template.
save_document: Writes the generated documentation directly to a file on the local filesystem.
Node.js Version v18.0.0, v20.0.0, v22.0.0 or higher
npm Version v8.0.0 or higher
An MCP client, such as VS Code (GitHub Copilot), Claude Desktop, Cursor, Cline, Claude Code, or Antigravity
Users can run the server directly from GitHub without cloning:
{
"mcpServers": {
"docs-mcp-server": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"github:yashisrani/Docs-MCP"
]
}
}
}Clone the repository:
git clone https://github.com/yashisrani/Docs-MCP.git
cd Docs-MCP
npm install
npm run buildConfigure your MCP client:
{
"mcpServers": {
"docs-mcp-server": {
"type": "stdio",
"command": "node",
"args": [
"/path/to/Docs-MCP/dist/index.js"
]
}
}
}code --add-mcp '{"name":"docs-mcp-server","type":"stdio","command":"npx","args":["-y","github:yashisrani/Docs-MCP"]}'Add to claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"docs-mcp-server": {
"command": "npx",
"args": ["-y", "github:yashisrani/Docs-MCP"]
}
}
}Open the Cline panel in VS Code.
Click on the "MCP Servers" icon at the top, next to the plus symbol.
Switch to the "Configure" tab, then click "Configure MCP servers".
Insert the configuration:
{
"mcpServers": {
"docs-mcp-server": {
"command": "npx",
"args": ["-y", "github:yashisrani/Docs-MCP"]
}
}
}claude mcp add --transport stdio --scope user docs-mcp-server -- npx -y github:yashisrani/Docs-MCPcodex mcp add --transport stdio docs-mcp-server -- npx -y github:yashisrani/Docs-MCPIn your MCP settings panel or config file, add:
Name: docs-mcp-server
Transport: stdio
Command: npx
Args: ["-y", "github:yashisrani/Docs-MCP"]
The following rules guide large language models (LLMs) in using the Docs MCP server correctly. Add these rules to your global or project-specific AGENTS.md (or CLAUDE.md for Claude Code):
## Guidelines for Documentation
- When creating or updating documentation, use the `search_templates` or `list_templates` tools from the Docs MCP server to select the matching template from The Good Docs Project.
- Consult `get_style_guide` and `get_template` with `include_guide: true` to align with professional documentation standards (voice, tone, structure, and readability).
- Use `generate_document_skeleton` or `save_document` to produce complete, structured markdown files.Once connected, you can prompt your agent:
Quickstart Guide:
"Using docs-mcp, find the right template and write a quickstart guide for running our Postgres database with Docker Compose."
API Reference:
"Search docs-mcp for API reference templates, inspect the authoring guide, and generate an API reference for our user authentication service."
Feature Overview / Concept Document:
"Using docs-mcp, find the appropriate template for a new feature overview (e.g. Concept template) and write an architecture and feature guide for our Real-Time Collaboration feature."
Contributing Guide:
"Generate a CONTRIBUTING.md file for our open-source TypeScript library following The Good Docs Project standards."
Troubleshooting Guide:
"We have several common connection timeout errors. Pull the troubleshooting guide template from docs-mcp and draft a troubleshooting document."
This project is open to feature requests, suggestions, and bug reports. Contributions and feedback are welcome.
For guidelines on writing and template structure, refer to The Good Docs Project.
Members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone. By participating in this project, you agree to abide by standard community conduct guidelines at all times.
Created and maintained by Yash Israni.
GitHub: @yashisrani
LinkedIn: Yash Israni
X (Twitter): @yashh_twt
The MCP server codebase is created by Yash Israni and licensed under the MIT License.
Documentation templates and authoring guides are developed by and credited to The Good Docs Project.
Generate a tailored document skeleton based on a The Good Docs Project template, substituting project metadata (title, overview, prerequisites, author, etc.) into the structured template.
| Name | Required | Description | Default |
|---|---|---|---|
| template_id | Yes | The template ID to base the doc on (e.g., 'quickstart', 'api-reference', 'readme', 'how-to', 'tutorial') | |
| project_name | Yes | The name of the project or tool | |
| custom_sections | No | Optional list of extra section headers to include | |
| project_description | No | Brief description of the project and target audience |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It hints at what the output contains (metadata substituted into a template structure) but never states the return format (markdown text? JSON?), whether anything is persisted to disk versus returned in-memory, or whether the result must then be passed to save_document. For a generation tool sitting next to save_document, that distinction matters and is left unstated.
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?
A single sentence that front-loads the action and the source template, with no filler. It is efficient, though the parenthetical field list is slightly padded with items that are not parameters.
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 4-parameter tool with full schema coverage and no output schema, the description should at least characterize the returned artifact and its relationship to save_document. It conveys the general shape of the output but not the format or the post-generation step, leaving a real gap for an agent wiring a documentation workflow.
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 baseline is 3. The description adds only marginal meaning: it names metadata concepts ('title, overview, prerequisites, author, etc.') that are not actual parameters, while the real optional inputs (custom_sections, project_description) are not elaborated on, so it neither compensates nor misleads significantly.
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+resource ('Generate a tailored document skeleton') and anchors it to a named source (The Good Docs Project template), which clearly separates it from retrieval siblings like get_template or list_templates. It stops short of explicitly distinguishing itself from get_template or save_document, so a 4 rather than a 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?
The usage is only implied: the agent can infer this is the step after selecting a template_id, but the description never states when to call this instead of get_template or save_document, nor any prerequisites (e.g., must a template be fetched first?). No exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get The Good Docs Project comprehensive style guide and writing tips (voice, tone, terminology, formatting, minimalism, and readability standards).
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional filter: 'style-guide', 'writing-tips', or 'all'. Defaults to 'all'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. The 'get' verb and the static-reference nature of a style guide make the read-only, side-effect-free character fairly evident, and the enumerated topic list gives useful scope information, but nothing is said about the return form (single document vs. sections), size, or whether the topic filter changes the shape of the response.
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 front-loaded sentence that states the resource and then brackets the covered sub-areas. No filler or redundancy, though the parenthetical list is long enough that it slightly dilutes the core statement.
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 single optional-parameter read tool with no output schema and no annotations, the description says what content the guide covers, which is the main thing needed to decide to call it. The only real gap is the absence of any hint about response format or granularity.
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 single 'topic' parameter is fully documented in-schema with its three accepted values and default. The description does not mention the filter at all, so it adds nothing beyond the schema; 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 opens with a specific verb ('Get') and a well-defined resource ('The Good Docs Project comprehensive style guide and writing tips'), then enumerates the content scope (voice, tone, terminology, formatting, minimalism, readability). The resource is unmistakably different from the sibling tools (templates, document generation, saving), so differentiation is implicit rather than stated.
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?
Usage is only implied: an agent can infer this is the reference to consult when writing or reviewing documentation for style. There is no explicit when-to-use, when-not-to-use, or pointer to any alternative source (e.g. list_templates for structure vs. this for prose style).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the raw Markdown template, official authoring guide, writing process instructions, and examples for a specific template ID.
| Name | Required | Description | Default |
|---|---|---|---|
| template_id | Yes | Template ID (e.g., 'quickstart', 'api-reference', 'readme', 'how-to', 'tutorial', 'installation-guide', 'changelog') | |
| include_guide | No | Whether to include the comprehensive TGDP authoring guide explaining best practices for this template. Defaults to true. | |
| include_example | No | Whether to include reference examples if available. Defaults to true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It does well on content composition – listing the four artifacts returned and noting guide/examples are optional bundles – but says nothing about read-only safety, behavior on an unknown template_id, or how the parts are packaged in the response.
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?
A single front-loaded sentence with no filler; the resource comes first and the content list follows. The enumeration is dense but every item corresponds to something actually returned.
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?
A read-only, three-parameter retrieval tool with full schema coverage and no output schema, so the description should mainly tell the agent what comes back. It names the content types but not their structure or format (e.g., whether sections are concatenated, keyed, or include metadata), leaving a real gap for a tool whose entire value is the return payload.
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 baseline is 3. The description's enumeration of guide/process instructions/examples loosely maps to include_guide and include_example, adding slight clarity about what those toggles yield, but the schema already documents defaults and the TGDP guide semantics, so marginal value only.
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?
States a specific verb (get) and resource (template by ID) plus the payload returned: raw Markdown, authoring guide, process instructions, examples. An agent can distinguish it from list_templates/search_templates by the single-ID retrieval, though the description never names those siblings explicitly.
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?
Usage is only implied: the required template_id makes it obvious this is a fetch-after-discovery call, but nothing states when to prefer it over get_style_guide or when to use list_templates/search_templates first to find an ID. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available documentation templates from The Good Docs Project with IDs, names, and summaries.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional category/pack filter (e.g., 'misc', 'core') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden; it does disclose that this is a plain read of all templates and what fields come back. It says nothing about result size, pagination, ordering, or behavior when no templates match, which matters for a full-list operation.
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?
A single well-formed sentence with the action front-loaded and no filler; every clause (source project, returned fields) 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?
For a simple single-parameter read tool with no output schema and no annotations, the description covers what it returns and where the data comes from. The only gap is the unfiltered-listing behavior and the optional category filter.
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?
Only one optional parameter exists and schema coverage is 100%, so the schema already documents the 'category/pack' filter with examples. The description completely omits the filter, adding no meaning beyond the schema — baseline 3.
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?
States a specific verb ('List') and resource ('documentation templates from The Good Docs Project') and names the fields returned (IDs, names, summaries). It implicitly distinguishes itself from search_templates and get_template via the 'all available' scope, but never names those siblings explicitly.
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 phrase 'all available' implies a full enumeration as opposed to a targeted lookup, which weakly routes the agent away from search_templates/get_template, but no explicit when-to-use or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write the generated documentation directly to a file on the local filesystem (e.g. README.md, docs/quickstart.md, CONTRIBUTING.md).
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The complete markdown documentation content to save | |
| file_path | Yes | Relative or absolute destination file path (e.g. 'README.md' or 'docs/api-guide.md') | |
| overwrite | No | Whether to overwrite if the file already exists. Defaults to false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden for a filesystem-writing tool. It discloses the destination domain (local filesystem) but says nothing about side effects: whether parent directories are created, what happens when the file exists without overwrite, whether existing content is lost, or what the call returns on success/failure.
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?
A single sentence with the verb and scope front-loaded and zero filler. Nothing needs trimming and nothing is buried.
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 3-parameter mutation tool with full schema coverage but no annotations and no output schema, the description covers what the tool does but not what it returns or how failures surface. Adequate to invoke, incomplete for predicting behavior.
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%, so all three parameters—including the overwrite default—are already documented in the schema. The description's example paths (README.md, docs/quickstart.md) merely duplicate the file_path schema text rather than adding new semantics.
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?
States a specific verb (Write) plus resource (generated documentation) and destination (a file on the local filesystem), with concrete example targets (README.md, docs/quickstart.md). No sibling in the list writes files—the others are template/style/skeleton readers and generators—so an agent can route here unambiguously.
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 phrase 'the generated documentation' implies this is the step after generating content, but the description never states when to use this versus generate_document_skeleton or when not to call it. Usage is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for the best documentation template based on keywords, document type, or task description (e.g. 'rest api', 'quick onboarding', 'bug tracking', 'installation', 'changelog', 'how to run docker').
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query or description of the document you want to create |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and says nothing about behavior: whether it is read-only (implied but unstated), how results are ranked ("best" suggests ranking but no criteria), how many results come back, or whether an empty result is possible. Only the ranking hint is added value.
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 front-loaded sentence with the action first and the examples trailing in parentheses. The example list is slightly long but each sample illustrates a different query axis, so it mostly earns its space.
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 one-parameter search tool with no output schema, an agent still lacks return-shape and ranking expectations; the description covers intent but not what comes back or how to interpret ordering. Adequate but with clear gaps.
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% for the single required `query` parameter, so the baseline is already 3. The description goes beyond the schema by showing the kinds of strings that work well ('rest api', 'quick onboarding', 'bug tracking'), which genuinely guides query construction.
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?
States a specific verb and resource ("Search for the best documentation template") and enumerates the axes of search (keywords, document type, task description). It is clearly distinguished from get_template/list_templates by the word "Search", though it never names a sibling to route away from.
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 example queries imply when to use it — when you have a fuzzy description of the doc you want — but there is no explicit statement of when to prefer list_templates or get_template instead, nor any prerequisite/order 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.
v1.0.0generate_document_skeletonget_style_guideget_templatelist_templatessave_documentsearch_templatesScored across 6 tools
The tools cover distinct stages of a documentation workflow: listing templates, searching templates, retrieving a specific template, getting a style guide, generating a tailored skeleton, and saving the result. list_templates vs search_templates vs get_template are clearly differentiated by scope and input.
All tool names use consistent snake_case with a leading verb, e.g. list_templates, search_templates, get_template, generate_document_skeleton, save_document. The pattern is predictable and readable throughout.
Six tools is a well-scoped set for a documentation template assistant. Each tool maps to a meaningful step and none appear redundant or unnecessary.
The core workflow is covered: discover templates, search, retrieve content, apply style guidance, generate a skeleton, and save it to disk. Minor gaps exist around editing or updating existing documents, validating generated output, or managing multiple saved documents, but these are not critical for the stated purpose.
Agent document workspace with wallet auth. Create, update and share markdown docs. By AutEng.ai
Markdown workspace for AI agents: read, write, organize, and share markdown documents.
Shared docs for people and their agents: markdown docs with comments, history and search.
Turns agent output into versioned web pages, PDFs, Word docs, spreadsheets and Markdown.
