Which integrations are available for this server?

Analyzes CodeIgniter 3/4 projects to detect controllers, models, routes, middleware, and MVC patterns for documentation generation. Generates and builds React-based documentation sites with modern templates and static site generation capabilities. Analyzes JavaScript code using the TypeScript Compiler API to extract code structure, JSDoc comments, and dependencies for documentation. Analyzes Laravel projects to detect Illuminate components, routes with attributes, middleware, and framework-specific patterns for documentation. Creates and edits Markdown-based documentation pages across multiple documentation frameworks. Performs deep AST-based analysis of PHP 8+ code including namespaces, types, enums, traits, attributes, routes, and middleware detection. Analyzes Python code using native AST parsing to extract classes, functions, docstrings, and dependencies for documentation. Generates and builds Python-based documentation sites for complex projects with powerful documentation features. Auto-generates OpenAPI 3.0/Swagger specifications from PHP code including routes, middleware, and security schemes in JSON or YAML format. Analyzes Symfony projects to detect framework components, attributes like IsGranted, and Symfony-specific patterns for documentation. Performs deep analysis of TypeScript code using the TypeScript Compiler API to extract classes, interfaces, functions, JSDoc comments, and module dependencies.

How do I use Documentation MCP Server?

1. Click on "Install 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., "@Documentation MCP Server analyze my TypeScript project and generate API docs for it" 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.

Documentation MCP Server

by ThaLoc0one

Overview Schema Related Servers Score Discussions

TypeScript

Local

📚 Documentation MCP Server

A Model Context Protocol (MCP) Server for generating professional documentation with support for multiple frameworks.

✨ Features

🔍 Deep Code Analysis - AST-based Multi-Language Analysis
- TypeScript/JavaScript: TypeScript Compiler API
- Python: Native Python AST module
- Go: Go parser & AST
- PHP: Regex-based analysis + PHP 8+ Features
- Extracts classes, functions, interfaces, methods, properties
- PHP 8+: Enums, Traits, Attributes
- Captures JSDoc/Docstrings/Go Doc/PHPDoc and calculates documentation coverage
- Analyzes imports/exports and module dependencies
🌍 Multi-Language Projects - Automatic detection and parallel analysis of multiple languages
📊 Project Analysis - Automatic code analysis for TypeScript, JavaScript, Python, Go, PHP
🏗️ Structure Generation - Creates complete documentation scaffolds
✍️ Page Editor - Creates and edits individual documentation pages
📖 API Documentation - Generates API docs from code comments
🌐 Static Site Builder - Builds static websites for hosting
📄 PDF Export - Converts documentation to PDF
👀 Live Preview - Local development server

🛠️ Supported Frameworks

Docusaurus (React-based, modern, various templates)
MkDocs (Python-based, Markdown-focused, simple)
Sphinx (Python, very powerful, for complex projects)

🚀 Quick Start

Install globally:
```
npm install -g documentation-mcp-server
```

Configure in Claude Desktop (see SETUP.md):

{
  "mcpServers": {
    "docs": {
      "command": "npx",
      "args": ["-y", "documentation-mcp-server"]
    }
  }
}

Start using the documentation tools in Claude!

📦 Tools

`docs_analyze_project`

Analyzes project structure and performs deep code analysis.

Parameters:

projectPath (string, required) - Path to project
language (enum, optional) - Programming language (typescript, javascript, python, go, rust, java, csharp)
deep (boolean, optional, default: true) - Enables deep code analysis

Deep Analysis Features:

