A
licenseA
qualityD
maintenanceEnables generation of PlantUML diagrams (sequence, class, C4, architecture) with embeddable SVG/PNG URLs, encoding/decoding capabilities, and automatic syntax error detection and fixing.
3
364 npm
53
MIT
@plantuml/mcp-js
Officialby plantuml
This MCP server provides programmatic access to PlantUML diagrams, running entirely in Node.js (no Java required) via an AI assistant. It offers four main capabilities:
Get PlantUML version: Retrieve the version of the embedded PlantUML library.
Check diagram syntax: Validate a diagram's syntax without rendering; returns validity, diagram type, line count, warnings, and detailed error info if invalid.
Render diagram to SVG: Generate a deterministic SVG from a diagram; returns the SVG content, diagram type, line count, warnings, or error details on failure.
Explain diagram parsing: Obtain a line-by-line explanation of how a diagram is parsed, showing input lines, human-readable explanations, and line numbers.
TIP
đ§ŠNew! Render PlantUML diagrams directly inside GitHub with our official browser extension — No server. No tokens. No tracking. Zero permissions but clipboard.
đŦ Want native PlantUML support in GitHub? Upvote and join the discussion: Support for PlantUML diagrams
TIP
đ¤New! Give your AI assistant the power to render and check PlantUML diagrams with @plantuml/mcp-js — a pure Node.js MCP server. No Java. No server. Just npx @plantuml/mcp-js.
đą PlantUML
Generate UML diagrams from textual descriptions.
âšī¸ About
PlantUML is a component that allows you to create various UML diagrams through simple textual descriptions. From sequence diagrams to deployment diagrams and beyond, PlantUML provides an easy way to create visual representations of complex systems.
đī¸ Supported Diagram Types
𧊠UML Diagrams
đ Non-UML Diagrams
Entity Relationship (ER) diagram
đŖ Additional Features
đ Learn More
For a more detailed overview, visit PlantUML Official Website.
Related MCP server: PlantUML MCP Server
đĄ Security
See Security Policy and Security overview.
đ Getting Started
Whether you're looking to use PlantUML as a standalone application or as a component in your own project, getting started is simple. Check out the official PlantUML setup guide for instructions on how to set up PlantUML on your system.
âī¸ Building from Source
To build PlantUML from source, you have two options:
Using Gradle:
./gradlew jarUsing Ant:
ant
For prerequisites and detailed build instructions, see our BUILDING.md guide.
đ Building for the Browser (TeaVM)
PlantUML can be compiled to JavaScript with TeaVM to run entirely client-side in the browser, with no server required. To produce the JavaScript artifacts and use them in your own project:
git clone https://github.com/plantuml/plantuml.git
cd plantuml
chmod +x ./gradlew
./gradlew clean teavm -Pfast
cp ./build/generated/teavm/js/plantuml.js $YOUR_PROJECT/plantuml.js
cp ./build/generated/teavm/js/viz-global.js $YOUR_PROJECT/viz-global.jsThe -Pfast flag skips the slow parts of a regular build (tests, Javadoc, JaCoCo) so you only get the TeaVM output. The viz-global.js file provides Viz.js (Graphviz) support for diagrams that rely on Dot layout.
The teavm task also copies the PlantUML stdlib bundles and a ready-to-use index.html demo into ./build/generated/teavm/js/.
For a live example of client-side rendering, see the JavaScript PlantUML Demo.
𧹠Contributing
PlantUML is an open-source project, and we welcome contributions of all kinds. Whether you're helping us fix bugs, improve the docs, or spread the word, we appreciate your support. See our contributing guide for more information on how to get started.
The language guide on plantuml.com is updated through alphadoc. Edit a page there (pick a language and wiki syntax), save, and maintainers publish it after review. Details are in CONTRIBUTING.md.
For comprehensive and detailed documentation on using PlantUML, refer to the official Javadoc, available here. Please note that this documentation is a work in progress and may not be complete.
đ§âđ¤âđ§ Support and Community
đ License
PlantUML is licensed under several licenses; you can choose the one that suits you best:
For more information, please refer to the PlantUML license FAQ to help determine which license is appropriate for your use case.
Available Tools
4 toolscheck_syntaxA
Checks the syntax of a single PlantUML diagram without rendering it. Returns a JSON object containing: 'valid' (boolean), 'diagramType' (if valid), 'lineCount', 'warnings' (list of non-fatal warnings), and on failure 'errorLineNumber' (1-based line number), 'errorMessage', 'errorLine' (the offending source line, when available), and 'errorContext'.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | The PlantUML source to check, including @start.../@end... (a single diagram) |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries behavioral disclosure. It details return values for success and failure, mentions no side effects, and clarifies the single-diagram constraint. It does not cover authorization or limits but is adequate.
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 purpose, efficient enumeration of return fields. No unnecessary 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?
Given no output schema, the description covers return structure comprehensively. It addresses both success and error states, but lacks mention of potential prerequisites or environment dependencies.
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% and the parameter description already includes the specific constraint. The tool description does not add additional meaning beyond the schema, so baseline 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 checks syntax of PlantUML diagrams without rendering, using specific verb and resource. It implicitly distinguishes from siblings like render_diagram by noting 'without rendering'.
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 by stating 'without rendering', hinting at use case. However, it lacks explicit guidance on when to use versus alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_diagramA
Explains how a single PlantUML diagram is parsed, line by line. Returns a JSON array of objects, each containing: 'input' (the source line(s) that produced the explanation), 'explain' (a human-readable explanation), and 'line' (1-based line number, when available).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | The PlantUML source to explain, including @start.../@end... (a single diagram) |
TDQS
A3.8/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 full burden. It discloses the return format (JSON array with input, explain, line fields) and that it operates line by line. However, it does not mention that the tool is read-only, has no side effects, or any limitations such as diagram size or performance characteristics.
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 exceptionally concise, with two sentences. The first sentence defines the core purpose, and the second details the output format. Every sentence adds value without redundancy or 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 no output schema, the description adequately explains the return structure with three fields. It also clarifies the input constraint (single diagram with delimiters). Minor improvement could be stating the tool is non-destructive, but overall it is complete for a simple tool with one parameter.
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 only parameter, 'source', is fully described in the schema (100% coverage) with the same details as the description. The description adds no new meaning beyond the schema, 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 explains how a single PlantUML diagram is parsed line by line, with a specific verb and resource. It distinguishes itself from siblings (check_syntax, plantuml_version, render_diagram) by focusing on parsing explanation rather than syntax, version, or rendering.
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 a user wants an explanation of how a PlantUML diagram is parsed, but does not explicitly state when to use vs. alternatives or provide any exclusions or prerequisites. The context about requiring a single diagram with @start.../@end... is helpful but not sufficient for strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
plantuml_versionA
Returns the version of the embedded PlantUML library (TeaVM JS build).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context about it being a TeaVM JS build, but no annotations provided. For a simple read-only operation, this is sufficient transparency.
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-loaded with verb and resource, no wasted words.
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?
The description fully covers the tool's function for a version endpoint with no parameters or output schema - no gaps remain.
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; schema coverage is 100%. Baseline score of 4 applies as description adds no parameter info beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns the version of the PlantUML library, distinguishing it from sibling tools that check syntax, explain, or render diagrams.
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?
Though not explicitly stating when to use, the context of siblings (syntax checking, diagram rendering) makes it obvious this tool is for version retrieval. No confusion with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
render_diagramA
Renders a single PlantUML diagram to a deterministic SVG. Returns a JSON object containing: 'valid' (boolean), and when valid 'diagramType', 'lineCount', 'warnings' (list of non-fatal warnings) and 'svg' (the rendered SVG as a string). On failure it has the same error shape as check_syntax: 'errorLineNumber' (1-based), 'errorMessage', 'errorLine' (the offending source line, when available) and 'errorContext'.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | The PlantUML source to render, including @start.../@end... (a single diagram) |
TDQS
A4.2/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and is highly transparent. It details both success (valid, diagramType, lineCount, warnings, svg) and failure (errorLineNumber, errorMessage, errorLine, errorContext) responses, even referencing the error shape from check_syntax.
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 three sentences with no wasted words. It front-loads the core action (rendering to SVG) and then concisely list the return structure. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully explains the tool's behavior and output, given the single parameter and lack of output schema. It covers both success and error cases. Minor omission: no mention of performance constraints or idempotency, but these are not critical for 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?
Schema coverage is 100% and the parameter description already includes the source content and constraint of being a single diagram. The tool description does not add new parameter meaning beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it renders a single PlantUML diagram to SVG. It distinguishes from siblings (check_syntax, explain_diagram, plantuml_version) by specifying the output format and that it is a deterministic rendering operation.
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 rendering a diagram but does not explicitly state when to use it versus alternatives. It lacks 'when-not' guidance or direct comparison with sibling tools, leaving the agent to infer based on purpose.
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 updates
v0.2.0- First observed
check_syntax - First observed
explain_diagram - First observed
plantuml_version - First observed
render_diagram
TDQS
A4.1/5.0
Scored across 4 tools
Disambiguation5/5
Each tool has a clearly distinct purpose: syntax checking, line-by-line explanation, version retrieval, and SVG rendering. No overlap or ambiguity.
Naming Consistency4/5
All tool names use consistent snake_case with descriptive verbs/nouns (check_syntax, explain_diagram, render_diagram). 'plantuml_version' is a minor deviation (noun_noun) but still follows the same style and is intuitive.
Tool Count5/5
Four tools is well-scoped for a PlantUML server, covering core operations (check, render, explain, version) without being too few or overly numerous.
Completeness4/5
The tool surface covers essential diagram workflows (validate, render, explain). A potential gap is the lack of a tool to list supported diagram types or configure rendering options, but the core is solid.
Maintenance
ActivityActive
ResponsivenessResponsive
Related MCP Connectors
Render, validate, encode/decode PlantUML diagram-as-code; 22 diagram types. Free, no auth.
Render, verify, describe, and safely edit Mermaid diagrams through MCP.
Collaborative whiteboard MCP server â create objects, connectors, C4 diagrams, and manage boards
HTML-to-PDF MCP server â render pixel-faithful PDFs from HTML.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to generate UML diagrams from text descriptions using PlantUML, supporting multiple output formats (PNG, SVG, PDF), syntax validation, and diagram source extraction.4 npmMIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that validates Mermaid diagram syntax and identifies diagram types across all major formats. It provides detailed parse-error messages for invalid diagrams without requiring external rendering processes.10 npm3MIT
- AlicenseAqualityAmaintenanceMCP server for rendering 35+ diagram types â sequence, flowchart, ER, C4, gantt, mindmap, infra, and more â to SVG/PNG with browser preview. Local rendering with palette/theme support and shareable diagrammo.app URLs.211630 npm3MIT
