What can you do with this server?

This MCP server generates and maintains grounded, enterprise-grade documentation for any codebase by analyzing real project artifacts (source tree, git history, package manifests, env files, existing docs) and never fabricating facts — every claim traces back to something the server's own analyzers actually found, or is explicitly labeled an assumption. * Analyze a project (analyze_project): Scans the source tree, git history, package manifests, env files, and existing docs to return a grounded analysis including summary, architecture, technologies, complexity, documentation coverage, risk findings, and recommendations. * Generate environment variable docs (generate_env_docs): Documents every environment variable a project declares or reads, without ever revealing secret values (only redacted placeholders). * Generate changelog (generate_changelog): Creates a Markdown changelog from real git history, grouped by conventional-commit types (Breaking Changes/Features/Fixes/Other), optionally scoped between tags. * Generate README (generate_readme): Produces a professional README.md with grounded narrative sections and deterministic installation/configuration/contributing/license from real project facts. * Review documentation (review_documentation): Scores existing docs on coverage/quality/consistency (0-100 each) and lists missing sections and recommendations. * Generate architecture docs (generate_architecture): Creates Architecture.md including layers, modules, dependency graph (Mermaid), design patterns, tech stack, and ADRs, all grounded in real source structure and imports. * Generate database docs (generate_database_docs): Reads a real Prisma or SQL schema to document tables, columns, relations, indexes, ER diagram, and business rules. * Generate API docs (generate_api_docs): Documents endpoints from a real OpenAPI/Swagger spec or falls back to regex-extracted routes from source (Express/Fastify/NestJS). * Generate sequence diagrams (generate_sequence_diagram): Renders Mermaid + PlantUML sequence diagrams from caller-supplied steps or a static symbol trace. * Generate flow diagrams (generate_flow_diagram): Builds user/application/request/auth/deployment/data flow diagrams grounded in real evidence (layer directories, dependencies). * Generate release notes (generate_release_notes): Groups real commits between tags by conventional-commit type, optionally including merged GitHub PRs. * Generate deployment docs (generate_deployment_docs): Reads real Docker/docker-compose/Kubernetes/Terraform files for scaling and rollback guidance. * Generate security docs (generate_security_docs): Reports real auth/RBAC/encryption/secrets evidence and includes an honest OWASP Top 10 checklist. * Generate testing docs (generate_testing_docs): Reports the real detected test framework, test file counts, and coverage-config presence. * Generate Product Requirements Doc (PRD) (generate_prd): Creates a grounded PRD (the only LLM-heavy tool) with assumptions explicitly flagged. * Generate Technical Requirements Doc (TRD) (generate_trd): Composes a technical requirements document from the real output of other structural tools. * Generate contribution guide (generate_contribution_guide): Renders real install/test/lint/build commands from the project’s package manifest. * Synchronize docs (synchronize_docs): Regenerates only docs whose real content actually changed, via content hashing, never overwriting hand-edited files. * Works with any MCP client: Integrates with Claude Code, Claude Desktop, Cursor, Windsurf, VS Code, Cline, Continue.dev, Zed, Gemini CLI, JetBrains AI, and others.

Which integrations are available for this server?

Enables release notes to include real merged GitHub pull requests when a GITHUB_TOKEN is configured, returning an empty list rather than fabricating PR data.

How do I use docs-assistant-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@docs-assistant-mcp Analyze my codebase and generate a README" 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.

docs-assistant-mcp

by HARDIK-31

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

This MCP server generates and maintains grounded, enterprise-grade documentation for any codebase by analyzing real project artifacts (source tree, git history, package manifests, env files, existing docs) and never fabricating facts — every claim traces back to something the server's own analyzers actually found, or is explicitly labeled an assumption.

