Analyzes JavaScript codebases to extract functions, classes, and methods, providing documentation coverage metrics and generating improvement suggestions
Generates professional markdown documentation from analyzed codebases, creating organized documentation by file and element type
Analyzes Python codebases to extract code elements including functions, classes, and variables, detecting missing docstrings and generating documentation templates
Analyzes TypeScript codebases to extract functions, classes, methods, interfaces, and types, generating comprehensive documentation and detecting missing documentation
Click on "Install 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., "@Smart Docs MCP Server analyze my TypeScript project and show me what's missing documentation"
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 production-ready Model Context Protocol (MCP) server that intelligently analyzes codebases and generates comprehensive documentation. Built with TypeScript and tree-sitter for accurate code parsing.
Multi-Language Support: Analyze TypeScript, JavaScript, and Python codebases
Smart Analysis: Extract functions, classes, methods, interfaces, types, and variables
Documentation Coverage: Calculate documentation coverage metrics
Missing Doc Detection: Identify undocumented code with severity levels (critical, medium, low)
AI-Powered Suggestions: Generate documentation templates and improvement recommendations
Markdown Output: Professional documentation in markdown format
Related MCP server: Documentation MCP Server
npm install
npm run buildAdd to your MCP client configuration (Claude Desktop):
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"smart-docs": {
"command": "node",
"args": ["C:\\ProjectFolder\\dist\\index.js"]
}
}
}Then restart Claude Desktop.
analyze_codebaseAnalyze a codebase or file to extract code elements and calculate documentation coverage.
Input:
{
"path": "/path/to/your/codebase"
}Output:
Total files analyzed
Total code elements found
Documentation coverage percentage
Detailed breakdown by file and element
generate_documentationGenerate comprehensive markdown documentation for a codebase.
Input:
{
"path": "/path/to/your/codebase",
"format": "markdown"
}Output:
Complete markdown documentation
Summary statistics
Organized by file and element type
detect_missing_docsDetect code elements missing documentation with severity classification.
Input:
{
"path": "/path/to/your/codebase",
"minSeverity": "critical"
}Severity Levels:
Critical: Public classes, interfaces, and exported functions
Medium: Type aliases and exported types
Low: Private methods and internal variables
Output:
List of missing documentation by severity
Summary statistics by severity and type
Detailed element information
suggest_improvementsAnalyze existing documentation and suggest improvements.
Input:
{
"path": "/path/to/your/codebase",
"limit": 20
}Output:
Documentation templates for missing docs
Suggestions for incomplete documentation
Parameter and return value documentation hints
smart-docs-mcp/
├── src/
│ ├── index.ts # MCP server entry point
│ ├── types/
│ │ └── index.ts # TypeScript types and interfaces
│ ├── parsers/
│ │ ├── base-parser.ts # Abstract parser base class
│ │ ├── typescript-parser.ts # TypeScript/JavaScript parser
│ │ └── python-parser.ts # Python parser
│ ├── analyzers/
│ │ ├── codebase-analyzer.ts # Main analysis engine
│ │ └── doc-detector.ts # Missing documentation detector
│ ├── generators/
│ │ ├── markdown-generator.ts # Markdown doc generator
│ │ └── improvement-suggester.ts # Improvement suggestions
│ ├── tools/
│ │ ├── analyze-codebase.ts
│ │ ├── generate-documentation.ts
│ │ ├── detect-missing-docs.ts
│ │ └── suggest-improvements.ts
│ └── utils/
│ └── file-utils.ts # File system utilities
├── package.json
├── tsconfig.json
└── README.mdParsing: Uses tree-sitter to parse source code into Abstract Syntax Trees (AST)
Extraction: Identifies code elements (functions, classes, etc.) from the AST
Documentation Detection: Checks for JSDoc, docstrings, and inline comments
Analysis: Calculates coverage and detects missing documentation
Generation: Creates markdown documentation and improvement suggestions
The server uses intelligent severity classification:
Public APIs (classes, interfaces, exported functions) → Critical
Type definitions and complex types → Medium
Private methods and internal variables → Low
All tools include comprehensive error handling:
Invalid paths return descriptive error messages
Unsupported file types are gracefully skipped
Parse errors include file location and context
# Install dependencies
npm install
# Build the project
npm run build
# Watch mode for development
npm run watch
# Run the server
npm startNode.js >= 18.0.0
TypeScript 5.3+
@modelcontextprotocol/sdk: MCP protocol implementation
tree-sitter: Code parsing engine
tree-sitter-typescript: TypeScript/JavaScript grammar
tree-sitter-python: Python grammar
zod: Schema validation
A test project is included in the test-project/ directory with sample files demonstrating various documentation scenarios.
MIT
Contributions are welcome! Please ensure:
Code follows TypeScript best practices
All new features include error handling
Documentation is updated according
Analyze a codebase or file to extract code elements and calculate documentation coverage. Supports TypeScript, JavaScript, and Python.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to file or directory to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions analysis outputs (extract elements, calculate coverage) but lacks critical behavioral details: whether this is read-only or has side effects, performance characteristics, error handling, or format of results. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise (two sentences) and front-loaded with the core purpose. Every sentence adds value: first states purpose, second adds language support. No wasted words, though it could be slightly more structured with bullet points for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that performs code analysis. It doesn't explain what 'extract code elements' means (functions, classes, etc.), how documentation coverage is calculated, or what the output format looks like. For a tool with one parameter but potentially complex behavior, more context is needed.
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% (the 'path' parameter is fully described in schema), so baseline is 3. The description adds no additional parameter semantics beyond what's in the schema—it doesn't clarify path format requirements, wildcard support, or differences between file vs directory analysis.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze a codebase or file to extract code elements and calculate documentation coverage.' It specifies the verb (analyze), resource (codebase/file), and key outputs (extract elements, calculate coverage). However, it doesn't explicitly differentiate from siblings like 'detect_missing_docs' or 'generate_documentation', which appear related to documentation analysis/generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance. It mentions supported languages (TypeScript, JavaScript, Python), which gives some context, but doesn't explain when to use this tool versus alternatives like 'detect_missing_docs' or 'generate_documentation'. No explicit when/when-not instructions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect code elements that are missing documentation and categorize them by severity (critical, medium, low).
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to file or directory to analyze | |
| minSeverity | No | Minimum severity level to report |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool categorizes by severity but doesn't explain what constitutes 'critical', 'medium', or 'low' severity, how the detection works (static analysis, heuristics), what output format to expect, or whether this is a read-only operation. Significant behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core functionality without unnecessary words. It's appropriately sized for a tool with two parameters and no complex behavioral traits to explain. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a detection/analysis tool with no annotations and no output schema, the description is insufficient. It doesn't explain what types of code elements are analyzed (functions, classes, modules), what documentation standards are expected, what the output looks like, or how results should be interpreted. The agent lacks critical context to use this tool effectively.
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 the schema already documents both parameters ('path' and 'minSeverity'). The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: detecting code elements missing documentation and categorizing them by severity. It specifies the verb 'detect' and the resource 'code elements', but doesn't explicitly differentiate from sibling tools like 'analyze_codebase' or 'suggest_improvements' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'analyze_codebase' or 'generate_documentation'. There's no mention of prerequisites, typical use cases, or exclusions. The agent must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate comprehensive markdown documentation for a codebase or file, including all code elements and their existing documentation.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to file or directory to document | |
| format | No | Output format for documentation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool generates documentation but doesn't cover critical aspects like whether it's read-only or destructive, permission requirements, rate limits, output handling, or error conditions. This leaves significant gaps for an agent to understand how to invoke it safely and effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core functionality without unnecessary details. It's front-loaded with the main purpose and avoids redundancy, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral traits, return values, or error handling, which are crucial for a tool that processes codebases. While concise, it fails to provide enough context for reliable agent use beyond the basic purpose.
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?
The description adds no parameter-specific information beyond what's in the schema, which has 100% coverage for its two parameters ('path' and 'format'). The baseline is 3 because the schema adequately documents the parameters, but the description doesn't enhance understanding with examples, constraints, or usage notes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate comprehensive markdown documentation for a codebase or file, including all code elements and their existing documentation.' It specifies the verb ('generate'), resource ('markdown documentation'), and scope ('codebase or file'), though it doesn't explicitly differentiate from sibling tools like 'analyze_codebase' or 'detect_missing_docs'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools like 'detect_missing_docs' or 'suggest_improvements', nor does it specify prerequisites, constraints, or typical use cases for documentation generation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze existing documentation and suggest improvements, including templates for missing docs and enhancements for incomplete documentation.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Path to file or directory to analyze | |
| limit | No | Maximum number of suggestions to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions analyzing and suggesting improvements but lacks details on permissions needed, whether it modifies files, rate limits, or output format. For a tool that likely involves reading and processing documentation, this gap is significant, though not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words and gets straight to the point. However, it could be slightly more structured by separating the analysis and suggestion components for clarity, but it's still highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on behavior, output, or integration with siblings. Without annotations or output schema, more context on what 'suggestions' entail would improve completeness, but it meets a basic threshold.
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 the schema already documents both parameters ('path' and 'limit'). The description does not add any meaning beyond what the schema provides, such as explaining what types of files are analyzed or how suggestions are prioritized. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze existing documentation and suggest improvements' with specific actions like 'including templates for missing docs and enhancements for incomplete documentation.' It uses specific verbs (analyze, suggest) and identifies the resource (documentation). However, it doesn't explicitly differentiate from sibling tools like 'detect_missing_docs' or 'generate_documentation,' which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the sibling tools 'analyze_codebase,' 'detect_missing_docs,' or 'generate_documentation.' There are no explicit instructions on prerequisites, alternatives, or exclusions. The tool's purpose is clear, but usage context is missing, leaving the agent to infer when this is the appropriate choice.
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. Dates show when Glama detected each change.
analyze_codebasedetect_missing_docsgenerate_documentationsuggest_improvementsEach tool has a clearly distinct purpose with no ambiguity: analyze_codebase extracts and assesses coverage, detect_missing_docs identifies gaps, generate_documentation creates full documentation, and suggest_improvements enhances existing docs. The descriptions clearly differentiate their roles in the documentation workflow.
All tool names follow a consistent verb_noun pattern (analyze_codebase, detect_missing_docs, generate_documentation, suggest_improvements) using snake_case throughout. This predictable naming makes it easy for agents to understand and select tools.
With 4 tools, the set is well-scoped for a documentation-focused server, covering analysis, detection, generation, and improvement phases. Each tool earns its place without redundancy, aligning perfectly with the server's purpose.
The tool surface provides complete lifecycle coverage for documentation tasks: analyze for assessment, detect for gap identification, generate for creation, and suggest for refinement. There are no obvious gaps, enabling agents to handle documentation workflows end-to-end.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate, search, and manage codebase documentation on DocuWriter.ai. 72 tools incl. Autopilot.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
AI-powered codebase analysis — call graphs, security, dead code, complexity. 150+ tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Njengah/smart-docs-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
