Which integrations are available for this server?

Supports generating Excalidraw diagrams as one of the specialized diagram types available through the server. Enables generating Mermaid diagrams from textual definitions and rendering them to SVG, PNG, PDF, JPEG, or base64 outputs. Allows generating UML diagrams, including class, sequence, activity, use case, state, component, deployment, and object diagrams.

How do I use UML-MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@UML-MCP Generate a UML class diagram for a library management system" 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.

UML-MCP

by Delight-L

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

UML-MCP: Diagram Generation via MCP

Run Tests Build Package Deploy docs GitHub stars License: MIT Python >=3.12,<3.13

Generate UML and other diagrams through the Model Context Protocol.

At a glance

Topic	What you get
Diagrams	30+ types: UML (Class, Sequence, Activity, Use Case, State, Component, Deployment, Object), Mermaid, D2, Graphviz, TikZ, ERD, BlockDiag, BPMN, C4, and more via Kroki
MCP tools	`generate_uml`, `validate_uml`, `list_diagram_types`, `generate_uml_batch`
Outputs	SVG, PNG, PDF, JPEG, base64 (availability varies by diagram type)
Pipeline	Kroki first, then PlantUML or Mermaid.ink
Deployment	Local stdio, local HTTP, Docker, Vercel, Smithery

Source	URL
Live MCP (HTTP)	https://uml-mcp.vercel.app/mcp
Smithery catalog	Add via Smithery

Quick Start

Choose your mode

Remote (recommended): Fast setup over HTTP MCP with Vercel serverless runtime
Local: stdio process for file output and local debugging

Remote quick start (Vercel HTTP MCP)

Configuration for the public Vercel deployment:

"uml-mcp": {
  "transport": "http",
  "url": "https://uml-mcp.vercel.app/mcp"
}

Local quick start (stdio MCP)

git clone https://github.com/antoinebou12/uml-mcp.git && cd uml-mcp
uv sync
uv run python server.py

Example client configs:

config/cursor_config.json
config/claude_desktop_config.json
config/README.md for exact config file locations
Claude Code: install the bundled plugin from the repo marketplace (see below) or read docs/integrations/claude_code.md

Claude Code plugin

Adds the hosted HTTP MCP server plus a diagram skill (no settings.json paste). In Claude Code:

/plugin marketplace add https://github.com/antoinebou12/uml-mcp
/plugin install uml-mcp@uml-mcp-plugins

Use a local path instead of the GitHub URL if you already cloned this repo. Custom endpoints and validation: docs/integrations/claude_code.md.

Related MCP server: Draw.io MCP Server

Remote vs Local

Transport: Remote uses HTTP MCP, local uses stdio by default
Runtime: Remote runs on Vercel, local runs in your Python environment
File writes: Remote is read-only (no output_dir), local supports output_dir
Returned data: Both return URL + base64; local can also save files
Environment variables: Remote is managed server-side; local reads your env config

MCP clients must call /mcp, not the site root.

Supported Diagram Types

Category	Examples
UML (PlantUML)	Class, Sequence, Activity, Use Case, State, Component, Deployment, Object
General	Mermaid, D2, Graphviz, ERD, BlockDiag, BPMN, C4
Specialized	TikZ, Excalidraw, Nomnoml, Pikchr, Structurizr, SVGBob, WaveDrom, WireViz, …

Full list with supported formats: run python server.py --list-tools or query uml://types and uml://formats.

MCP Tools and Resources

Tools

Tool	Purpose
`generate_uml`	Render a diagram; omit `output_dir` for URL/base64 only
`validate_uml`	Structural validation before render; `strict` enables extra Mermaid/D2 checks
`list_diagram_types`	Same metadata as `uml://types` when resources are awkward
`generate_uml_batch`	Multiple diagrams in one call (cap: `MCP_BATCH_MAX_ITEMS`)

Resources (`uml://`)

