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 "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@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 Source Related Servers Discussions Admin

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_projectA

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

A3.9/5.0

Behavior4/5

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

Discloses deep code analysis using AST parsers and extraction of classes, functions, interfaces, etc. Lacks explicit statement that it is read-only, but no annotations are provided, so description carries full burden.

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 concise sentences that front-load the purpose and follow with capabilities. No redundant or filler content.

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?

Describes inputs and high-level output (extracted elements), but lacks description of return format or how results are presented. Without an output schema, more detail on output would improve completeness.

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 all three parameters. Description adds context about extracted elements (classes, functions, etc.) but does not significantly elaborate on parameter behavior 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 analyzes project structure and code for documentation generation, listing supported languages and extraction capabilities. Distinguishes well from sibling tools like docs_generate_api or docs_build_static.

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?

Implied usage from context ('for documentation generation'), but no explicit when-to-use vs. alternatives. Does not mention when not to use or prerequisites.

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

docs_build_staticA

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

A3.5/5.0

Behavior2/5

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

Without annotations, the description is the sole source of behavioral insight. It states only the basic function ('Build static website') and common hosting targets. It does not disclose side effects (e.g., file overwrites, output directory creation), required permissions, or execution steps (e.g., running a build command). This is insufficient for an agent to understand operational implications.

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, front-loaded sentence that conveys the core purpose without superfluous words. Every word contributes to clarity, making it efficient for an agent to parse.

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 the tool has 3 parameters, no output schema, and no annotations, the description is minimal. It explains the tool's purpose but omits details about the build process (e.g., does it return a status or file path?), output structure, or interaction with the file system. While adequate for a simple tool, it leaves gaps in an agent's understanding for reliable invocation.

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 baseline is 3. The description adds no parameter-specific information, but the schema already provides adequate descriptions for all three parameters (docsPath, framework, outputPath), including an enum for framework. Thus, the description neither harms nor significantly aids parameter understanding.

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 static website for online hosting'. It specifies the action (Build), resource (static website), and target (GitHub Pages, Netlify, Vercel). This distinguishes it from sibling tools like docs_export_pdf (PDF export) and docs_preview (local preview), making the tool's role in the documentation workflow unambiguous.

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 ('ready for GitHub Pages...') but does not explicitly guide when to use this tool over alternatives like docs_preview for local testing or docs_export_pdf for static file export. There is no when-not or comparison to siblings, leaving room for ambiguity in an agent's decision.

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?

No annotations are provided, so the description carries full burden. It only states 'create or edit' without clarifying whether it overwrites, upserts, or requires prerequisites. No side effects or permissions are disclosed.

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 sentence with ten words, front-loading the key action. It is concise but could benefit from slightly more detail without becoming verbose.

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 no output schema, no annotations, and the tool being a mutation (create/edit), the description lacks return value information, error handling clues, and clarification of the create-vs-edit behavior. It is incomplete for an agent to use confidently.

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 schema already describes all four parameters. The description adds the term 'Markdown' which is redundant with the content parameter description, and 'individual' may help but doesn't add semantic depth. Baseline score 3 is appropriate.

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

Purpose4/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. It distinguishes from sibling tools like docs_generate_api or docs_export_pdf by specifying 'individual pages', though it doesn't explicitly name alternatives.

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 manual page creation/editing, contrasting with automatic generation tools. However, it lacks explicit when-to-use or when-not-to-use guidance, and no alternatives are mentioned.

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

Behavior3/5

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

Mentions Puppeteer/Playwright, giving some behavioral context, but lacks disclosure on permissions, performance, or side effects. No annotations to supplement.

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, efficient, but somewhat generic and not front-loaded with critical decision-making information.

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; description fails to explain return behavior, error cases, or constraints beyond schema properties. Incomplete for a PDF 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?

Schema descriptions cover all parameters (100%), so description adds no marginal value beyond what is already provided.

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

Purpose4/5

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

Clearly states action and resource, but fails to differentiate from sibling tools like docs_analyze_project or 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 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, no 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_apiC

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

C2.9/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 clarify behavioral traits like whether the tool modifies project files, requires specific permissions, or produces a specific output format. The mention of 'from code' implies a read-only analysis but the outputPath parameter suggests writing, which is not explained.

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 purpose. It avoids unnecessary words, but could include a bit more detail without harming conciseness.

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 three required parameters, no output schema, and no annotations, the description is insufficiently complete. It does not explain what format the documentation is generated in (e.g., HTML, Markdown), where it is written, or how to interpret the output. The agent would lack enough information to use the tool correctly without external knowledge.

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 for all three required parameters, each with a clear purpose. The description adds no additional meaning beyond what the schema already provides, achieving the baseline score.

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

