docs-assistant-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ANTHROPIC_API_KEY | Yes | Your Anthropic API key. Required for analyze_project and generate_readme's narrated sections; validated against Anthropic key shape (sk-ant-...) at startup. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| analyze_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. |
| generate_env_docsA | 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. |
| generate_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). |
| generate_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. |
| review_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. |
| generate_architectureB | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
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).
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.
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.
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.