docs-assistant-mcp

by HARDIK-31

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
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.
Average 4/5 across 6 of 6 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![docs-assistant-mcp MCP server](https://glama.ai/mcp/servers/HARDIK-31/docs-assistant-mcp/badges/card.svg)](https://glama.ai/mcp/servers/HARDIK-31/docs-assistant-mcp)

Score Badge

Copy to your README.md:

[![docs-assistant-mcp MCP server](https://glama.ai/mcp/servers/HARDIK-31/docs-assistant-mcp/badges/score.svg)](https://glama.ai/mcp/servers/HARDIK-31/docs-assistant-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/HARDIK-31/docs-assistant-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server