Resource	Description
`uml://types`	Diagram types, backends, supported formats per type
`uml://templates`	Starter templates per type; see BPMN 2.0.2 guide for element and flow reference (docs)
`uml://examples`	Example diagrams per type; Mermaid documents named samples (sequence API, Gantt) alongside `uml://examples` (key `mermaid`)
`uml://formats`	Output formats per type
`uml://capabilities`	Type → backend → formats matrix used for validation
`uml://server-info`	Server name, version, tools, prompts, Kroki/PlantUML URLs
`uml://workflow`	Recommended plan-then-generate workflow

Deployment

Vercel

This repo includes vercel.json for serverless deployment.

Connect the repo to Vercel
Use https://<project>.vercel.app/mcp
Keep /mcp in all MCP client URLs

Smithery

Open smithery.ai/new, choose URL
Enter https://<project>.vercel.app/mcp
Configure display name, description, and homepage

Detailed guide: docs/integrations/vercel_smithery.md

Docker

Default image serves FastAPI on port 8000 with MCP HTTP at http://127.0.0.1:8000/mcp.

# Full local stack (local Kroki + mermaid + blockdiag)
docker compose up -d

# API + MCP only (public Kroki)
docker build -t uml-mcp . && docker run -p 8000:8000 uml-mcp

# stdio MCP subprocess mode
docker run -i uml-mcp python server.py --transport stdio

Configuration (Local runtime)

These variables apply to local/self-hosted runs. Remote Vercel endpoint settings are managed server-side.

Variable	Description	Default
`KROKI_SERVER`	Kroki server URL	`https://kroki.io`
`PLANTUML_SERVER`	PlantUML server URL	`http://plantuml-server:8080`
`MCP_OUTPUT_DIR`	Diagram output directory	`./output`
`MCP_READ_ONLY`	Disable file writes	`false`
`MCP_MAX_CODE_LENGTH`	Max diagram code length	`500000`
`MCP_BATCH_MAX_ITEMS`	Max items per `generate_uml_batch`	`20`
`MCP_RATE_LIMIT_PER_MINUTE`	HTTP rate limit per IP for diagram/MCP routes (`0` = off)	`0`
`USE_LOCAL_KROKI`	Use local Kroki instance	`false`
`USE_LOCAL_PLANTUML`	Use local PlantUML instance	`false`

Full options: docs/configuration.md

Architecture

Typical flow when a user asks an MCP-enabled assistant for a diagram: the assistant calls generate_uml, the server renders via Kroki, then returns URLs and optional base64 to the assistant for the user.

server.py              -- MCP entry point (stdio/HTTP)
app.py                 -- FastAPI REST API + MCP HTTP at /mcp
api/app.py             -- legacy re-export of root app (Vercel FastAPI preset uses root app.py)
mcp_core/
  core/                -- config, server, CLI, utilities, diagram pipeline
  tools/               -- generate_uml, validate_uml
  prompts/             -- diagram generation prompts
  resources/           -- uml:// resource handlers
tools/kroki/           -- Kroki, PlantUML, Mermaid, D2 clients

Development

# Install dev dependencies
uv sync --all-groups

# Run tests
uv run pytest tests/ -v

# Lint
uv run ruff check . && uv run ruff format --check .

# Local CI
make ci

Documentation

Built with MkDocs + Material:

Online: antoinebou12.github.io/uml-mcp
Local: uv run mkdocs serve then open http://127.0.0.1:8000

Contributing

License

MIT

Acknowledgements

PlantUML | Kroki | Mermaid | D2

Star History

Available Tools

4 tools

generate_umlB

Idempotent

Generate any UML or diagram by type (class, sequence, mermaid, d2, etc.)

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Diagram code in the syntax for the chosen type
`scale`	No	Scale factor for SVG only (default 1.0, min 0.1). Ignored for other formats.
`theme`	No	PlantUML theme for UML diagrams (e.g. cerulean)
`output_dir`	No	Directory to save the image. Omit or None for URL, playground, and content_base64 only (no file write; use in serverless / read-only).
`diagram_type`	Yes	Type of diagram (class, sequence, activity, mermaid, d2, etc.)
`output_format`	No	svg, png, pdf, jpeg, txt, or base64 (default: svg). See uml://formats per type.	svg

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior3/5

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

Annotations provide idempotentHint and destructiveHint. Description adds no further behavioral detail beyond generating diagrams, which is already clear. No contradictions.

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