Purpose4/5

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

The description clearly states the tool generates API documentation from code comments like JSDoc or Docstrings, using a specific verb 'generate' and resource 'API documentation'. However, it does not differentiate from the sibling tool docs_generate_openapi, which also generates API documentation but specifically for OpenAPI.

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?

The description provides no guidance on when to use this tool versus alternatives such as docs_generate_openapi or docs_analyze_project. It lacks context about prerequisites, when not to use, or typical use cases.

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

docs_generate_openapiA

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

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It mentions generation and conversion, which implies a write operation, but does not disclose side effects (e.g., overwriting output files) or permissions needed. The purpose is clear but behavioral details are lacking.

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 main purpose, and contains no redundant information. Every word adds 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 absence of an output schema, the description explains the output (OpenAPI 3.0 specification) and what it includes (routes, middleware, parameters, security schemes). It is sufficiently complete for a 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?

Schema description coverage is 100%, so the schema already documents all parameters adequately. The tool description adds no extra parameter-level information beyond the schema, so baseline 3 applies.

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 'Generate' and the resource 'OpenAPI 3.0 specification from analyzed PHP routes'. It differentiates itself from siblings by specifying the input type (PHP routes) and including details like middleware, parameters, and security schemes.

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 generating OpenAPI specs from PHP routes, but does not explicitly state when to use this tool versus alternatives like docs_generate_api or docs_export_pdf. No when-not-to-use or comparative 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_sales_docsB

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

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that it creates Markdown files and optionally exports PDF, and lists the sections. However, it does not clarify whether it modifies existing files, requires specific permissions, or if analyzing the project path is read-only. This is adequate but lacks deeper 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.

Conciseness4/5

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

The description consists of two concise, front-loaded sentences. The first captures the main purpose, the second details the output. It is efficient though could be slightly more structured (e.g., bullet points) for clarity.

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 the complexity (10 parameters, no output schema), the description covers the core functionality but omits details about return values, failure cases, or prerequisites (e.g., that the project must be PHP). It is adequate for a basic understanding but not fully complete.

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 baseline is 3. The description does not add extra meaning beyond what the schema already provides for each parameter. It lists the generated sections but does not link them to specific parameters.

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: generating professional sales-ready documentation for specific marketplaces like CodeCanyon and ThemeForest. It lists the sections created (README, Installation, etc.), distinguishing it from sibling tools like docs_generate_api or docs_generate_structure.

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?

The description does not provide any guidance on when to use this tool versus its siblings. It mentions marketplaces but does not explain that this is for sales documentation while other tools are for API docs or general project analysis. No alternatives or exclusions are mentioned.

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.2/5.0

Behavior2/5

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

No annotations are present, so the description must fully convey behavior. It mentions 'based on project analysis' but does not clarify whether the tool performs analysis internally or relies on prior steps. Side effects like file overwriting are not disclosed.

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, direct and to the point. No extraneous information. Every word serves the description.

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 9 sibling tools, the description is too brief. It does not explain what 'project analysis' means, what the output looks like, or how it integrates with other tools. No output schema requires more context about return values.

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 to the parameters beyond what the schema already provides.

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 does not provide any guidance on when to use this tool versus alternatives like docs_analyze_project or docs_build_static. No explicit 'when-to-use' or 'when-not-to-use' information is included.

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 usage guidelines are provided. The description lacks information on when to choose this tool over siblings such as docs_analyze_project (for analysis) or docs_build_static (for building).

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.2/5.0

Behavior2/5

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

No annotations provided. The description lacks behavioral details: e.g., if the server blocks, how to stop it, or what output is produced. Only states it starts a server.

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?

A single, clear sentence. Efficient but could benefit from additional structured detail (e.g., output behavior).

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?

No output schema, but the tool is simple. Still, the description doesn't mention what the result is (e.g., URL, server status). Adequate but not complete.

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 description adds no extra meaning beyond the schema. 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 action ('start local development server') and the resource ('documentation preview'). It distinguishes from siblings like docs_build_static and docs_generate_*.

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 vs alternatives (e.g., when to preview vs build). No exclusions or prerequisites mentioned.

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.

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

Deploy Server

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

TDQS

A3.7/5.0

Scored 2026-05-01 03:40 across 9 tools

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

Related MCP Connectors

docuwriter AOAuth
ai.docuwriter
Generate, search, and manage codebase documentation on DocuWriter.ai. 72 tools incl. Autopilot.
AI & Machine Learning Developer Tools Documentation Access
723
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

📚 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

Related MCP Connectors

`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!