Skip to main content
Glama
ThaLoc0one

Documentation MCP Server

by ThaLoc0one

docs_generate_structure

Generate a documentation scaffold by analyzing your project. Creates the initial directory structure and configuration files for Docusaurus, MkDocs, or Sphinx frameworks.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectPathYesPath to the project directory
frameworkYesDocumentation framework to use
templateNoTemplate to use (for Docusaurus: classic, facebook, etc.)
outputPathNoOutput path for documentation (default: ./docs)

Implementation Reference

  • src/index.ts:57-83 (registration)
    Tool registration and schema definition for docs_generate_structure in the tools array
    {
      name: "docs_generate_structure",
      description: "Generate documentation scaffold/structure based on project analysis. Creates initial directory structure and configuration files.",
      inputSchema: {
        type: "object",
        properties: {
          projectPath: {
            type: "string",
            description: "Path to the project directory",
          },
          framework: {
            type: "string",
            description: "Documentation framework to use",
            enum: ["docusaurus", "mkdocs", "sphinx"],
          },
          template: {
            type: "string",
            description: "Template to use (for Docusaurus: classic, facebook, etc.)",
          },
          outputPath: {
            type: "string",
            description: "Output path for documentation (default: ./docs)",
          },
        },
        required: ["projectPath", "framework"],
      },
    },
  • src/index.ts:302-303 (registration)
    Handler dispatch case mapping docs_generate_structure to generateStructure function
    case "docs_generate_structure":
      return await generateStructure(args);
  • Main handler function that dispatches to framework-specific generators (Docusaurus, MkDocs, Sphinx)
    export async function generateStructure(args: any) {
      const { projectPath, framework, template, outputPath = "docs" } = args as GenerateStructureArgs;
    
      try {
        const fullOutputPath = path.resolve(projectPath, outputPath);
    
        switch (framework) {
          case "docusaurus":
            return await generateDocusaurus(projectPath, fullOutputPath, template);
          case "mkdocs":
            return await generateMkDocs(projectPath, fullOutputPath);
          case "sphinx":
            return await generateSphinx(projectPath, fullOutputPath);
          default:
            throw new Error(`Unsupported framework: ${framework}`);
        }
      } catch (error) {
        throw new Error(`Failed to generate structure: ${error}`);
      }
    }
  • TypeScript interface for the tool's input arguments, matching the inputSchema in registration
    interface GenerateStructureArgs {
      projectPath: string;
      framework: "docusaurus" | "mkdocs" | "sphinx";
      template?: string;
      outputPath?: string;
    }
  • Helper generating Docusaurus setup instructions and returning them as text content
    async function generateDocusaurus(projectPath: string, outputPath: string, template?: string) {
      const availableTemplates = [
        "classic",
        "facebook",
        "meta",
      ];
    
      const selectedTemplate = template && availableTemplates.includes(template) ? template : "classic";
    
      const message = `📦 Docusaurus Setup Instructions:
    
    1. Install Docusaurus:
       cd ${projectPath}
       npx create-docusaurus@latest ${path.basename(outputPath)} ${selectedTemplate} --typescript
    
    2. Available templates:
       ${availableTemplates.map(t => `- ${t}`).join("\n   ")}
    
    3. Start the development server:
       cd ${path.basename(outputPath)}
       npm start
    
    4. Build for production:
       npm run build
    
    The static files will be in the 'build' directory, ready for hosting!`;
    
      return {
        content: [
          {
            type: "text",
            text: message,
          },
        ],
      };
    }
  • Helper generating MkDocs setup instructions with mkdocs.yml config and structure
    async function generateMkDocs(projectPath: string, outputPath: string) {
      const configContent = `site_name: My Documentation
    site_url: https://example.com
    theme:
      name: material
      features:
        - navigation.tabs
        - navigation.sections
        - toc.integrate
        - search.suggest
        - search.highlight
      palette:
        - scheme: default
          primary: indigo
          accent: indigo
          toggle:
            icon: material/brightness-7
            name: Switch to dark mode
        - scheme: slate
          primary: indigo
          accent: indigo
          toggle:
            icon: material/brightness-4
            name: Switch to light mode
    
    nav:
      - Home: index.md
      - Getting Started: getting-started.md
      - API Reference: api/index.md
    
    markdown_extensions:
      - pymdownx.highlight
      - pymdownx.superfences
      - pymdownx.tabbed
      - admonition
      - codehilite`;
    
      const message = `📦 MkDocs Setup Instructions:
    
    1. Install MkDocs with Material theme:
       pip install mkdocs mkdocs-material
    
    2. Create the following structure in '${outputPath}':
       
       ${outputPath}/
       ├── mkdocs.yml
       └── docs/
           ├── index.md
           ├── getting-started.md
           └── api/
               └── index.md
    
    3. Configuration file (mkdocs.yml):
    ${configContent}
    
    4. Start the development server:
       cd ${projectPath}
       mkdocs serve
    
    5. Build for production:
       mkdocs build
    
    The static files will be in the 'site' directory!`;
    
      return {
        content: [
          {
            type: "text",
            text: message,
          },
        ],
      };
    }
  • Helper generating Sphinx setup instructions
    async function generateSphinx(projectPath: string, outputPath: string) {
      const message = `📦 Sphinx Setup Instructions:
    
    1. Install Sphinx:
       pip install sphinx sphinx-rtd-theme
    
    2. Initialize Sphinx:
       cd ${projectPath}
       sphinx-quickstart ${path.basename(outputPath)}
    
    3. Edit conf.py to use the Read the Docs theme:
       html_theme = 'sphinx_rtd_theme'
    
    4. Build documentation:
       cd ${path.basename(outputPath)}
       make html
    
    5. The HTML output will be in '_build/html'
    
    For API documentation from Python code:
       pip install sphinx-autodoc`;
    
      return {
        content: [
          {
            type: "text",
            text: message,
          },
        ],
      };
    }
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.

Install Server

Other Tools

Latest Blog Posts

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