📦 Extracts Classes/Structs, Interfaces, Functions, Enums, Type Aliases
🔍 Captures Methods, Properties, Constructors with complete details
📝 Analyzes JSDoc/Docstrings/Go Doc and calculates documentation coverage
🔗 Tracks Imports/Exports and Module Dependencies
📊 Generates summary statistics
🎯 Multi-Language Support:
- ✅ TypeScript/JavaScript (TypeScript Compiler API)
- ✅ Python (Native Python AST)
- ✅ Go (go/parser & go/ast)
- ✅ PHP v2 (nikic/php-parser AST) - New! 100% accurate
  - Namespaces & Use-Statements
  - Union/Intersection/Nullable Types
  - Enums, Traits, Attributes (PHP 8+)
  - Framework Detection:
    - CodeIgniter 3/4 (Controller, Model)
    - Laravel (Illuminate*)
    - Symfony (Symfony*)
    - MVC Pattern Recognition
  - Route Detection: 🚀
    - Convention-based: /controller/method/{param}
    - Attribute-based: #[Get('/')], #[Post('/')]
    - HTTP Methods: GET, POST, PUT, PATCH, DELETE
    - Parameter Types & Required/Optional Status
  - Middleware Detection: 🔒
    - Laravel: #[Middleware('auth')]
    - Symfony: #[IsGranted('ROLE_ADMIN')]
    - CodeIgniter 4: #[Filter('auth')]
    - CodeIgniter 3: @middleware (Docblocks)
    - Class-Level & Method-Level
    - Middleware Parameters
  - OpenAPI 3.0 Export: 📋
    - Auto-generates Swagger/OpenAPI specs
    - Routes → Paths conversion
    - Middleware → Security Schemes
    - JSON & YAML format support
- ✅ PHP v1 (Regex-based) - Fallback
- 🌍 Automatic Multi-Language Detection
- 🔜 Rust, Java, C# (planned)

Example Response:

{
  "deepAnalysis": {
    "summary": {
      "totalFiles": 11,
      "totalClasses": 2,
      "totalInterfaces": 23,
      "totalFunctions": 16,
      "overallDocCoverage": 3.17
    }
  }
}

`docs_generate_structure`

Generates documentation scaffold.

Parameters:

projectPath (string, required) - Path to project
framework (enum, required) - docusaurus | mkdocs | sphinx
template (string, optional) - Template name
outputPath (string, optional) - Output path (default: ./docs)

`docs_create_page`

Creates or edits documentation page.

Parameters:

docsPath (string, required) - Path to docs
pagePath (string, required) - Relative path to page
title (string, required) - Page title
content (string, required) - Markdown content

`docs_generate_api`

Generates API documentation from code.

Parameters:

projectPath (string, required) - Path to source code
outputPath (string, required) - Output path
language (enum, required) - Programming language

`docs_build_static`

Builds static website.

Parameters:

docsPath (string, required) - Path to docs
framework (enum, required) - Framework
outputPath (string, optional) - Output path (default: ./build)

`docs_export_pdf`

Exports documentation as PDF.

Parameters:

docsPath (string, required) - Path to docs
outputPath (string, required) - PDF output path
includePages (array, optional) - Specific pages

`docs_preview`

Starts local dev server.

Parameters:

docsPath (string, required) - Path to docs
framework (enum, required) - Framework
port (number, optional) - Port (default: 3000/8000)

`docs_generate_openapi`

Generates OpenAPI 3.0 specification from PHP code.

Parameters:

projectPath (string, required) - PHP project path
outputPath (string, optional) - Output path (default: ./openapi.json)
format (enum, optional) - json | yaml (default: json)
title (string, optional) - API title
version (string, optional) - API version
serverUrl (string, optional) - API server URL

`docs_generate_sales_docs` 🎯 NEW!

Generates professional, sales-ready documentation for CodeCanyon, ThemeForest, etc.

Parameters:

projectPath (string, required) - PHP project path
outputDir (string, optional) - Output directory (default: ./sales-docs)
productName (string, required) - Product name
productVersion (string, optional) - Version (default: 1.0.0)
author (string, required) - Author/Company
description (string, required) - Product description
price (string, optional) - Price (e.g., "$49")
demoUrl (string, optional) - Live demo URL
supportEmail (string, optional) - Support email
features (array, optional) - List of key features

Generated Files:

README.md (2.5 KB) - Product overview with features, statistics, requirements
INSTALLATION.md (3.2 KB) - Step-by-step setup guide
API_REFERENCE.md (24.2 KB) - Complete API documentation
CONFIGURATION.md (2.1 KB) - Environment variables, security
EXAMPLES.md (4.0 KB) - Code examples (JS, PHP, Python)
FAQ.md (2.2 KB) - Frequently asked questions
CHANGELOG.md (0.9 KB) - Version history
COMPLETE_DOCUMENTATION.md (39.0 KB) - All-in-one for PDF