Analyze a project (analyze_project): Scans the source tree, git history, package manifests, env files, and existing docs to return a grounded analysis including summary, architecture, technologies, complexity, documentation coverage, risk findings, and recommendations.
Generate environment variable docs (generate_env_docs): Documents every environment variable a project declares or reads, without ever revealing secret values (only redacted placeholders).
Generate changelog (generate_changelog): Creates a Markdown changelog from real git history, grouped by conventional-commit types (Breaking Changes/Features/Fixes/Other), optionally scoped between tags.
Generate README (generate_readme): Produces a professional README.md with grounded narrative sections and deterministic installation/configuration/contributing/license from real project facts.
Review documentation (review_documentation): Scores existing docs on coverage/quality/consistency (0-100 each) and lists missing sections and recommendations.
Generate architecture docs (generate_architecture): Creates Architecture.md including layers, modules, dependency graph (Mermaid), design patterns, tech stack, and ADRs, all grounded in real source structure and imports.
Generate database docs (generate_database_docs): Reads a real Prisma or SQL schema to document tables, columns, relations, indexes, ER diagram, and business rules.
Generate API docs (generate_api_docs): Documents endpoints from a real OpenAPI/Swagger spec or falls back to regex-extracted routes from source (Express/Fastify/NestJS).
Generate sequence diagrams (generate_sequence_diagram): Renders Mermaid + PlantUML sequence diagrams from caller-supplied steps or a static symbol trace.
Generate flow diagrams (generate_flow_diagram): Builds user/application/request/auth/deployment/data flow diagrams grounded in real evidence (layer directories, dependencies).
Generate release notes (generate_release_notes): Groups real commits between tags by conventional-commit type, optionally including merged GitHub PRs.
Generate deployment docs (generate_deployment_docs): Reads real Docker/docker-compose/Kubernetes/Terraform files for scaling and rollback guidance.
Generate security docs (generate_security_docs): Reports real auth/RBAC/encryption/secrets evidence and includes an honest OWASP Top 10 checklist.
Generate testing docs (generate_testing_docs): Reports the real detected test framework, test file counts, and coverage-config presence.
Generate Product Requirements Doc (PRD) (generate_prd): Creates a grounded PRD (the only LLM-heavy tool) with assumptions explicitly flagged.
Generate Technical Requirements Doc (TRD) (generate_trd): Composes a technical requirements document from the real output of other structural tools.
Generate contribution guide (generate_contribution_guide): Renders real install/test/lint/build commands from the project’s package manifest.
Synchronize docs (synchronize_docs): Regenerates only docs whose real content actually changed, via content hashing, never overwriting hand-edited files.
Works with any MCP client: Integrates with Claude Code, Claude Desktop, Cursor, Windsurf, VS Code, Cline, Continue.dev, Zed, Gemini CLI, JetBrains AI, and others.

Documentation Assistant MCP Server

An MCP server that generates and maintains grounded, enterprise-grade documentation for any codebase — by analyzing real project artifacts (source tree, git history, package manifests, env files, existing docs), never fabricating facts. Every claim in a generated document either traces back to something the server's own analyzers actually found, or is explicitly labeled an assumption — never silently blended into the narrative as if it were fact.

Related MCP server: Documentation MCP Server

Setup Guide

Prerequisites

Node.js >= 20
An Anthropic API key — required for analyze_project and generate_readme's narrated sections; generate_env_docs, generate_changelog, and review_documentation are fully deterministic and work without a real key (see docs/Testing.md), but this server only ever talks to Anthropic — it validates ANTHROPIC_API_KEY against Anthropic's own key shape (sk-ant-...) at startup and refuses to boot with a key from another provider, a typo, or an empty value, even if you only intend to use the deterministic tools (see docs/Configuration.md)

There are two ways to run this server: install the published npm package (recommended for everyone using it as a tool), or build from source (for contributors).

Option A — Install from npm (recommended)

Nothing to clone or build — every client config in this README uses npx, which downloads and caches the package on first run:

npx -y docs-assistant-mcp

The server speaks MCP over stdio — running it directly in a terminal will look like it hangs; that's expected, it's waiting for a client to connect over stdin/stdout. It's meant to be launched by an MCP client (see below), not run standalone. Set ANTHROPIC_API_KEY as an environment variable — everything else has a sensible default, see docs/Configuration.md.

Prefer a global install instead of npx re-resolving on every launch:

npm install -g docs-assistant-mcp
docs-assistant-mcp

Option B — Build from source (for contributors)

git clone <this-repo-url>
cd docs-assistant-mcp
pnpm install   # pnpm >= 9; `corepack enable` provides it on most systems
cp .env.example .env

Open .env and set at minimum:

ANTHROPIC_API_KEY=sk-ant-...

pnpm build     # produces dist/index.js, a self-contained ESM bundle with a shebang
node dist/index.js

During development, pnpm dev runs the server straight from TypeScript source with hot reload. See CONTRIBUTING.md and docs/Development.md for the full local workflow.

Verify it's working

Point any MCP client at the server (npx -y docs-assistant-mcp, or dist/index.js if built from source) and list its tools — all 18 should appear (see the Tools table below, or docs/Tool-Reference.md for full contracts). See docs/Troubleshooting.md if the server exits immediately (almost always a missing/invalid ANTHROPIC_API_KEY).

Usage Guide

Step 1 — Understand a project

Ask your AI agent something like:

"Analyze the project at /path/to/my-project"

which drives a call like:

{ "tool": "analyze_project", "arguments": { "projectPath": "/absolute/path/to/my-project" } }

The server scans the project's filesystem, git history, package manifests, and env files, runs every deterministic analyzer (technology detection, complexity, documentation coverage, risk findings), and asks Claude to narrate a grounded summary and architecture description. Every claim in the response traces back to a fact the analyzers actually computed — anything the model infers beyond that is returned separately in assumptions[], never blended into the narrative.