Conciseness5/5

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

Single sentence, front-loads purpose, no wasted words. Efficient and clear.

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 6 parameters and output schema, description is sparse. Lacks context about output format options, file saving ability, or relationship to siblings. Output schema partly compensates.

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 parameter descriptions. Tool description only hints at diagram_type via examples, adding minimal value beyond schema.

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?

Description clearly states the tool generates UML or diagrams by type, with examples. It distinguishes the action from siblings like validate_uml but does not explicitly differentiate from generate_uml_batch.

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 siblings. No mention of batch generation or validation alternatives.

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

generate_uml_batchA

Idempotent

Generate multiple diagrams in one call. Each item is like generate_uml (diagram_type, code, output_format?, theme?, scale?). Optional shared output_dir for all items. Returns a list of per-index results or errors.

ParametersJSON Schema

Name	Required	Description	Default
`items`	Yes
`output_dir`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior3/5

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

Annotations provide idempotentHint=true (safe to retry) and readOnlyHint=false (modifies state). The description adds that it returns a list of per-index results or errors, but lacks details on partial failures, atomicity, or whether output_dir affects file storage. Basic transparency but could be more detailed.

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 action, and every word adds value. No wasted or repetitive language.

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 complexity (2 parameters, one being an array of objects with no strict schema) and that an output schema exists, the description is fairly complete. It covers the item structure and the return format. A minor gap is the precise behavior of output_dir (e.g., if it creates directories), but overall it provides sufficient context for an AI agent.

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

Parameters4/5

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

Schema description coverage is 0%, so the description compensates by explaining that 'items' are like generate_uml with specific parameters (diagram_type, code, output_format?, theme?, scale?) and that output_dir is an optional shared directory. This provides meaningful semantics beyond the raw schema.

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

Purpose5/5

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

The description clearly states the tool's purpose: generating multiple diagrams in one call. It distinguishes from the sibling 'generate_uml' by being a batch version, and lists the parameters that each item uses, similar to generate_uml.

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 usage context by stating 'Each item is like generate_uml' and mentions an optional shared output_dir. However, it does not explicitly state when to use this batch tool versus the single-call alternative, or when not to use it.

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

list_diagram_typesA

Read-onlyIdempotent

