UML-MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| KROKI_SERVER | No | Kroki server URL | https://kroki.io |
| MCP_READ_ONLY | No | Disable file writes | false |
| MCP_OUTPUT_DIR | No | Diagram output directory (local runtime only) | ./output |
| PLANTUML_SERVER | No | PlantUML server URL | http://plantuml-server:8080 |
| USE_LOCAL_KROKI | No | Use local Kroki instance | false |
| USE_LOCAL_PLANTUML | No | Use local PlantUML instance | false |
| MCP_BATCH_MAX_ITEMS | No | Max items per generate_uml_batch | 20 |
| MCP_MAX_CODE_LENGTH | No | Max diagram code length | 500000 |
| MCP_RATE_LIMIT_PER_MINUTE | No | HTTP rate limit per IP for diagram/MCP routes (0 = off) | 0 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_diagram_typesA | List supported diagram types with Kroki backend, description, and formats (same data as uml://types resource). Use when the client cannot read resources. |
| generate_uml_batchA | 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. |
| generate_umlA | Generate any UML or diagram by type (class, sequence, mermaid, d2, etc.) |
| validate_umlA | Validate a diagram by compiling it on the renderer. Runs local structure checks first, then a real Kroki compile, so |
| render_diagramA | Render a diagram and return it as an MCP image plus the server-side file path. Use this instead of generate_uml when the figure should appear in chat or be uploaded: the image needs no base64 copying in the conversation, and local_path is a file the wiki writer can upload directly. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| uml_diagram | Base prompt for UML diagram generation |
| uml_diagram_with_thinking | Prompt for generating UML diagrams with plan-then-generate. Same workflow as uml_diagram (plan first, then code and generate_uml), plus explicit planning instructions and optional sequential-thinking MCP guidance. |
| class_diagram | Prompt for generating UML class diagrams |
| sequence_diagram | Prompt for generating UML sequence diagrams |
| activity_diagram | Prompt for generating UML activity diagrams |
| usecase_diagram | Prompt for generating UML use case diagrams |
| mermaid_sequence_api | Prompt for a Mermaid sequenceDiagram showing a typical API call: client, API, optional auth/DB, request/response, and optional alt block. |
| mermaid_gantt | Prompt for a Mermaid gantt chart with title, dateFormat, sections, and tasks. |
| bpmn_process_guide | Prompt that instructs the model to explain how to draw a BPMN process model: start/end events, tasks, gateways, sequence flow, lanes, aligned with BPMN 2.0.2. Optionally point to uml://templates (key bpmn), uml://examples (key bpmn), and generate_uml. |
| c4_model | Task-specific guidance for C4 via Kroki c4plantuml backend (aligned with uml://templates key c4plantuml). |
| wireviz_harness | Aligned with uml://templates and uml://examples for wireviz. |
| bpmn_executable_process | Task-first BPMN XML; aligned with uml://templates (key bpmn). |
| convert_class_to_mermaid | Prompt for converting a class diagram (PlantUML or prose) into Mermaid classDiagram. Instructs to output Mermaid classDiagram and optionally call generate_uml("mermaid", code). |
| algorithm_explainer | Task-focused prompt for explaining algorithms as diagrams. Steers the model through (1) picking a diagram shape that matches the algorithm's structure, (2) labeling each step with its complexity, and (3) using layout directives that reduce crossing arrows. Then call `generate_uml` with the chosen `diagram_type` and the raw source. |
| paper_concept_diagram | Task-focused prompt for academic-paper concept diagrams with clickable citation links. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| get_diagram_types | Get available diagram types |
| get_diagram_templates | Get diagram templates for different diagram types |
| get_diagram_examples | Get diagram examples for different diagram types |
| get_output_formats | Get supported output formats for each diagram type |
| get_capabilities | Type → backend → formats matrix for tooling and clients. |
| get_server_info | Get MCP server information |
| get_diagram_recipes | Return curated starter recipes that map a use case to a ready-to-edit source body. |
| get_recommended_workflow | Return the recommended workflow: plan first, then call generate_uml. |
TDQS
Scored across 5 tools
Each tool has a mostly distinct role: listing types, single generate, batch generate, validate, and render. The main ambiguity is between generate_uml and render_diagram, but the description explicitly steers usage ('use this instead of generate_uml when the figure should appear in chat'), which resolves most misselection risk.
All names follow a snake_case verb_noun pattern (list_diagram_types, generate_uml, generate_uml_batch, validate_uml, render_diagram). Minor inconsistency: three tools use the '_uml' resource suffix while render_diagram uses '_diagram', but the convention remains readable and predictable.
Five tools is well-scoped for a diagram generation server, with each tool earning its place (discovery, single gen, batch gen, validation, image rendering). No obvious padding or redundancy.
The core lifecycle (discover types, generate, batch, validate, render to image/file) is covered with no dead ends. Minor gaps exist around managing generated artifacts (e.g., listing or cleaning up previously written output files), but agents can work around this.