Step 2 — Generate documentation

{ "tool": "generate_readme", "arguments": { "projectPath": "/absolute/path/to/my-project" } }

Returns a ready-to-use README.md. Overview/Features/Usage/Troubleshooting are narrated and grounded; Installation/Configuration/Contributing/License are generated deterministically straight from facts (the actual install command for the detected package ecosystem, an actual table of env vars, whether a LICENSE/CONTRIBUTING file really exists) — nothing here is guessed.

{ "tool": "generate_env_docs", "arguments": { "projectPath": "/absolute/path/to/my-project" } }
{ "tool": "generate_changelog", "arguments": { "projectPath": "/absolute/path/to/my-project" } }

Both fully deterministic. generate_env_docs documents every environment variable a project declares or reads, without ever reading a real .env file's actual values. generate_changelog groups real commits into Breaking Changes/Features/Fixes/Other via conventional-commit types — optionally scoped with fromRef/toRef (e.g. two tags).

Step 3 — Review what already exists

{ "tool": "review_documentation", "arguments": { "projectPath": "/absolute/path/to/my-project" } }

Returns coverageScore/qualityScore/consistencyScore (0–100 each) plus missingSections[]/recommendations[] — works against hand-written docs alone, no other generator needs to have run first.

Step 4 — Document the architecture

{ "tool": "generate_architecture", "arguments": { "projectPath": "/absolute/path/to/my-project" } }