Total: ~78 KB professional documentation!

🏗️ Architecture

src/
├── index.ts                    # MCP Server main file
├── core/                       # Core modules for deep analysis
│   ├── types.ts               # Type definitions for all languages
│   └── analyzer.ts            # Abstract base class & factory
├── analyzers/                  # Language-specific analyzers
│   ├── typescript.ts          # TypeScript/JavaScript (TS Compiler API)
│   ├── python.ts              # Python wrapper (subprocess)
│   ├── go.ts                  # Go wrapper (subprocess)
│   └── helpers/               # Native language parsers
│       ├── python_analyzer.py # Python AST parser
│       └── go_analyzer.go     # Go AST parser
└── tools/                      # MCP tool implementations
    ├── analyzeProject.ts      # Deep analysis integration
    ├── generateStructure.ts
    ├── createPage.ts
    ├── generateApi.ts
    ├── buildStatic.ts
    ├── exportPdf.ts
    └── preview.ts

🔬 Deep Analysis Pipeline

File Scanning - Scans project directory
Language Detection - Detects dominant programming language
Analyzer Selection - Selects appropriate AST parser (Factory Pattern)
AST Parsing - Parses code files with language-specific parser
- TypeScript: TS Compiler API (in-process)
- Python: Python AST module (subprocess)
- Go: go/parser & go/ast (subprocess)
Symbol Extraction - Extracts all code symbols (Classes, Functions, etc.)
Documentation Analysis - Captures documentation comments
Summary Generation - Calculates statistics and coverage

📝 License

MIT

Available Tools

9 tools

docs_analyze_projectB

Analyze project structure and perform deep code analysis to understand the project for documentation generation. Supports TypeScript, JavaScript, Python, Go, and more. Deep analysis extracts classes, functions, interfaces, documentation coverage, and more.

ParametersJSON Schema

Name	Required	Description
`projectPath`	Yes	Path to the project directory to analyze
`language`	No	Primary programming language (typescript, javascript, python, go, etc.)
`deep`	No	Enable deep code analysis using language-specific AST parsers (default: true)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It describes the analysis but does not state whether the tool is read-only, requires authentication, or has side effects. Key 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.

Conciseness4/5

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

The description is concise (two sentences) with the purpose front-loaded. The second sentence adds useful details without fluff, earning a high score for efficiency.

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

Completeness2/5

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

The description lacks information about output format, return behavior, and potential blocking nature. Since there is no output schema, the description should compensate but does not provide sufficient detail for an agent to fully understand the tool's response.

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?

Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning: it mentions extracted elements like classes and functions, but parameter-specific guidance is largely redundant with the schema.

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 verb 'Analyze' and the resources 'project structure' and 'code analysis' for documentation generation, distinguishing it from sibling tools that build, create, export, or generate specific documentation.

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 when understanding the project before documentation generation but does not explicitly state when not to use it or mention alternative tools like docs_generate_structure.

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

docs_build_staticB

Build static website for online hosting (ready for GitHub Pages, Netlify, Vercel, etc.)

ParametersJSON Schema

Name	Required	Description
`docsPath`	Yes	Path to documentation directory
`framework`	Yes	Documentation framework used
`outputPath`	No	Output path for built site (default: ./build)

TDQS

B3.4/5.0

Behavior2/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 fails to mention that the tool generates files in the output path, may overwrite existing files, or requires an existing documentation directory and installed framework. The description is too vague about side effects.

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 a single, concise sentence that front-loads the core action and purpose. No unnecessary words or repetition.

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

Completeness2/5

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 should provide more context about execution (e.g., that output is written to disk, that docsPath must contain a valid project, that framework must be installed). It currently leaves many operational details unstated.

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 input schema covers all three parameters with clear descriptions (100% coverage). The tool description adds no extra parameter information, so baseline score of 3 is appropriate—it neither enhances nor detracts from the schema.

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: build a static website for online hosting. It uses a specific verb ('Build') and resource ('static website'), and distinguishes itself from sibling tools like docs_preview (local preview) and docs_export_pdf (PDF export).

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 usage for deployment to platforms like GitHub Pages, Netlify, Vercel, but does not explicitly state when not to use it or mention alternatives like docs_preview for local testing. Guidance is present but not fully explicit.

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

