Skip to main content
Glama
mfaizanmumtaz

Engineering Documentation MCP Server

by mfaizanmumtaz
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Engineering Documentation MCP Server

Turn any software repository into professional engineering documentation — automatically.

A production-ready Model Context Protocol (MCP) server that analyzes code repositories and publishes comprehensive documentation directly to Google Docs. Works with Claude Code, Cursor, and any MCP-compatible AI assistant.

What It Does

Say this to your AI assistant:

"Document this project."

The server will:

  1. Analyze the repository — languages, frameworks, API routes, DB models, env vars, CI/CD, dependencies

  2. Generate 13 documentation sections with Mermaid architecture diagrams

  3. Publish a formatted Google Doc and return the URL

  4. Export to Markdown, HTML, or PDF (optional)

Related MCP server: Documentation MCP Server

Features

Feature

Details

Language Detection

Python, JavaScript, TypeScript, Go, Rust, Java, C#, Ruby, PHP, and more

Framework Recognition

FastAPI, Django, Flask, Next.js, Express, NestJS, React, LangChain, LangGraph, and more

API Extraction

FastAPI, Flask, Django URLs, Express, Next.js App Router & Pages Router

Database Parsing

SQLAlchemy, Django ORM, Prisma, TypeORM, Mongoose

Architecture Diagrams

Mermaid flowcharts + ER diagrams

Google Docs

Create, update, share with professional formatting

Export Formats

Markdown, HTML (with Mermaid), PDF

CI/CD Detection

GitHub Actions, GitLab CI, CircleCI, Jenkins, Azure DevOps

12 MCP Tools

Full tool suite exposed to AI assistants

Quick Start

1. Clone & Install

git clone https://github.com/your-org/engineering-docs-mcp.git
cd engineering-docs-mcp

# Using uv (recommended)
pip install uv
uv sync

# Or using pip
python -m venv .venv
source .venv/bin/activate  # Windows: .venv\Scripts\activate
pip install -e ".[dev]"

2. Set Up Google OAuth

Note (2026 UI): Google renamed "OAuth consent screen" to Google Auth Platform and reorganized it into tabs: Branding, Audience, Data Access, and Clients. The steps below reflect the current UI.

Step 1 — Create a Google Cloud Project

  1. Go to Google Cloud Console

  2. Click the project dropdown (top-left) → New Project

  3. Give it a name (e.g. Engineering Docs MCP) → Create

Step 2 — Enable the Required APIs

  1. Go to APIs & Services → Library

  2. Search "Google Docs API" → click it → Enable

  3. Search "Google Drive API" → click it → Enable

Step 3 — Configure Google Auth Platform

  1. Go to APIs & Services → Google Auth Platform

  2. If you see a "Get Started" button, click it — this launches the setup wizard:

    Wizard — App Information

    Field

    Value

    App name

    Engineering Docs MCP

    User support email

    Your Gmail address

    Click Next

    Wizard — Audience

    • Select External (works with any Gmail; choose Internal only for Google Workspace orgs)

    • Click Next

    ⚠️ You cannot change External → Internal later without creating a new project.

    Wizard — Contact Information

    • Enter your email for Google notifications

    • Click Next → Create

Step 4 — Add Scopes (Data Access Tab)

  1. Click the Data Access tab

  2. Click Add or Remove Scopes

  3. In the filter/search box:

    • Search Google Docs → check /auth/documents

    • Search Google Drive → check /auth/drive

  4. Click Update → Save

Step 5 — Add Test Users (Audience Tab)

  1. Click the Audience tab

  2. Scroll down to Test users → click + Add Users

  3. Enter your Gmail address → Add → Save

While in Testing mode only listed emails can authenticate. You never need to publish the app for personal/dev use.

Step 6 — Create OAuth Credentials (Clients Tab)

  1. Click the Clients tab

  2. Click + Create Client

  3. Application type: Desktop app

  4. Name: Engineering Docs MCP → Create

  5. In the dialog that appears, click Download JSON

  6. Rename the downloaded file to credentials.json

  7. Place it in the project root:

documentation_mcp/
├── credentials.json   ← here
├── server.py
└── ...

Quick Reference — Old vs New UI

Old UI

New UI (2026)

OAuth consent screen

Google Auth Platform

App information page

Branding tab

Scopes page

Data Access tab

Test users page

Audience tab

Credentials page

Clients tab

3. Configure Environment

cp .env.example .env
# Edit .env if needed — defaults work for most setups

4. Run the Server

python server.py

On first run, a browser window will open for Google OAuth authentication. After authorizing, a token.json is saved for subsequent runs.

Connecting to Claude Code

Add the server to your Claude Code MCP configuration:

# Edit ~/.claude/claude_desktop_config.json (Mac/Linux)
# or %APPDATA%\Claude\claude_desktop_config.json (Windows)
{
  "mcpServers": {
    "engineering-docs-mcp": {
      "command": "python",
      "args": ["/absolute/path/to/engineering-docs-mcp/server.py"],
      "env": {
        "GOOGLE_CREDENTIALS_FILE": "/absolute/path/to/credentials.json"
      }
    }
  }
}

Or using uv:

{
  "mcpServers": {
    "engineering-docs-mcp": {
      "command": "uv",
      "args": [
        "--directory", "/absolute/path/to/engineering-docs-mcp",
        "run", "python", "server.py"
      ]
    }
  }
}

Restart Claude Code to load the server.

Connecting to Cursor

Add to Cursor's MCP settings (~/.cursor/mcp.json):

{
  "mcpServers": {
    "engineering-docs-mcp": {
      "command": "python",
      "args": ["/absolute/path/to/engineering-docs-mcp/server.py"]
    }
  }
}

Example Prompts

Once connected, use natural language:

Document this project.
Analyze /path/to/my-api and create a Google Doc. Share it with team@example.com.
Generate API documentation for the repository at /home/user/projects/my-service.
Export the documentation for /path/to/repo as Markdown.
Show me the database schema for /path/to/project.
Generate a README for /path/to/my-project.
Update Google Doc abc123 with the latest docs for /path/to/repo.

Available MCP Tools

Tool

Description

analyze_repository

Analyze a repo and return structured metadata

generate_project_documentation

Full pipeline: analyze → generate → publish to Google Docs

create_google_doc

Create a formatted Google Doc from analysis

update_google_doc

Update an existing Google Doc by ID

document_api

Extract and document all API endpoints

document_database

Extract and document all database models

generate_readme

Generate a professional README.md

generate_architecture

Generate architecture docs with Mermaid diagrams

export_markdown

Export documentation as Markdown

export_html

Export documentation as styled HTML

export_pdf

Export documentation as PDF (requires weasyprint)

share_google_doc

Share a Google Doc with email addresses

Generated Documentation Sections

Every generated document includes:

  1. Executive Summary — What the project does in plain language

  2. Project Overview — Purpose, features, stats, contributors

  3. Technology Stack — Languages, frameworks, databases, infrastructure

  4. Folder Structure — Annotated directory tree

  5. Architecture — Patterns, request flow, Mermaid flowchart

  6. API Documentation — All endpoints with methods, auth, handlers

  7. Database Documentation — Models, fields, relationships, ER diagram

  8. Environment Variables — All env vars with descriptions and examples

  9. Installation Guide — Step-by-step setup instructions

  10. Deployment — Docker, Kubernetes, CI/CD instructions

  11. Dependencies — Production and dev dependencies with purposes

  12. Security Notes — Auth, secrets, recommendations

  13. Future Improvements — Suggested enhancements based on analysis

Docker

# Copy environment file
cp .env.example .env

# Build and run
docker compose up -d

# View logs
docker compose logs -f mcp-server

The Docker setup mounts:

  • ./credentials.json — Google OAuth credentials (read-only)

  • ./token.json — OAuth token (persisted across restarts)

  • ./output/ — Generated export files

  • ${REPOS_ROOT:-/repos} — Host directory for repository access

Development

# Install dev dependencies
uv sync

# Run tests
pytest

# Run with coverage
pytest --cov=. --cov-report=html

# Lint
ruff check .
ruff format .

# Type check
mypy .

Project Structure

engineering-docs-mcp/
│
├── server.py                 # FastMCP server with 12 tools
│
├── analyzers/                # Repository analysis engines
│   ├── orchestrator.py       # Runs all analyzers in sequence
│   ├── structure.py          # File/folder structure + language detection
│   ├── framework.py          # Framework, CI/CD, auth, deployment detection
│   ├── api.py                # API endpoint extraction
│   ├── database.py           # ORM model extraction
│   ├── environment.py        # Environment variable extraction
│   ├── dependencies.py       # Dependency manifest parsing
│   └── git_info.py           # Git metadata
│
├── generators/               # Documentation section generators
│   ├── orchestrator.py       # Assembles complete documentation
│   ├── overview.py           # Executive summary + project overview
│   ├── tech_stack.py         # Technology stack + architecture + Mermaid diagrams
│   ├── structure.py          # Folder structure section
│   ├── api_docs.py           # API documentation tables
│   ├── database_docs.py      # Database documentation tables
│   ├── env_docs.py           # Environment variables table
│   ├── installation.py       # Installation guide + deployment
│   ├── security.py           # Security notes + future improvements
│   └── dependencies_docs.py  # Dependencies tables
│
├── google_docs/              # Google Docs integration
│   ├── auth.py               # OAuth 2.0 authentication
│   ├── client.py             # Create, update, share documents
│   └── formatter.py          # batchUpdate request builder
│
├── services/
│   ├── documentation.py      # High-level pipeline orchestrator
│   └── export.py             # Markdown / HTML / PDF export
│
├── models/
│   ├── analysis.py           # Pydantic models for repository analysis
│   └── documentation.py      # Pydantic models for documentation
│
├── config/
│   └── settings.py           # Pydantic Settings configuration
│
├── tests/                    # pytest test suite
│
├── Dockerfile
├── docker-compose.yml
├── pyproject.toml
└── .env.example

Supported Frameworks

Language

Frameworks

Python

FastAPI, Django, Flask, LangChain, LangGraph, Celery, SQLAlchemy, Alembic

JavaScript / TypeScript

Next.js, React, Express, NestJS, Nuxt.js, Vue, Angular, Fastify, Hono

Testing

pytest, Jest, Vitest

Infrastructure

Docker, Kubernetes, Terraform

Environment Variables

Variable

Default

Description

GOOGLE_CREDENTIALS_FILE

credentials.json

Path to Google OAuth credentials

GOOGLE_TOKEN_FILE

token.json

Path to cached OAuth token

DEFAULT_OUTPUT_FORMAT

google_docs

Default output: google_docs, markdown, html, pdf

DEFAULT_DOC_TITLE

Engineering Documentation

Default document title

OUTPUT_DIR

output

Directory for exported files

LOG_LEVEL

INFO

Log verbosity: DEBUG, INFO, WARNING, ERROR

MAX_FILE_SIZE_KB

500

Maximum file size to parse (KB)

MAX_FILES_TO_ANALYZE

2000

Maximum files to include in analysis

Extending the Server

Adding a New Framework Detector

Edit analyzers/framework.py and add entries to FRAMEWORK_SIGNATURES:

Framework.MY_FRAMEWORK: [
    ("*.py", "from my_framework import"),
    ("requirements*.txt", "my-framework"),
],

Add the framework to the Framework enum in models/analysis.py.

Adding a New Documentation Section

  1. Create a generator in generators/my_section.py extending BaseGenerator

  2. Register it in generators/orchestrator.py

  3. Add the field to ProjectDocumentation in models/documentation.py

Troubleshooting

FileNotFoundError: credentials.json Download OAuth credentials from the Clients tab in APIs & Services → Google Auth Platform and place credentials.json in the project root.

Can't find "OAuth consent screen" in the sidebar Google renamed it to Google Auth Platform. Navigate to APIs & Services → Google Auth Platform instead.

access_blocked error during OAuth login` Your email isn't in the Test Users list. Go to Google Auth Platform → Audience tab → Test users and add your Gmail address.

Token refresh failed Delete token.json and restart the server. A new browser authentication window will open.

Scopes not showing in Data Access tab The APIs must be enabled first. Go to APIs & Services → Library, enable Google Docs API and Google Drive API, then return to the Data Access tab.

PDF export fails WeasyPrint requires system libraries. On Ubuntu/Debian:

apt-get install libpango-1.0-0 libharfbuzz0b libpangoft2-1.0-0

No API endpoints detected Ensure the repository uses supported frameworks. Currently supports FastAPI, Flask, Django, Express, and Next.js route handlers.

License

MIT — see LICENSE for details.

Available Tools

12 tools
analyze_repositoryA

Analyze a software repository and return detailed metadata including detected languages, frameworks, API endpoints, database models, environment variables, CI/CD configuration, and dependencies.

ParametersJSON Schema
NameRequiredDescriptionDefault
repo_pathYesAbsolute or relative path to the repository root directory.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly states the tool analyzes and returns metadata, but it does not explicitly state that it is read-only, nor does it mention behavior for invalid paths or potential performance implications. Core behavior is covered, but edge cases are not.

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 efficiently conveys the purpose and output. The list of metadata categories is informative without being redundant.

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

Completeness5/5

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

Given the low complexity of one parameter and the presence of an output schema, the description adequately covers what the tool does and what it returns. It provides a clear scope of the analysis, making it sufficient for an agent to correctly select and invoke the 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% for the sole parameter repo_path, which is fully described as an absolute or relative path. The tool description adds no additional nuance about parameters, so the baseline score of 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 tool analyzes a software repository and returns detailed metadata. It lists specific metadata categories (languages, frameworks, API endpoints, etc.), distinguishing it from sibling tools that generate documentation rather than analyze and report.

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 when repository metadata is needed, but it does not explicitly mention when to avoid using it or name any alternative tools. Sibling tools like generate_project_documentation could overlap, but no exclusions are provided.

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

create_google_docA

Create a formatted Google Doc from previously generated documentation content.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleNoDocument title.
repo_pathYesPath to the repository (will be analyzed on-the-fly).
share_withNoEmail addresses to share the document with.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.7/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 the full burden. It discloses that the tool creates a document (a mutation), but it omits critical behavioral details like required authentication, whether it overwrites an existing doc with the same title, potential side effects on Google Drive, or error conditions. This is insufficient transparency for a creation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is a single concise sentence that clearly communicates the core purpose without any fluff. Every word earns its place.

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?

The tool has moderate complexity with an output schema and related sibling tools. The description is minimal but leaves ambiguity: it says 'previously generated documentation content' yet the schema mentions repo_path 'will be analyzed on-the-fly', implying possible contradiction about the source. It also lacks explicit prerequisite context (e.g., run generate_project_documentation first). This is incomplete but not severely so.

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. The description adds no additional meaning about parameters, such as how repo_path is used or what share_with does. Baseline of 3 is appropriate since the schema carries the load.

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

Purpose5/5

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

The description clearly states the tool creates a formatted Google Doc from previously generated content, using a specific verb and resource. It distinguishes itself from sibling tools like generate_project_documentation (which generates content) and update_google_doc (which updates an existing doc).

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

Usage Guidelines4/5

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

The description implies when to use the tool: after documentation has been generated, as indicated by 'from previously generated documentation content'. However, it does not explicitly mention alternatives or exclusions, such as using update_google_doc for edits or export_markdown for non-Google formats.

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

document_apiA

Extract and document all API endpoints from a repository. Returns a structured list of endpoints with methods, paths, handlers, and auth requirements.

ParametersJSON Schema
NameRequiredDescriptionDefault
repo_pathYesPath to the repository.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the burden of disclosure. It states what the tool returns ('structured list of endpoints with methods, paths, handlers, and auth requirements'), which clarifies behavior. It does not mention side effects, but the return-focused wording suggests a read-only operation.

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, each earning its place. The first sentence states the core purpose, and the second summarizes the output format. No unnecessary filler.

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 simple single-parameter tool and the presence of an output schema, the description sufficiently covers the tool's purpose and expected output. It could be more complete with usage context or constraints, but it is adequate for selecting the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully describes the single parameter 'repo_path' with 100% coverage. The description does not add additional semantic meaning beyond what the schema provides, so a 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 specific action ('Extract and document') and the resource ('API endpoints from a repository'). It also distinguishes from sibling tools like analyze_repository or generate_project_documentation by focusing on API endpoint discovery.

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

Usage Guidelines4/5

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

The description provides clear context that this tool is for API endpoint extraction from a repository, implying it is for that purpose. However, it does not explicitly mention when not to use it or name alternatives, so it lacks explicit usage guidance.

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

document_databaseA

Extract and document all database models from a repository (SQLAlchemy, Django ORM, Prisma, TypeORM, Mongoose). Returns tables with fields, types, and relationships.

ParametersJSON Schema
NameRequiredDescriptionDefault
repo_pathYesPath to the repository.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

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 discloses the output format ('Returns tables with fields, types, and relationships'), which is helpful, but it does not state whether the tool modifies the repository, requires specific permissions, or how it handles repositories without supported ORMs. This is adequate but not rich.

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 action and scope. The list of ORMs is compact and informative, with no filler or redundancy.

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 tool's simplicity (one parameter) and existing output schema info (though not shown), the description adequately explains what the tool returns and its supported ORMs. It lacks details on edge cases or fallback behavior, but overall it is reasonably complete for its complexity.

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% coverage for the single parameter repo_path, describing it as 'Path to the repository.' The description adds no additional parameter-level detail, so it meets the baseline without contribution.

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 uses specific verbs ('Extract and document') and identifies the resource ('all database models from a repository'). It lists supported ORMs to further clarify scope, distinguishing it from siblings like document_api or generate_project_documentation.

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

Usage Guidelines3/5

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

The description implies its usage by naming the target resource (database models) and supported ORM frameworks, but it does not explicitly state when to use it over alternatives or mention any exclusions. This is clear context but lacks explicit guidance on when not to use or what sibling tools to prefer.

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

export_htmlB

Generate documentation and export it as a styled HTML file with Mermaid diagram support.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleNoDocument title.
repo_pathYesPath to the repository.
output_pathNoPath to save the .html file.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the output format (HTML, Mermaid) but omits side effects such as file writing, overwrite behavior, or dependencies. This leaves the agent uncertain about what invoking the tool will do.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is a single concise sentence that is front-loaded with the primary action and output format. Every word earns its place with no unnecessary filler.

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 full schema coverage and presence of an output schema, the description is minimally adequate. However, it lacks usage context and behavioral detail, making it incomplete for an agent deciding when to use this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all three parameters (repo_path, title, output_path) with complete descriptions. The description adds no additional parameter semantics, so the baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool generates documentation and exports it as a styled HTML file with Mermaid support. This distinguishes it from sibling tools like export_markdown and export_pdf by specifying the output format and key feature.

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 offers no guidance on when to choose this tool over alternatives like export_markdown or export_pdf. It does not mention use cases, exclusions, or compare with siblings.

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

export_markdownB

Generate documentation for a repository and export it as a Markdown file.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleNoDocument title.
repo_pathYesPath to the repository.
output_pathNoPath to save the .md file.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, and the description only restates the core operation. It does not disclose important behavioral details such as whether it writes to the filesystem, overwrites existing files, requires network access, or what happens when output_path is not provided.

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 with no redundant words. It succinctly communicates the tool's primary purpose and output.

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?

With full schema coverage and an output schema present, the basic mechanics are adequately covered. However, the description is thin on usage context, especially relative to sibling tools, and leaves behavioral details such as file-handling behavior unspecified.

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?

All three parameters are fully described in the schema (100% coverage), so the description adds little beyond reinforcing that repo_path refers to a repository and output_path refers to a Markdown file. This meets the baseline but does not exceed it.

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 action (generate documentation) and the output format (Markdown file), which distinguishes it from HTML/PDF export siblings. However, it does not explicitly differentiate it from generate_project_documentation, which may have overlapping functionality.

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

Usage Guidelines3/5

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

The description implies usage for when a user wants repository documentation as a Markdown file, but it offers no explicit guidance on when to choose this tool over closely related siblings like generate_project_documentation or export_html/export_pdf.

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

export_pdfA

Generate documentation and export it as a PDF file. Requires weasyprint and system dependencies (libpango, libcairo).

ParametersJSON Schema
NameRequiredDescriptionDefault
titleNoDocument title.
repo_pathYesPath to the repository.
output_pathNoPath to save the .pdf file.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does disclose a critical prerequisite (weasyprint and libpango/libcairo), which is useful context. However, it does not describe side effects, whether it overwrites existing output files, or any error conditions beyond missing dependencies.

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 short sentences, front-loaded with the core purpose and followed by a key dependency note. Every sentence earns its place, with no wasted words.

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's simplicity (3 params, no annotations), the description covers its main purpose and a key prerequisite. However, there is ambiguity about whether it generates documentation from scratch or exports pre-existing documentation, especially with sibling tools like generate_project_documentation. The presence of an output schema may compensate, but the description alone leaves this gap.

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 already provides descriptions for all three parameters (title, repo_path, output_path) with 100% coverage. The description does not add any additional parameter-specific meaning, such as default behavior for output_path when null, or how title is used in the document. Since schema coverage is high, a baseline of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool generates documentation and exports it as a PDF file, using a specific verb ('Generate') and resource ('documentation') with a target format. This distinguishes it from sibling tools like export_markdown and export_html, which target other formats, and generate_project_documentation, which likely only generates documentation without exporting.

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 when PDF output is needed, but does not explicitly state when to use this tool over alternatives like export_markdown or export_html, nor does it mention exclusions or prerequisites beyond the weasyprint/system dependencies. It provides some context by noting the required dependencies, but lacks clear when-to-use guidance.

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

generate_architectureB

Generate architecture documentation including Mermaid diagrams for a repository. Returns system architecture flowchart and ER diagram in Mermaid syntax.

ParametersJSON Schema
NameRequiredDescriptionDefault
repo_pathYesPath to the repository.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that the tool returns Mermaid syntax diagrams, but it does not clarify whether it reads from the repository only, writes files, or has side effects. The word 'Generate' could imply writing, though 'Returns' suggests a pure return value.

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 concise sentences, front-loaded with the core action and immediately specifying the output format. Every word earns its place with no redundancy.

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?

The description covers the tool's purpose and output, and an output schema exists. However, it lacks usage context, operational limitations, and guidance on how this tool fits among siblings. Given the moderate complexity of generating architecture diagrams, this is adequate but has clear gaps.

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% for the single repo_path parameter, and the description merely refers to 'repository' without adding additional meaning beyond what the schema already provides. This meets the baseline for high schema coverage.

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 uses a specific verb ('Generate') and resource ('architecture documentation for a repository'), and clearly defines the output ('system architecture flowchart and ER diagram in Mermaid syntax'). This distinguishes it from sibling tools like generate_project_documentation, which likely produces broader documentation.

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 gives no guidance on when to use this tool versus alternatives such as analyze_repository or generate_project_documentation. There is no mention of prerequisites, exclusions, or preferred use cases.

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

generate_project_documentationA

Run the full documentation pipeline on a repository: analyze the code, generate all documentation sections, publish to Google Docs, and optionally export to Markdown/HTML/PDF. Returns the Google Docs URL and export paths.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleNoCustom document title. Defaults to "<repo-name> — Engineering Documentation".
repo_pathYesPath to the repository root directory.
export_pdfNoSave a PDF file to the output directory.
share_withNoList of email addresses to share the Google Doc with.
export_htmlNoSave an HTML file to the output directory.
export_markdownNoSave a Markdown file to the output directory.
publish_to_google_docsNoCreate and populate a Google Doc.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4/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 of behavioral disclosure. It does disclose that the tool analyzes code, publishes to Google Docs, exports files, and returns URLs/paths, but it omits side effects, prerequisites (e.g., authentication), and conditional behavior such as interactions between publish_to_google_docs and share_with.

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, action-first, with a clear colon-separated list of steps and the return value. Every clause contributes to understanding the tool's role, making it concise and well-structured.

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?

For a complex tool with seven parameters and an output schema, the description captures the primary workflow, optional exports, and return values. It could improve by suggesting when to choose individual sibling tools, but the current level is adequate for selection and 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 description coverage is 100%, so the schema already documents each parameter. The description only reiterates 'optionally export to Markdown/HTML/PDF' and adds no new meaning beyond what the input schema 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 immediately states the tool's core action with 'Run the full documentation pipeline on a repository' and enumerates each stage (analyze, generate, publish, optionally export). This clearly distinguishes it from sibling tools like generate_readme or create_google_doc, which handle only parts of the pipeline.

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

Usage Guidelines4/5

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

The phrase 'full documentation pipeline' communicates a comprehensive workflow, and the sibling tool names suggest individual steps, so the intended use case is clear. However, it lacks explicit 'use this instead of X when...' guidance or exclusions, so it stops short of a 5.

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

generate_readmeA

Generate a professional README.md for a repository based on code analysis. Includes badges, description, installation, usage, and API overview.

ParametersJSON Schema
NameRequiredDescriptionDefault
repo_pathYesPath to the repository.
output_pathNoWhere to save the README.md (defaults to repo_path/README.md).

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It mentions 'based on code analysis' but does not reveal whether the tool overwrites an existing README, requires special permissions, or performs side effects like writing files. The output_path parameter hints at file creation, but the description itself omits this critical behavioral detail.

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 one sentence that is front-loaded with the core action and resource, followed by a compact list of included sections. Every word earns its place, with no redundancy or unnecessary detail.

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?

For a simple two-parameter tool with an output schema, the description covers the main purpose and output contents. However, it lacks usage guidelines and behavioral transparency (e.g., file overwriting, analysis scope), which are needed for an agent to select and invoke it confidently among sibling documentation tools.

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% for both parameters (repo_path and output_path), so the schema already documents their meaning. The description adds no additional parameter semantics beyond mentioning the output content sections. Per the rubric baseline for high schema coverage, a score of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool's function: 'Generate a professional README.md for a repository based on code analysis.' It specifies the resource (README.md), the input (repository), and the method (code analysis). This distinguishes it from sibling tools like generate_project_documentation (broader), document_api, and generate_architecture, which target different artifacts.

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 READMEs from code analysis but does not explicitly state when to use this tool over alternatives like generate_project_documentation or document_api. There are no exclusions or alternative naming, so the agent must infer context from the sibling list and purpose.

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

share_google_docA

Share an existing Google Doc with one or more email addresses.

ParametersJSON Schema
NameRequiredDescriptionDefault
roleNoPermission role — 'reader', 'commenter', or 'writer'.commenter
doc_idYesGoogle Docs document ID.
emailsYesList of email addresses to share with.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description bears full responsibility for disclosing behavior. It only states the basic action and target, but omits any details about access permission handling, potential overwriting of existing permissions, notification side effects, or required authentication scopes. This is a significant gap for a mutation tool.

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, tight sentence of 11 words. Every word contributes to conveying the core purpose, and it is front-loaded with the action. There is no redundancy or filler.

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?

The tool has a moderate complexity with three parameters, but the schema fully documents them and an output schema exists (per context signals). The description covers the primary purpose but leaves gaps about behavioral nuances, use-case boundaries, and permission implications. It is minimally viable but has clear gaps.

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 provides 100% coverage with descriptions for all three parameters, so the baseline is 3. The description adds a little context by clarifying the email parameter ('one or more email addresses') and the doc_id ('existing Google Doc'), but it does not add substantive meaning beyond what the schema already documents.

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 (share), the resource (existing Google Doc), and the target (one or more email addresses). It distinguishes itself from sibling tools like create_google_doc and update_google_doc by specifying 'existing' and focusing on sharing rather than creation or modification.

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 phrase 'existing Google Doc' implies that this tool is for documents already created, giving some usage context. However, it provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The usage is implied rather than clearly directed.

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

update_google_docB

Regenerate documentation and update an existing Google Doc by ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleNoNew document title (optional).
doc_idYesThe Google Docs document ID to update.
repo_pathYesRepository path to re-analyze.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'regenerate' and 'update' but does not reveal whether existing content is overwritten, whether permissions are needed, or any side effects. This lack of detail is a significant gap for a mutation tool.

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 sentence, compact and to the point. It front-loads the action and resource, with no wasted words. Every word contributes to the core purpose.

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?

The presence of an output schema and full parameter descriptions reduces the need to explain return values and parameters. However, the description lacks usage guidance and behavioral nuance about the regeneration process, making it adequate for simple selection but not fully complete for all invocation contexts.

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 tool description adds little beyond the schema; 'by ID' repeats the doc_id description, and 'regenerate documentation' is implicit in repo_path. No additional parameter meaning is provided.

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 function: 'Regenerate documentation and update an existing Google Doc by ID.' It uses a specific verb ('update') and resource ('existing Google Doc'), and distinguishes itself from siblings like create_google_doc (create vs update) and share_google_doc.

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 explicit guidance is provided on when to use this tool versus alternatives. The description implies it is for updating existing docs, but does not state exclusions, prerequisites, or mention alternatives such as create_google_doc for new documents.

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.

  1. 12 tool updatesv0.1.0
    • First observedanalyze_repository
    • First observedcreate_google_doc
    • First observeddocument_api
    • First observeddocument_database
    • First observedexport_html
    • First observedexport_markdown
    • First observedexport_pdf
    • First observedgenerate_architecture
    • First observedgenerate_project_documentation
    • First observedgenerate_readme
    • First observedshare_google_doc
    • First observedupdate_google_doc
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0
Disambiguation4/5

Most tools target distinct outputs (README, architecture, API, database, exports), but generate_project_documentation is a superset that overlaps with the individual generation and export tools, creating mild ambiguity about when to use it versus the separate tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (analyze_repository, generate_readme, export_pdf, share_google_doc), making the naming predictable and easy to navigate.

Tool Count5/5

With 12 tools, the server is well-scoped for an engineering documentation workflow, covering analysis, generation, publishing, and exporting without excessive redundancy.

Completeness4/5

The tool surface covers the core documentation lifecycle (analyze, generate, publish, export, share), but lacks simple management operations like listing or deleting Google Docs, which are minor gaps for a full workflow.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

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/mfaizanmumtaz/Engineering-Docs-MCP'

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