List supported diagram types with Kroki backend, description, and formats (same data as uml://types resource). Use when the client cannot read resources.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already provide readOnlyHint, idempotentHint, destructiveHint, openWorldHint. The description adds context about the Kroki backend and data equivalence to a resource, which is additional useful behavioral info beyond annotations.

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, front-loaded with the action and key details. No extraneous information. Every sentence adds value.

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?

For a simple list tool with no parameters and an output schema, the description covers what the tool lists (diagram types, backend, description, formats) and its usage context. It is complete.

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

Parameters4/5

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

No parameters exist, so baseline is 4. The description adds no parameter info, but that's not needed. It provides context about the output content, which is helpful.

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 it lists supported diagram types with Kroki backend, description, and formats. It distinguishes from sibling tools which generate or validate UML, so purpose is unambiguous.

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

Usage Guidelines5/5

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

Explicitly says 'Use when the client cannot read resources.' This provides clear when-to-use guidance and implies the alternative (use the resource if available).

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

validate_umlA

Read-onlyIdempotent

Validate diagram type, format, code length, and basic syntax locally before render (no Kroki call). Returns errors and suggestions.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Diagram source text.
`strict`	No	When True, apply extra Mermaid/D2 checks (no extra PlantUML rules).
`diagram_type`	Yes	Same as generate_uml (see uml://types).
`output_format`	No	Intended output format (default svg); must be allowed for the type.	svg

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior5/5

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

The description adds significant behavioral context beyond the annotations: it specifies local execution (no Kroki call), validates specific aspects (type, format, code length, basic syntax), and returns errors and suggestions. All annotations (readOnlyHint, idempotentHint, destructiveHint) are consistent.

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, well-structured sentence that efficiently conveys the tool's purpose and key characteristics. No wasted words.

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?

The description covers the primary validation scope and return type, and with the output schema present, further detail is unnecessary. It could be slightly more specific about 'basic syntax,' but overall it is complete for the tool's role.

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 with clear descriptions for each parameter. The tool description does not add any additional meaning to the parameters beyond what the schema already provides, so baseline score of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool validates diagram type, format, code length, and basic syntax locally before rendering. It distinguishes from sibling tools like generate_uml by emphasizing it is a pre-render validation step without a Kroki call.

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 the tool should be used before rendering to check validity, and it notes it runs locally without a Kroki call. However, it does not explicitly state when not to use it or name alternative tools for comparison.

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.

4 tool updatesv1.3.0Sep 14, 2026
- First observedgenerate_uml
- First observedgenerate_uml_batch
- First observedlist_diagram_types
- First observedvalidate_uml

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored 2026-09-14 14:20 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct role: listing available types, validating before render, generating a single diagram, and batch-generating multiple diagrams. The single vs. batch generation pair is unambiguous given the explicit descriptions.

Naming Consistency5/5

All four tools follow a consistent verb_noun snake_case pattern (list_diagram_types, generate_uml, generate_uml_batch, validate_uml). No mixing of conventions.

Tool Count5/5

Four tools is well-scoped for a diagram rendering service, covering discovery, validation, single generation, and batch generation without redundancy. Each tool clearly earns its place.

Completeness4/5

The surface covers the full diagram workflow: discover types, validate, generate, and batch generate. Minor gap in that there is no explicit info/help tool, though list_diagram_types largely covers discovery.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

hustcc-mcp-mermaid
ai.smithery
Generate dynamic Mermaid diagrams and charts with AI assistance. Customize styles and export diagr…
Software Architecture Developer Tools App Automation
2632
uml.singsk.com PlantUML A
com.singsk
Render, validate, encode/decode PlantUML diagram-as-code; 22 diagram types. Free, no auth.
Software Architecture Developer Tools
61
Flowgraf A
in.flowgraf
Create and edit architecture diagrams from your AI agent; get an SVG and a live editable canvas.
Software Architecture Design Tools
32
Diagrams MCP A
io.github.mskry
Generate cloud architecture diagrams, flowcharts, and sequence diagrams.
Software Architecture Design Tools Cloud Platforms
923

Related MCP Servers

PlantUML MCP Server
Software Architecture Developer Tools Documentation Access
junqing258
A
license
Not graded
quality
D
maintenance
Enables AI assistants to generate UML diagrams from text descriptions using PlantUML, supporting multiple output formats (PNG, SVG, PDF), syntax validation, and diagram source extraction.
Updated 9 months ago (2025-12-17 10:54 UTC)
4 npm
MIT
Draw.io MCP Server
Software Architecture Developer Tools App Automation
lgazo
A
license
B
quality
A
maintenance
Enables AI agents to programmatically create, modify, and analyze Draw.io diagrams through the Model Context Protocol. Supports generating architectural diagrams, flowcharts, and visualizations with bidirectional communication between AI systems and Draw.io.
Updated 13 days ago (2026-09-01 18:27 UTC)
13
53 npm
1,461
MIT
MCP-GLSP
Design Tools Software Architecture
pulseengine
F
license
Not graded
quality
F
maintenance
Enables AI-driven graphical diagram creation and manipulation using natural language, with support for BPMN workflows, analysis, and manual editing via the Model Context Protocol.
Updated 10 months ago (2025-11-13 19:12 UTC)
1
-
UML-MCP
Software Architecture Developer Tools
antoinebou12
A
license
A
quality
A
maintenance
Generates UML and other diagrams (30+ types) via the Model Context Protocol, supporting multiple output formats and deployment options.
Updated 4 days ago (2026-09-10 21:52 UTC)
4
99
MIT

UML-MCP: Diagram Generation via MCP

At a glance

Quick Start

Choose your mode

Remote quick start (Vercel HTTP MCP)

Local quick start (stdio MCP)

Claude Code plugin

Remote vs Local

Supported Diagram Types

MCP Tools and Resources

Tools

Resources (uml://)

Deployment

Vercel

Smithery

Docker

Configuration (Local runtime)

Architecture

Development

Documentation

Contributing

License

Acknowledgements

Star History

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Resources (`uml://`)