docs_create_pageB

Create or edit individual documentation pages with Markdown content

ParametersJSON Schema

Name	Required	Description
`docsPath`	Yes	Path to documentation directory
`pagePath`	Yes	Relative path for the page (e.g., 'guides/getting-started.md')
`title`	Yes	Page title
`content`	Yes	Markdown content for the page

TDQS

B3.1/5.0

Behavior2/5

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

The description lacks detail on side effects, such as whether it overwrites existing pages, creates intermediate directories, or requires specific permissions. No annotations are provided to compensate, leaving the agent with minimal behavioral insight.

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 concise sentence that front-loads the core functionality. However, it sacrifices some informative detail for brevity.

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

Completeness2/5

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

With no output schema and only a brief description, the tool's behavior (e.g., return values, editing behavior) is underspecified. The agent lacks complete context to invoke it reliably.

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?

Schema coverage is 100%, so the input schema already describes all parameters. The description adds no extra meaning beyond hinting at Markdown content, which schema already specifies. Baseline 3 is appropriate.

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 creates or edits documentation pages with Markdown content, specifying the verb and resource. It distinguishes from sibling tools like docs_analyze_project and docs_generate_api which have different purposes.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like docs_generate_api or docs_build_static. The description does not mention context or exclusions.

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

docs_export_pdfB

Generate PDF from documentation using Puppeteer/Playwright

ParametersJSON Schema

Name	Required	Description
`docsPath`	Yes	Path to documentation or built site
`outputPath`	Yes	Output path for PDF file
`includePages`	No	Specific pages to include (optional, includes all by default)

TDQS

B3.1/5.0

Behavior2/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 mentions using Puppeteer/Playwright, implying headless browser rendering, but does not disclose whether it creates files locally or on a server, whether the operation is synchronous, or what happens if pages fail to load.

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?

Single sentence, no wasted words, but lacks structure (e.g., no bullet points or explicit separation of purpose vs. technical detail).

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

Completeness2/5

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

No output schema exists. The description does not explain default behavior for optional parameters (e.g., includePages defaults to all pages), output format details, or error scenarios. More completeness is needed for a tool that generates files.

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?

Schema description coverage is 100%, so the description adds no extra meaning beyond the schema. Baseline 3 is appropriate.

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 'Generate PDF from documentation using Puppeteer/Playwright' clearly states the action (Generate), the resource (PDF from documentation), and the technology (Puppeteer/Playwright), distinguishing it from siblings like docs_build_static or docs_preview.

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

Usage Guidelines2/5

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

No information is provided about when to use this tool versus alternatives (e.g., for final output vs. preview), nor are there any prerequisites or exclusions mentioned.

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

docs_generate_apiB

Generate API documentation from code (JSDoc, Docstrings, etc.)

ParametersJSON Schema

Name	Required	Description
`projectPath`	Yes	Path to the project source code
`outputPath`	Yes	Output path for API documentation
`language`	Yes	Programming language

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, and description does not disclose behavioral traits like read-only nature, side effects, or permissions. Minimal transparency.

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?

Single sentence that is concise, front-loaded, and provides essential information without extraneous text.

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

Completeness2/5

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

Description lacks information about output format, process, prerequisites, or edge cases. For a tool with no output schema and no annotations, the description is incomplete.

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?

Schema coverage is 100% with descriptions for each parameter. Description adds context about extracting from code comments, but does not enhance individual parameter understanding beyond schema.

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?

Clearly states it generates API documentation from code, with specific examples (JSDoc, Docstrings). Differentiates from siblings like docs_generate_openapi which focuses on OpenAPI specs.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as docs_generate_openapi or docs_build_static. Lacks explicit usage context.

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

docs_generate_openapiB

Generate OpenAPI 3.0 specification from analyzed PHP routes with middleware, parameters, and security schemes. Automatically converts controller routes to API documentation.

ParametersJSON Schema