Returns content (Architecture.md), plus its parts separately: layers[]/modules[] (from the real src/ directory structure), dependencyGraph (Mermaid, built from real relative-import statements), dataFlow (Mermaid), designPatterns[] (evidence-grounded, from real class names — e.g. a FooRepository class is Repository-pattern evidence, two classes implementing the same interface is Strategy-pattern evidence), techStack[], and decisions[] (titles pulled from docs/adr/*.md, if any exist). Only the overview paragraph is narrated; everything else is rendered deterministically from what the scan actually found.

Step 5 — Document the database, API, and system flows

{ "tool": "generate_database_docs", "arguments": { "projectPath": "/absolute/path/to/my-project" } }
{ "tool": "generate_api_docs", "arguments": { "projectPath": "/absolute/path/to/my-project" } }

Both fully deterministic. generate_database_docs reads a real schema.prisma (or a .sql file with a CREATE TABLE statement) — tables, columns, relations, indexes, a Mermaid ER diagram, and business rules inferred from real naming conventions (soft-delete columns, audit timestamps, required vs. optional foreign keys). generate_api_docs prefers a real OpenAPI/Swagger spec when one exists in the project; otherwise it falls back to regex-extracted Express/Fastify/NestJS routes from source, and the source field in the response always says which.

{ "tool": "generate_sequence_diagram", "arguments": { "projectPath": "/absolute/path/to/my-project", "flowSteps": [{ "from": "Client", "to": "API", "message": "POST /orders" }] } }
{ "tool": "generate_flow_diagram", "arguments": { "projectPath": "/absolute/path/to/my-project", "flowType": "auth" } }

Both render Mermaid + PlantUML. generate_sequence_diagram either renders flowSteps you supply verbatim (zero inference), or — given traceHint instead — does a static regex reference scan for that symbol across JS/TS source, labeled "code-reference" since it's not a true runtime trace. generate_flow_diagram builds user/application/request/auth/deployment/data flows strictly from real evidence (layer directories, detected auth/infra dependencies) — a flow type with no supporting evidence returns a notes[] explanation instead of an invented diagram.

Step 6 — Document releases, deployment, security, and testing

{ "tool": "generate_release_notes", "arguments": { "projectPath": "/absolute/path/to/my-project", "fromTag": "v1.0.0", "toTag": "v1.1.0" } }
{ "tool": "generate_deployment_docs", "arguments": { "projectPath": "/absolute/path/to/my-project" } }
{ "tool": "generate_security_docs", "arguments": { "projectPath": "/absolute/path/to/my-project" } }
{ "tool": "generate_testing_docs", "arguments": { "projectPath": "/absolute/path/to/my-project" } }

All four fully deterministic. generate_release_notes groups real commits between two refs/tags by conventional-commit type; set includePrs: true to also include real merged GitHub PRs (requires GITHUB_TOKEN, see Configuration — returns an empty list otherwise, never fabricated PR data). generate_deployment_docs reads real Dockerfile/docker-compose/Kubernetes manifest/Terraform files for scaling and rollback guidance. generate_security_docs reports real auth/RBAC/encryption dependency evidence and a real .gitignore/env-var check, plus an OWASP Top 10 checklist that honestly marks categories "not-detected" when nothing in the project can confirm them either way. generate_testing_docs reports the real detected test framework, real unit/integration/e2e file counts by directory convention, and real coverage-config presence.

Step 7 — Product/technical requirements and contribution docs

{ "tool": "generate_trd", "arguments": { "projectPath": "/absolute/path/to/my-project" } }
{ "tool": "generate_contribution_guide", "arguments": { "projectPath": "/absolute/path/to/my-project" } }
{ "tool": "generate_prd", "arguments": { "projectPath": "/absolute/path/to/my-project", "requirementsHint": "Focus on the billing module." } }

generate_trd and generate_contribution_guide are fully deterministic: the TRD composes the real content every other structural tool above already produced for the same project (a roll-up, not a new source of facts); the contribution guide renders real install/test/lint/build commands from your package manifest. generate_prd is the one tool in this server that calls the LLM — grounded in the same facts analyze_project uses, plus your optional requirementsHint. It's the highest-inference tool here, so expect a longer assumptions[] array than the structural tools above; that's the grounding mechanism working as intended, not a bug.

Step 8 — Keep docs in sync

{
  "tool": "synchronize_docs",
  "arguments": {
    "projectPath": "/absolute/path/to/my-project",
    "manifest": [
      {
        "path": "docs/Security.md",
        "tool": "generate_security_docs",
        "lastGeneratedHash": "<hash you recorded last time>"
      }
    ]
  }
}

Fully deterministic. For each manifest entry, reads the doc directly off disk: if its current hash doesn't match lastGeneratedHash, it was hand-edited since it was last generated and comes back as a conflicts[] entry — never overwritten. Otherwise it's regenerated and reported as skipped (unchanged) or updated (with fresh content for you to write and the new hash to record). Only supports the fully deterministic content tools above (generate_readme/ generate_architecture/generate_prd call the LLM, so hash-comparing their output isn't meaningful — see docs/Tool-Reference.md).

Tips

Pass an absolute projectPath, not relative — this server reads the filesystem directly on the machine it runs on; it has no notion of your AI agent's current working directory.
If a generated document's assumptions[] array is non-empty, that's the server telling you exactly what it couldn't ground in a fact — not a bug.
generate_changelog needs a real git repository at projectPath; it returns a VALIDATION_ERROR otherwise rather than fabricating history.

Integrating with AI Agents / MCP Clients

The server is a standard MCP server over stdio — command: npx, args: ["-y", "docs-assistant-mcp"], plus whatever env vars you need from docs/Configuration.md. Every client below just wants that triple in a slightly different place; npx -y downloads and caches the published npm package on first run, so there's nothing to clone or build first.

Built from source instead? Swap "command": "npx", "args": ["-y", "docs-assistant-mcp"] for "command": "node", "args": ["/absolute/path/to/docs-assistant-mcp/dist/index.js"] in any of the configs below — an absolute path, since relative paths resolve against the client's working directory, not this repo.

Claude Code

claude mcp add docs-assistant \
  --scope project \
  -e ANTHROPIC_API_KEY=sk-ant-... \
  -- npx -y docs-assistant-mcp

(--scope project writes to .mcp.json, committable so your team gets it too; use --scope user for a personal, machine-wide registration instead.) Or edit .mcp.json directly:

{
  "mcpServers": {
    "docs-assistant": {
      "command": "npx",
      "args": ["-y", "docs-assistant-mcp"],
      "env": { "ANTHROPIC_API_KEY": "sk-ant-..." }
    }
  }
}

Run claude mcp list to confirm it's registered, then ask Claude Code to analyze or document a project — it will discover and call the tools directly.

Claude Desktop

Edit the config file (create it if it doesn't exist):

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "docs-assistant": {
      "command": "npx",
      "args": ["-y", "docs-assistant-mcp"],
      "env": { "ANTHROPIC_API_KEY": "sk-ant-..." }
    }
  }
}

Restart Claude Desktop afterward — new servers are only picked up on launch.

Cursor

Add to .cursor/mcp.json in your project (or ~/.cursor/mcp.json for a global registration):

{
  "mcpServers": {
    "docs-assistant": {
      "command": "npx",
      "args": ["-y", "docs-assistant-mcp"],
      "env": { "ANTHROPIC_API_KEY": "sk-ant-..." }
    }
  }
}

Cursor picks up project-scoped MCP servers automatically; you can also manage them under Settings → MCP.

Windsurf

Windsurf → Settings → Cascade → MCP Servers → "View raw config" opens ~/.codeium/windsurf/mcp_config.json for direct editing:

{
  "mcpServers": {
    "docs-assistant": {
      "command": "npx",
      "args": ["-y", "docs-assistant-mcp"],
      "env": { "ANTHROPIC_API_KEY": "sk-ant-..." }
    }
  }
}

Antigravity

Antigravity supports MCP servers via the same command/args/env shape used above, managed through its MCP/tools settings panel (look for "MCP Servers" or "Manage MCP" in Settings):

{
  "mcpServers": {
    "docs-assistant": {
      "command": "npx",
      "args": ["-y", "docs-assistant-mcp"],
      "env": { "ANTHROPIC_API_KEY": "sk-ant-..." }
    }
  }
}

VS Code (Copilot Chat / MCP)

VS Code's built-in MCP support uses a servers key (not mcpServers) and an explicit type. Create .vscode/mcp.json in your workspace:

{
  "servers": {
    "docs-assistant": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "docs-assistant-mcp"],
      "env": { "ANTHROPIC_API_KEY": "sk-ant-..." }
    }
  }
}

VS Code will prompt to start the server the first time you open the workspace; use the "MCP: List Servers" command afterward to confirm it connected.

Cline

Cline (VS Code extension) stores MCP config in cline_mcp_settings.json:

macOS: ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
Windows: %APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json
Linux: ~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json

{
  "mcpServers": {
    "docs-assistant": {
      "command": "npx",
      "args": ["-y", "docs-assistant-mcp"],
      "env": { "ANTHROPIC_API_KEY": "sk-ant-..." }
    }
  }
}

Continue.dev

Continue uses YAML, not JSON — add an entry under the top-level mcpServers key in config.yaml (or drop a standalone file under .continue/mcpServers/):

mcpServers:
  - name: docs-assistant
    command: npx
    args:
      - -y
      - docs-assistant-mcp
    env:
      ANTHROPIC_API_KEY: sk-ant-...

Zed

Zed uses a context_servers key (not mcpServers) with a source: "custom" field, in settings.json:

{
  "context_servers": {
    "docs-assistant": {
      "source": "custom",
      "command": "npx",
      "args": ["-y", "docs-assistant-mcp"],
      "env": { "ANTHROPIC_API_KEY": "sk-ant-..." }
    }
  }
}

Gemini CLI

Add to mcpServers in ~/.gemini/settings.json (user-scope) or .gemini/settings.json (project-scope):

{
  "mcpServers": {
    "docs-assistant": {
      "command": "npx",
      "args": ["-y", "docs-assistant-mcp"],
      "env": { "ANTHROPIC_API_KEY": "sk-ant-..." }
    }
  }
}

JetBrains AI Assistant

Settings → Tools → AI Assistant → Model Context Protocol (MCP) → "Command" (top-left of the dialog) → "As JSON":

{
  "mcpServers": {
    "docs-assistant": {
      "command": "npx",
      "args": ["-y", "docs-assistant-mcp"],
      "env": { "ANTHROPIC_API_KEY": "sk-ant-..." }
    }
  }
}

Works the same way across IntelliJ IDEA, WebStorm, PyCharm, and other JetBrains IDEs with the AI Assistant plugin installed.

Any other MCP client

Any client that speaks MCP over stdio works the same way: launch npx -y docs-assistant-mcp, pass ANTHROPIC_API_KEY (and any other vars from docs/Configuration.md) as environment variables, and let the client's tool-discovery handshake do the rest. See docs/API.md for the wire-level details.

Tools

All 18 tools are implemented.

Tool	Purpose
`analyze_project`	Grounded project summary, architecture, complexity, coverage, risks, recommendations
`generate_env_docs`	Document every environment variable, never exposing secret values
`generate_changelog`	Markdown changelog from real git history, grouped by conventional-commit type
`generate_readme`	Grounded README with deterministic Installation/Configuration/Contributing/License
`review_documentation`	Score existing docs on coverage/quality/consistency, list gaps
`generate_architecture`	Architecture.md: layers, modules, patterns, dependency graph
`generate_database_docs`	Tables, relations, indexes, ER diagram, business rules from a real Prisma/SQL schema
`generate_api_docs`	Endpoint docs from a real OpenAPI/Swagger spec, or code-derived routes as a fallback
`generate_sequence_diagram`	Mermaid + PlantUML sequence diagram from caller-supplied steps or a static symbol trace
`generate_flow_diagram`	User/application/request/auth/deployment/data flow diagrams grounded in real evidence
`generate_release_notes`	Release notes from real commits, optionally + real merged GitHub PRs
`generate_deployment_docs`	Deployment/scaling/rollback guide from real Dockerfile/docker-compose/K8s/Terraform
`generate_security_docs`	Auth/RBAC/encryption/secrets evidence + an OWASP Top 10 checklist
`generate_testing_docs`	Testing strategy from the real test suite structure
`generate_prd`	Product Requirements Document, grounded + heavily assumption-flagged
`generate_trd`	Technical Requirements Document, composed from the other tools' real output
`generate_contribution_guide`	CONTRIBUTING.md from real install/test/lint/build commands
`synchronize_docs`	Regenerate only docs whose real content actually changed, via content hashing

Full contracts: docs/Tool-Reference.md.

Documentation

Architecture · Tool Reference · Configuration · API · Security Guide · Development · Deployment · Testing · Troubleshooting · ADRs

Contributing

Bug reports, feature requests, and pull requests are welcome — see CONTRIBUTING.md for the local dev setup and PR checklist. Participation is governed by the Code of Conduct.

Security

This server reads real project artifacts (source, git history, .env.example-style files) and calls the Anthropic API for narrated sections — see SECURITY.md for the vulnerability-reporting process and docs/Security-Guide.md for what's actually implemented (secret redaction, filesystem sandboxing, prompt-injection framing, fact-grounding).

License

Apache License 2.0

Available Tools

6 tools

analyze_projectAnalyze ProjectA

Scan a project (source tree, git history, package manifests, env files, existing docs) and return a grounded architect-level analysis: summary, architecture, technologies, complexity, documentation coverage, risk findings, and recommendations. Every claim traces back to a fact the scan actually computed — never fabricated.

ParametersJSON Schema

Name	Required	Description	Default
`projectPath`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It states that the scan covers source tree, git history, manifests, env files, and docs, and importantly guarantees every claim is grounded in computed facts. It does not detail permissions or failure cases, but the read-only nature of a scan is clear, and the grounding claim adds valuable behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler. The first sentence efficiently packs the tool's scope and output list into one clause, and the second adds a concise quality guarantee. It is well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, read-only tool with no output schema, the description explains both the inputs and the return structure in sufficient detail. It could mention when not to use it relative to sibling tools, but that gap belongs to usage guidelines; the tool's functionality is fully described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by clarifying what a project consists of and implying the parameter is the path to the project root. It does not explicitly define projectPath syntax or absolute/relative semantics, but the context is sufficient for correct usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Scan') and resource ('a project'), and enumerates both the input sources and the output fields of the analysis. It clearly distinguishes this holistic analysis tool from sibling tools that generate specific documents like README or changelog.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for obtaining a comprehensive, grounded project assessment and lists what it scans, but it does not explicitly state when to prefer this over sibling tools or mention any exclusions or prerequisites. The use case is inferable but not directly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_architectureGenerate Architecture DocumentationB

Generate Architecture.md grounded in the real project: layers/modules from actual directory structure, a dependency graph from real relative-import statements, design-pattern evidence from real class names, tech stack, and recorded ADRs. The overview paragraph is narrated but every claim traces to a fact; the graphs/lists are rendered deterministically.

ParametersJSON Schema

Name	Required	Description	Default
`projectPath`	Yes

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden. It discloses that the overview is narrated but fact-traceable and that graphs/lists are rendered deterministically, which is helpful. However, it does not mention whether the tool writes to the filesystem, overwrites existing files, or what happens if ADRs are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose, and every clause adds specific detail about outputs and reliability. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains what content is generated and notes deterministic behavior, but it lacks operational details such as whether it overwrites files, requires a valid project structure, or if any of the listed inputs (ADRs) are mandatory. Given no annotations or output schema, a bit more practical guidance is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description never mentions the single required parameter 'projectPath'. With schema description coverage at 0%, the description provides no guidance on the expected value or constraints beyond the schema's bare minimum length, leaving the parameter semantics entirely unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates Architecture.md with specific content sources: layers/modules from directory structure, dependency graph from relative imports, design-pattern evidence from class names, tech stack, and ADRs. This distinguishes it from sibling documentation tools like generate_readme or generate_changelog.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for generating architecture documentation grounded in real project facts, but it does not explicitly state when to use this tool versus alternatives like generate_readme or generate_changelog, nor any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_changelogGenerate ChangelogA

Generate a Markdown changelog from real git history, grouped into Breaking Changes/Features/Fixes/Other via conventional-commit types — a reformatting of commit messages that already exist, never invented entries. Optionally scoped between fromRef/toRef (e.g. two tags).

ParametersJSON Schema

Name	Required	Description	Default
`toRef`	No
`fromRef`	No
`projectPath`	Yes

TDQS

A4.2/5.0

Behavior3/5

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 adds valuable transparency by guaranteeing no invented entries ('never invented entries'), which implies a non-fabricating, read-only transformation of git history. Yet it does not explicitly clarify whether the tool writes a file or returns output to stdout, nor does it address edge cases like non-conventional commits or missing git history. This ambiguity prevents a higher score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no redundant phrasing. It front-loads the core action and grouping behavior, then adds the scoping option in a clear, compact sentence. Every word earns its place, making it appropriately concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given moderate tool complexity and no output schema, the description provides a complete-enough picture: it names the output format ('Markdown changelog'), the grouping categories (Breaking Changes/Features/Fixes/Other), and the optional input refs. It could address edge cases (e.g., behavior when no conventional commits exist) or the exact return/output mode, but for a tool of this simplicity, the description is largely sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must compensate. It explains the semantics of fromRef/toRef as optional scoping ('Optionally scoped between fromRef/toRef'), giving concrete meaning beyond parameter names. projectPath is not explicitly described, but as a common term it is inferable. This is a strong compensation given the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: generating a Markdown changelog from real git history, grouped by conventional-commit types. It uses a specific verb ('generate'), names the resource ('changelog'), and distinguishes from sibling tools like generate_readme or analyze_project. The clarification that it is 'a reformatting of commit messages that already exist, never invented entries' further sharpens the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool: it operates on 'real git history' and can be scoped 'between fromRef/toRef (e.g. two tags)'. This helps the agent understand the intended use case. However, it does not explicitly name alternatives or state when not to use it, leaving slight ambiguity relative to sibling tools, but the context is strong enough to infer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_env_docsGenerate Environment Variable DocumentationA

Document every environment variable a project declares (.env.example/.env.sample/.env.template) or reads in source (process.env/os.environ/os.Getenv), each with its required/default/example — secret-shaped values are never echoed, only redacted placeholders.

ParametersJSON Schema

Name	Required	Description	Default
`projectPath`	Yes

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the transparency burden. It discloses a key safety behavior (secret values are redacted) and the range of sources scanned. It does not explicitly state whether the tool modifies files or only outputs documentation, but the verb 'Document' and the lack of side-effect warnings are reasonably clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense sentence packed with necessary information (input sources, output details, redaction). It is front-loaded and contains no filler, though it could be split into two sentences for readability without adding length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers what the tool does, what it scans, what it reports, and the redaction policy. It does not specify the output format (e.g., markdown, console) or whether a file is written, which would be helpful given there is no output schema. But overall, it is sufficiently complete for a tool with a single parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has one parameter, projectPath, with a clear name and type (string, required). The description does not mention the parameter at all, and schema coverage is 0%. However, since the parameter is self-explanatory and there is only one, the lack of additional description is not a major gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Document') and resource ('every environment variable a project declares or reads'), with explicit sources (.env files and process.env/os.environ/os.Getenv). This distinguishes it from siblings like generate_readme or generate_changelog.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on what the tool covers and how it behaves, which implies when to use it (when env var documentation is needed). It does not explicitly mention alternatives or exclusions, but the scope is well defined enough for an agent to select it appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_readmeGenerate READMEA

Generate a professional README.md grounded in the real project (source, dependencies, git history, env vars, existing docs). Overview/Features/Usage/Troubleshooting are narrated but every claim traces to a fact; Installation/Configuration/Contributing/License are generated deterministically from facts alone.

ParametersJSON Schema

Name	Required	Description	Default
`projectPath`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses important behavioral traits: it grounds content in real project data, distinguishes between narrated and deterministically generated sections, and claims every claim traces to a fact. This exceeds what annotations (which are absent) would provide, though it does not specify whether the tool writes the README to disk or returns it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: two sentences that front-load the main purpose, then add essential detail about grounding and section generation. No filler words and every sentence provides value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one simple parameter and no annotations or output schema, the description covers purpose, grounding, data sources, and generation behavior. It lacks explicit information about the return value or file-writing behavior, but for a README generator this is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero schema descriptions, the description compensates by implicitly explaining that the projectPath parameter points to the project root containing source, dependencies, git history, etc. This gives meaningful context beyond the bare schema, even though it does not explicitly describe the parameter format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to generate a professional README.md grounded in real project data. It specifies the output resource (README.md) and differentiates from sibling tools by detailing the content sections and grounding approach.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The usage is implied: use this when you need a README for a project. However, there is no explicit guidance on when not to use it or how it compares to sibling tools like generate_env_docs or generate_changelog.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

review_documentationReview DocumentationA

Score a project's existing documentation on coverage/quality/consistency (0-100 each, computed deterministically from headings/word counts/topic coverage) and list missing sections and recommendations. Works against hand-written docs alone — no other generator tool needs to have run first.

ParametersJSON Schema

Name	Required	Description	Default
`projectPath`	Yes

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must cover behavioral traits. Adds that scoring is 'computed deterministically from headings/word counts/topic coverage,' which is useful. Doesn't explicitly state read-only behavior but 'Score' implies it; some side-effect info missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, first sentence encapsulates purpose, second adds a key usage context. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, method, output, and usage context for a simple tool. Lacks parameter details and explicit return structure, but acceptable for a 1-param tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and description does not mention the sole parameter projectPath. Agent must infer from name; no path format or meaning explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Score a project's existing documentation' with specific metrics (coverage/quality/consistency 0-100) and output (missing sections, recommendations). Distinguishes from sibling generator tools by noting it works against hand-written docs only.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States 'Works against hand-written docs alone — no other generator tool needs to have run first,' giving clear context for when to use. Doesn't explicitly name alternatives, but implies use for review, not generation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv0.1.0Aug 11, 2026
- First observedanalyze_project
- First observedgenerate_architecture
- First observedgenerate_changelog
- First observedgenerate_env_docs
- First observedgenerate_readme
- First observedreview_documentation

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-08-11 14:30 across 6 tools

Disambiguation5/5

Each tool targets a distinct deliverable: overall analysis, env docs, changelog, README, docs review, and architecture doc. No two tools have overlapping purposes; even analyze_project and generate_architecture differ in output scope (overview vs. detailed architecture doc).

Naming Consistency4/5

Four tools follow the 'generate_' pattern, but analyze_project and review_documentation use different verbs. This is a minor deviation; the names are still descriptive and follow a readable <verb>_<object> convention overall.

Tool Count5/5

Six tools is well-scoped for a documentation assistant. Each tool covers a specific documentation need without redundancy, and the count feels neither thin nor bloated.

Completeness4/5

The set covers core documentation generation (README, env, changelog, architecture) and review, which is strong for the domain. Minor gaps exist, such as no API reference generation or doc update tool, but agents can work around these.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

docuwriter AOAuth
ai.docuwriter
Generate, search, and manage codebase documentation on DocuWriter.ai. 72 tools incl. Autopilot.
AI & Machine Learning Developer Tools Documentation Access
723
SpiderbrainOAuth
ai.spiderbrain
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
Code Analysis Developer Tools RAG Systems
13
Rosey – Quality verification for human and AI contentOAuth
com.getrosey
Fact-checks generated content against your sources of truth showing what to trust, change, & verify.
Testing & QA Tools RAG Systems AI & Machine Learning
1
Brain Scanner DOAuth
io.github.kevin-lozada-santos
Codebase graphs, caller impact analysis, and recorded project context for AI coding agents.
Code Analysis Developer Tools Knowledge & Memory
1361

Related MCP Servers

Documentation MCP Server
Developer Tools Code Analysis Documentation Access
LiL-Loco
A
license
A
quality
B
maintenance
Generates professional documentation for multi-language codebases with deep AST-based code analysis, supporting Docusaurus, MkDocs, and Sphinx frameworks. Includes API documentation generation, PDF export, OpenAPI spec generation, and sales-ready documentation for code marketplaces.
Updated 9 months ago (2025-12-12 00:49 UTC)
9
MIT
Documentation MCP Server
Developer Tools Documentation Access Code Analysis
ThaLoc0one
A
license
A
quality
B
maintenance
Generates professional documentation for multi-language projects with deep code analysis, supporting frameworks like Docusaurus, MkDocs, and Sphinx, including API docs, PDF export, and OpenAPI specifications.
Updated 9 months ago (2025-12-12 01:12 UTC)
9
MIT
codebase-doc-generator
Developer Tools Code Analysis Documentation Access
lazymac2x
A
license
Not graded
quality
D
maintenance
Generates comprehensive documentation (architecture overview, dependency graph, API surface, and README) for any codebase locally without external APIs.
Updated 6 months ago (2026-03-28 10:47 UTC)
3 npm
1
MIT
Documentation MCP
Documentation Access Code Analysis Software Architecture
syamai
A
license
Not graded
quality
D
maintenance
Analyzes codebases to automatically generate README, API docs, architecture diagrams, and CHANGELOG.
Updated 8 months ago (2026-01-12 17:22 UTC)
3 npm
MIT

Documentation Assistant MCP Server

Contents

Setup Guide

Prerequisites

Option A — Install from npm (recommended)

Option B — Build from source (for contributors)

Verify it's working

Usage Guide

Step 1 — Understand a project

Step 2 — Generate documentation

Step 3 — Review what already exists

Step 4 — Document the architecture

Step 5 — Document the database, API, and system flows

Step 6 — Document releases, deployment, security, and testing

Step 7 — Product/technical requirements and contribution docs

Step 8 — Keep docs in sync

Tips

Integrating with AI Agents / MCP Clients

Claude Code

Claude Desktop

Cursor

Windsurf

Antigravity

VS Code (Copilot Chat / MCP)

Cline

Continue.dev

Zed

Gemini CLI

JetBrains AI Assistant

Any other MCP client

Tools

Documentation

Contributing

Security

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers