Which integrations are available for this server?

Analyzes CodeIgniter 3/4 projects to detect controllers, models, MVC patterns, routes, and middleware for documentation generation. Generates React-based documentation structures, creates pages, builds static sites, and provides live preview for Docusaurus projects. Performs AST-based deep code analysis using TypeScript Compiler API to extract classes, functions, interfaces, JSDoc comments, and module dependencies from JavaScript projects. Analyzes Laravel projects to detect Illuminate components, attributes-based routes, middleware, and framework-specific patterns for documentation generation. Creates and edits Markdown-based documentation pages with support for multiple documentation frameworks. Performs AST-based analysis of PHP 8+ projects using nikic/php-parser to extract namespaces, classes, methods, enums, traits, attributes, PHPDoc comments, routes, and middleware with framework detection. Performs native AST-based code analysis to extract classes, functions, docstrings, and module dependencies from Python projects for documentation generation. Supports documentation generation using React-based Docusaurus framework with various templates. Generates Python-based documentation structures, creates pages, builds static sites, and provides live preview for Sphinx projects. Auto-generates OpenAPI 3.0/Swagger specifications from PHP code by converting routes to paths, middleware to security schemes, with JSON and YAML format support. Analyzes Symfony projects to detect Symfony components, attribute-based routes, IsGranted middleware, and framework-specific patterns for documentation generation. Performs AST-based deep code analysis using TypeScript Compiler API to extract classes, interfaces, functions, type aliases, JSDoc comments, and module dependencies from TypeScript projects.

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 Docusaurus" 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 LiL-Loco

Overview Schema Related Servers Score Discussions

TypeScript

Local

📚 Documentation MCP Server

Ein Model Context Protocol (MCP) Server zum Generieren professioneller Dokumentationen mit Unterstützung für mehrere Frameworks.

✨ Features

🔍 Deep Code Analysis - AST-basierte Multi-Language Analysis
- TypeScript/JavaScript: TypeScript Compiler API
- Python: Native Python AST module
- Go: Go parser & AST
- PHP: Regex-basierte Analyse + PHP 8+ Features
- Extrahiert Klassen, Funktionen, Interfaces, Methoden, Properties
- PHP 8+: Enums, Traits, Attributes
- Erfasst JSDoc/Docstrings/Go Doc/PHPDoc und berechnet Dokumentations-Coverage
- Analysiert Imports/Exports und Module-Dependencies
🌍 Multi-Language Projects - Automatische Erkennung und parallele Analyse mehrerer Sprachen
📊 Projekt-Analyse - Automatische Code-Analyse für TypeScript, JavaScript, Python, Go, PHP
🏗️ Struktur-Generierung - Erstellt komplette Dokumentations-Gerüste
✍️ Seiten-Editor - Erstellt und bearbeitet einzelne Dokumentationsseiten
📖 API-Dokumentation - Generiert API-Docs aus Code-Kommentaren
🌐 Static Site Builder - Baut statische Websites für Hosting
📄 PDF-Export - Konvertiert Dokumentation zu PDF
👀 Live-Preview - Lokaler Entwicklungsserver

🛠️ Unterstützte Frameworks

Docusaurus (React-basiert, modern, verschiedene Templates)
MkDocs (Python-basiert, Markdown-fokussiert, einfach)
Sphinx (Python, sehr mächtig, für komplexe Projekte)

🚀 Quick Start

Verzeichnisse erstellen:
```
mkdir src
mkdir src\tools
```
Dependencies installieren:
```
npm install
```
Build:
```
npm run build
```
MCP Server in Claude Desktop konfigurieren (siehe SETUP.md)

📦 Tools

`docs_analyze_project`

Analysiert Projekt-Struktur und führt Deep Code Analysis durch.

Parameter:

projectPath (string, required) - Pfad zum Projekt
language (enum, optional) - Programmiersprache (typescript, javascript, python, go, rust, java, csharp)
deep (boolean, optional, default: true) - Aktiviert Deep Code Analysis

Deep Analysis Features:

📦 Extrahiert Classes/Structs, Interfaces, Functions, Enums, Type Aliases
🔍 Erfasst Methods, Properties, Constructors mit vollständigen Details
📝 Analysiert JSDoc/Docstrings/Go Doc und berechnet Documentation Coverage
🔗 Trackt Imports/Exports und Module Dependencies
📊 Generiert Zusammenfassungs-Statistiken
🎯 Multi-Language Support:
- ✅ TypeScript/JavaScript (TypeScript Compiler API)
- ✅ Python (Native Python AST)
- ✅ Go (go/parser & go/ast)
- ✅ PHP v2 (nikic/php-parser AST) - Neu! 100% genau
  - 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
- 🌍 Automatische Multi-Language-Erkennung
- 🔜 Rust, Java, C# (in Planung)

Beispiel-Rückgabe:

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

`docs_generate_structure`

Generiert Dokumentations-Gerüst.

Parameter:

projectPath (string, required) - Pfad zum Projekt
framework (enum, required) - docusaurus | mkdocs | sphinx
template (string, optional) - Template-Name
outputPath (string, optional) - Ausgabepfad (default: ./docs)

`docs_create_page`

Erstellt oder bearbeitet Dokumentationsseite.

Parameter:

docsPath (string, required) - Pfad zur Doku
pagePath (string, required) - Relativer Pfad zur Seite
title (string, required) - Seitentitel
content (string, required) - Markdown-Inhalt

`docs_generate_api`

Generiert API-Dokumentation aus Code.

Parameter:

projectPath (string, required) - Pfad zum Quellcode
outputPath (string, required) - Ausgabepfad
language (enum, required) - Programmiersprache

`docs_build_static`

Baut statische Website.

Parameter:

docsPath (string, required) - Pfad zur Doku
framework (enum, required) - Framework
outputPath (string, optional) - Ausgabepfad (default: ./build)

`docs_export_pdf`

Exportiert Dokumentation als PDF.

Parameter:

docsPath (string, required) - Pfad zur Doku
outputPath (string, required) - PDF-Ausgabepfad
includePages (array, optional) - Spezifische Seiten

`docs_preview`

Startet lokalen Dev-Server.

Parameter:

docsPath (string, required) - Pfad zur Doku
framework (enum, required) - Framework
port (number, optional) - Port (default: 3000/8000)

`docs_generate_openapi`

Generiert OpenAPI 3.0 Spezifikation aus PHP-Code.

Parameter:

projectPath (string, required) - PHP-Projekt Pfad
outputPath (string, optional) - Ausgabepfad (default: ./openapi.json)
format (enum, optional) - json | yaml (default: json)
title (string, optional) - API-Titel
version (string, optional) - API-Version
serverUrl (string, optional) - API Server URL

`docs_generate_sales_docs` 🎯 NEU!

Generiert professionelle, verkaufsfertige Dokumentation für CodeCanyon, ThemeForest, etc.

Parameter:

projectPath (string, required) - PHP-Projekt Pfad
outputDir (string, optional) - Ausgabe-Verzeichnis (default: ./sales-docs)
productName (string, required) - Produktname
productVersion (string, optional) - Version (default: 1.0.0)
author (string, required) - Autor/Firma
description (string, required) - Produktbeschreibung
price (string, optional) - Preis (z.B., "$49")
demoUrl (string, optional) - Live-Demo URL
supportEmail (string, optional) - Support E-Mail
features (array, optional) - Liste der Key Features

Generierte Dateien:

README.md (2.5 KB) - Produkt-Übersicht mit Features, Statistiken, Requirements
INSTALLATION.md (3.2 KB) - Schritt-für-Schritt Setup-Guide
API_REFERENCE.md (24.2 KB) - Komplette API-Dokumentation
CONFIGURATION.md (2.1 KB) - Umgebungsvariablen, Security
EXAMPLES.md (4.0 KB) - Code-Beispiele (JS, PHP, Python)
FAQ.md (2.2 KB) - Häufig gestellte Fragen
CHANGELOG.md (0.9 KB) - Versionshistorie
COMPLETE_DOCUMENTATION.md (39.0 KB) - All-in-One für PDF

Gesamt: ~78 KB professionelle Dokumentation!

🏗️ Architektur

src/
├── index.ts                    # MCP Server Hauptdatei
├── core/                       # Kern-Module für Deep Analysis
│   ├── types.ts               # Type-Definitionen für alle Sprachen
│   └── analyzer.ts            # Abstract Base Class & Factory
├── analyzers/                  # Sprachspezifische Analyzer
│   ├── 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-Implementierungen
    ├── analyzeProject.ts      # Deep Analysis Integration
    ├── generateStructure.ts
    ├── createPage.ts
    ├── generateApi.ts
    ├── buildStatic.ts
    ├── exportPdf.ts
    └── preview.ts

🔬 Deep Analysis Pipeline

File Scanning - Durchsucht Projekt-Verzeichnis
Language Detection - Erkennt dominante Programmiersprache
Analyzer Selection - Wählt passenden AST-Parser (Factory Pattern)
AST Parsing - Parst Code-Dateien mit sprachspezifischem Parser
- TypeScript: TS Compiler API (in-process)
- Python: Python AST module (subprocess)
- Go: go/parser & go/ast (subprocess)
Symbol Extraction - Extrahiert alle Code-Symbole (Classes, Functions, etc.)
Documentation Analysis - Erfasst Dokumentations-Kommentare
Summary Generation - Berechnet Statistiken und Coverage

📝 Lizenz

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
`deep`	No	Enable deep code analysis using language-specific AST parsers (default: true)
`language`	No	Primary programming language (typescript, javascript, python, go, etc.)
`projectPath`	Yes	Path to the project directory to analyze

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
`title`	Yes	Page title
`content`	Yes	Markdown content for the page
`docsPath`	Yes	Path to documentation directory
`pagePath`	Yes	Relative path for the page (e.g., 'guides/getting-started.md')

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
`language`	Yes	Programming language
`outputPath`	Yes	Output path for API documentation
`projectPath`	Yes	Path to the project source code

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
`title`	No	API title (default: 'API Documentation')
`format`	No	Output format	json
`version`	No	API version (default: '1.0.0')
`serverUrl`	No	API server URL (e.g., 'https://api.example.com')
`outputPath`	No	Output path for OpenAPI spec file (default: ./openapi.json)
`projectPath`	Yes	Path to the PHP project directory to analyze

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

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
`template`	No	Template to use (for Docusaurus: classic, facebook, etc.)
`framework`	Yes	Documentation framework to use
`outputPath`	No	Output path for documentation (default: ./docs)
`projectPath`	Yes	Path to the project directory

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
`port`	No	Port number (default: 3000 for Docusaurus, 8000 for MkDocs/Sphinx)
`docsPath`	Yes	Path to documentation directory
`framework`	Yes	Documentation framework used

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

9 tool updatesDec 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.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: analysis, building static site, creating/editing pages, PDF export, API doc generation (two types), sales doc generation, structure scaffolding, and preview. No overlap that would confuse an agent.

Naming Consistency5/5

All tools use the consistent 'docs_' prefix and follow a verb_noun pattern in snake_case (e.g., docs_analyze_project, docs_generate_api). No mixing of conventions.

Tool Count5/5

9 tools is well-scoped for a documentation server. It covers the full workflow from analysis to generation, editing, preview, and export without being excessive.

Completeness4/5

The set covers core documentation tasks, but missing tools for listing/deleting pages or managing versions. Minor gap, but overall surface is solid.

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
ArchGraphOAuth
dev.archgraph
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Code Analysis Software Architecture Developer Tools
2
XRay-VisionOAuth
com.emtailabs
AI-powered codebase analysis — call graphs, security, dead code, complexity. 150+ tools.
Code Analysis Developer Tools Autonomous Agents
2

Appeared in Searches

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

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

📚 Documentation MCP Server

✨ Features

🛠️ Unterstützte 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 🎯 NEU!

🏗️ Architektur

🔬 Deep Analysis Pipeline

📝 Lizenz

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Appeared in Searches

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