Name	Required	Description	Default
`projectPath`	Yes	Path to the PHP project directory to analyze
`outputPath`	No	Output path for OpenAPI spec file (default: ./openapi.json)
`format`	No	Output format	json
`title`	No	API title (default: 'API Documentation')
`version`	No	API version (default: '1.0.0')
`serverUrl`	No	API server URL (e.g., 'https://api.example.com')

TDQS

B3.4/5.0

Behavior2/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 mentions generating specs and converting routes, but lacks details on side effects (e.g., file overwriting), error handling, or prerequisites beyond PHP routes.

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 that are front-loaded with the primary action and include relevant details. No unnecessary words.

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

Completeness2/5

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

The tool has no output schema and no annotations, yet the description omits return value, error conditions, and behavior for edge cases (e.g., non-PHP projects). This leaves agents underinformed.

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?

Input schema has 100% parameter descriptions, so the burden on the description is low. The description does not add extra meaning beyond the schema, which is acceptable but not exemplary.

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 OpenAPI 3.0 specifications from analyzed PHP routes, which is a specific verb and resource. It distinguishes itself from siblings like docs_generate_api by focusing on OpenAPI format and PHP routes.

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 usage for PHP projects with routes but does not provide explicit when-to-use or when-not-to-use guidance, nor does it contrast with sibling tools like docs_generate_api.

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

docs_generate_sales_docsA

Generate professional sales-ready documentation for CodeCanyon, ThemeForest, and other marketplaces. Creates comprehensive Markdown documentation (README, Installation, API Reference, Configuration, Examples, FAQ, Changelog) with optional PDF export.

ParametersJSON Schema

Name	Required	Description
`projectPath`	Yes	Path to the PHP project directory to analyze
`outputDir`	No	Output directory for documentation files (default: ./sales-docs)
`productName`	Yes	Product name for marketplace listing (e.g., 'Advanced User Management System')
`productVersion`	No	Product version (default: '1.0.0')
`author`	Yes	Author or company name (e.g., 'Your Company')
`description`	Yes	Product description for the README (e.g., 'A comprehensive user management system with advanced features...')
`price`	No	Product price (optional, e.g., '$49' or '€39')
`demoUrl`	No	Live demo URL (optional)
`supportEmail`	No	Support email address (optional)
`features`	No	List of key product features (e.g., ['User authentication', 'Role-based access', 'API support'])

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as whether it modifies existing files, reads project files, or requires specific permissions. It only mentions it 'creates' documentation and 'analyzes' the project.

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 only two sentences, front-loaded with the core purpose and key output details. No unnecessary words or repetition.

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?

Given 10 parameters and no output schema, the description lacks details on error behavior, output format (beyond Markdown/PDF), and prerequisites. Adequate but not complete for a complex doc generation tool.

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 input schema has 100% description coverage with clear parameter descriptions. The tool description adds no additional parameter semantics beyond stating the output includes Markdown sections. Baseline score of 3 is appropriate.

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 professional sales-ready documentation for specific marketplaces (CodeCanyon, ThemeForest) and lists the output sections (README, Installation, etc.), distinguishing it from siblings like docs_generate_api.

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 usage for marketplace sales docs but does not explicitly state when to use this tool versus alternatives like docs_generate_api or docs_generate_structure. No when-not-to-use guidance is provided.

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

docs_generate_structureB

Generate documentation scaffold/structure based on project analysis. Creates initial directory structure and configuration files.

ParametersJSON Schema

Name	Required	Description
`projectPath`	Yes	Path to the project directory
`framework`	Yes	Documentation framework to use
`template`	No	Template to use (for Docusaurus: classic, facebook, etc.)
`outputPath`	No	Output path for documentation (default: ./docs)

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, so description must carry full burden. Only says it 'creates' directories and config files, but does not disclose whether it overwrites existing files, requires permissions, or has side effects. For a file-creation tool, this is insufficient.

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?

Two sentences, front-loaded with purpose. Efficient and no wasted words, though could include a brief note on safety or output without becoming verbose.

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?

Adequate for a 4-param tool with 100% schema coverage and no output schema. Lacks mention of return values or confirmation, and does not clarify if it modifies project directory in place or writes to outputPath. Hints at prerequisite (project analysis) but not explicit.

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?

