Provides PlantUML diagram generation capabilities, including tools for creating and encoding diagrams, generating embeddable SVG/PNG URLs, and creating various diagram types like sequence diagrams, class diagrams, and C4 architecture diagrams.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PlantUML MCP Server generate a sequence diagram for user login flow"
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.
A Model Context Protocol (MCP) server that provides PlantUML diagram generation capabilities for Claude Desktop and Claude Code.
generate_plantuml_diagram - Generate diagrams and get embeddable URLs (SVG/PNG), optionally save locally
encode_plantuml - Encode PlantUML code for URL sharing
decode_plantuml - Decode PlantUML from encoded strings
plantuml_error_handling - Guidelines for handling PlantUML syntax errors and implementing auto-fix workflows
This prompt provides Claude instances with comprehensive instructions on how to:
Detect PlantUML syntax errors using native server validation
Implement intelligent auto-fix workflows for common syntax issues
Parse structured error responses and apply appropriate corrections
Handle validation failures gracefully with retry logic
The prompt enables Claude to automatically detect and fix common PlantUML errors like missing tags, invalid arrow syntax, typos in keywords, and missing quotes, making PlantUML diagram generation more reliable and user-friendly.
# Using default PlantUML server
claude mcp add plantuml --scope user --env PLANTUML_SERVER_URL=https://www.plantuml.com/plantuml -- npx plantuml-mcp-serverAdd this to your Claude Desktop MCP configuration (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"plantuml": {
"command": "npx",
"args": ["plantuml-mcp-server"],
"env": {
"PLANTUML_SERVER_URL": "https://www.plantuml.com/plantuml"
}
}
}
}To use your own PlantUML server, change the PLANTUML_SERVER_URL environment variable.
Then restart Claude Desktop/Code to activate the MCP server.
Related MCP server: UMLmcp
After setup, you can ask Claude to:
Generate PlantUML diagrams and get embeddable SVG/PNG URLs
Create sequence diagrams, class diagrams, architecture diagrams
Use advanced PlantUML features like !include directives and external libraries
Encode/decode PlantUML for URL sharing
Save diagrams locally with secure path restrictions
The generate_plantuml_diagram tool supports saving diagrams to local files via the output_path parameter.
Security: By default, files can only be saved within the current working directory. Only .svg and .png extensions are allowed.
To allow additional directories, set the PLANTUML_ALLOWED_DIRS environment variable:
# Allow specific directories (colon-separated)
PLANTUML_ALLOWED_DIRS=/home/user/diagrams:/tmp/output
# Allow any directory (use with caution)
PLANTUML_ALLOWED_DIRS=*> add c4 diagram for this project in readme 'C4 diagram for plantuml-mcp-server' section> add sequence diagram in readme in architecture section> show me basic oauth2 flow png, open it in browserNode.js 18+
npm
# Clone and setup
git clone https://github.com/mzagar/plantuml-mcp-server.git
cd plantuml-mcp-server
make setup# Show all available commands
make help
# Build and run all tests
make clean build test-allVariable | Description | Default |
| PlantUML server URL |
|
| Additional directories for | CWD only |
MIT License - see LICENSE file for details.
Decode encoded PlantUML string back to PlantUML code
| Name | Required | Description | Default |
|---|---|---|---|
| encoded_string | Yes | Encoded PlantUML string to decode |
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 clearly states the transform (decode to PlantUML code) but does not mention error handling, input validation, or side effects. For a simple transform, this is adequate but not rich; a more explicit note about non-mutating behavior would elevate it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundancy. It is front-loaded with the action verb and immediately conveys the purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with full schema coverage, the description is complete enough. It states the input and the output implicitly ('back to PlantUML code'). Since no output schema exists, the description's mention of the output helps, though it could specify the return format (e.g., UTF-8 string) for absolute clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameter with a description ('Encoded PlantUML string to decode') that mirrors the tool description. The description adds no additional semantic detail beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('decode') with a clear resource ('encoded PlantUML string') and outcome ('back to PlantUML code'). It distinguishes itself from sibling tools like encode_plantuml and generate_plantuml_diagram by explicitly stating the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you have an encoded PlantUML string. However, it does not explicitly state when to use this tool over alternatives, nor does it mention preconditions or exclusions. The sibling context suggests encode_plantuml as the inverse, but the description itself provides no direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Encode PlantUML code for URL usage
| Name | Required | Description | Default |
|---|---|---|---|
| plantuml_code | Yes | PlantUML diagram code to encode |
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 not disclose what the encoded output looks like, whether it's a pure transformation, or any error behavior. The phrase 'for URL usage' implies a URL-safe result but lacks specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb, and contains no filler. It is appropriately sized for a tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain the return value, but it doesn't. It also lacks context about when to use encoding and what the output format is. For a simple tool this is still a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the parameter is described as 'PlantUML diagram code to encode'), so the baseline is 3. The description adds no additional meaning about the parameter, such as format constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('encode') and resource ('PlantUML code') with a clear purpose ('for URL usage'). It distinguishes from sibling tools like decode_plantuml (the inverse operation) and generate_plantuml_diagram (which creates diagrams).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that decode_plantuml is the inverse or give any context about when encoding is needed, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a PlantUML diagram with automatic syntax validation and error reporting for auto-fix workflows. Returns embeddable image URLs for valid diagrams or structured error details for invalid syntax that can be automatically corrected. Optionally saves the diagram to a local file.
| Name | Required | Description | Default |
|---|---|---|---|
| plantuml_code | Yes | PlantUML diagram code. Will be automatically validated for syntax errors before generating the diagram URL. | |
| format | No | Output image format (SVG or PNG) | svg |
| output_path | No | Optional. Path to save diagram locally. Automatically creates all necessary parent directories. Restricted to current working directory by default. Set PLANTUML_ALLOWED_DIRS env var (colon-separated paths, or "*" for unrestricted) to allow additional directories. Only .svg and .png extensions permitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite having no annotations, the description discloses key behaviors: automatic syntax validation, return of embeddable URLs or structured errors, and optional local file saving. It doesn't detail side effects like overwriting files or permission requirements, but it covers the main behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loaded with the main action and key differentiator.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a moderate number of parameters and no output schema, the description explains the return types (URLs or error details) and optional side effect (file saving). It's sufficient for an agent to understand inputs and outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions, so baseline is 3. The description adds no significant parameter details beyond the schema, though it reiterates the auto-validation behavior for plantuml_code.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('PlantUML diagram') and clearly distinguishes from sibling tools like decode_plantuml/encode_plantuml by adding automatic syntax validation and error reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the tool is for 'auto-fix workflows' and describes its typical use of generating diagrams with validation. It doesn't explicitly name alternatives, but the description implies when to use it versus other PlantUML utilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.3decode_plantumlencode_plantumlgenerate_plantuml_diagramScored across 3 tools
Each tool has a clearly distinct purpose: decode_plantuml reverses encoding, encode_plantuml prepares code for URLs, and generate_plantuml_diagram creates diagrams with validation. There is no overlap or ambiguity between these functions, making tool selection straightforward for an agent.
All tool names follow a consistent verb_noun pattern with snake_case (decode_plantuml, encode_plantuml, generate_plantuml_diagram). The naming is predictable and readable, adhering to a uniform style throughout the set.
With 3 tools, this server is well-scoped for handling PlantUML encoding, decoding, and diagram generation. Each tool earns its place by covering essential operations without bloat, making the count appropriate for the domain.
The tool set provides complete coverage for core PlantUML workflows: encoding for URLs, decoding back to code, and generating diagrams with validation and error handling. There are no obvious gaps, as these tools support the full lifecycle from code to visual output.
Render, validate, encode/decode PlantUML diagram-as-code; 22 diagram types. Free, no auth.
Generate dynamic Mermaid diagrams and charts with AI assistance. Customize styles and export diagr…
Diagrams, badges, charts and QR codes as plain image URLs you can paste into Markdown.
Generate cloud architecture diagrams, flowcharts, and sequence diagrams.