Schema description coverage is 100%, so baseline is 3. The description adds no further meaning beyond what schema already provides for each parameter (projectPath, framework, template, outputPath).

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?

Clearly states the tool generates documentation scaffold/structure, creates initial directory and config files. Distinct from sibling tools like docs_create_page (single page) or docs_build_static (builds).

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?

Mentions 'based on project analysis' implying a prerequisite, but does not explicitly state when to use this tool vs alternatives like docs_generate_api or docs_create_page. No exclusion criteria.

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

docs_previewB

Start local development server to preview documentation

ParametersJSON Schema

Name	Required	Description
`docsPath`	Yes	Path to documentation directory
`framework`	Yes	Documentation framework used
`port`	No	Port number (default: 3000 for Docusaurus, 8000 for MkDocs/Sphinx)

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It says 'start local development server' but does not disclose that the server may block the process, require manual stopping, or impact other tools. Missing side effects and lifecycle details.

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?

Single sentence with no redundancy. Front-loaded with verb and noun. Every word is meaningful.

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

Completeness2/5

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

Lacks critical behavioral context for a server-starting tool: no mention of how to stop the server, what URL is returned, or if it blocks. Output schema is absent, so description should compensate but does not.

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?

Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the parameter names and descriptions in the schema. Port defaults are already in schema description.

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 verb 'start', the resource 'local development server', and the purpose 'preview documentation'. It effectively distinguishes from sibling tools like docs_build_static (build) and docs_create_page (create).

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 usage during development for previewing, but does not explicitly state when to use this tool versus alternatives like docs_build_static. No when-not or alternative names are provided.

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. Dates show when Glama detected each change.

9 tool updatesv1.0.0Dec 12, 2025
- First observeddocs_analyze_project
- First observeddocs_build_static
- First observeddocs_create_page
- First observeddocs_export_pdf
- First observeddocs_generate_api
- First observeddocs_generate_openapi
- First observeddocs_generate_sales_docs
- First observeddocs_generate_structure
- First observeddocs_preview

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation4/5

Tools have distinct purposes, though docs_generate_api and docs_generate_openapi could be confused as both generate API documentation, but from different sources (code vs routes). The descriptions clarify the difference.

Naming Consistency5/5

All tools follow a consistent 'docs_verb_noun' pattern (e.g., docs_analyze_project, docs_build_static, docs_create_page). No mixed naming conventions.

Tool Count5/5

9 tools is well-scoped for a documentation server, covering analysis, generation, editing, building, exporting, and previewing without unnecessary bloat or deficiency.

Completeness5/5

The toolset provides a complete lifecycle: analyze project, generate structure, create/edit pages, generate API/OpenAPI/sales docs, build static site, export PDF, and preview. No obvious gaps.

Maintenance

ActivityNo data

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

docuwriter AOAuth
ai.docuwriter
Generate, search, and manage codebase documentation on DocuWriter.ai. 72 tools incl. Autopilot.
Developer Tools Documentation Access
3
llmref A
org.llmref
Versioned documentation registry and semantic search for AI tools and coding assistants.
Documentation Access Search Developer Tools
42
XRay-VisionOAuth
com.emtailabs
AI-powered codebase analysis — call graphs, security, dead code, complexity. 150+ tools.
Code Analysis Developer Tools Autonomous Agents
2
ArchGraphOAuth
dev.archgraph
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Code Analysis Software Architecture Developer Tools
2

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/ThaLoc0one/documentation-mcp-server'

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

📚 Documentation MCP Server

✨ Features

🛠️ Supported Frameworks

🚀 Quick Start

📦 Tools

docs_analyze_project

docs_generate_structure

docs_create_page

docs_generate_api

docs_build_static

docs_export_pdf

docs_preview

docs_generate_openapi

docs_generate_sales_docs 🎯 NEW!

🏗️ Architecture

🔬 Deep Analysis Pipeline

📝 License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Latest Blog Posts

MCP directory API

`docs_analyze_project`

`docs_generate_structure`

`docs_create_page`

`docs_generate_api`

`docs_build_static`

`docs_export_pdf`

`docs_preview`

`docs_generate_openapi`

`docs_generate_sales_docs` 🎯 NEW!