UML-MCP

Generate Diagram Image

generate_uml_image

Idempotent

Render diagram source code as an inline image for chat, returning a bounded preview plus render and playground links to inspect and share UML and other diagrams.

Instructions

Render a diagram as MCP ImageContent for chat with a bounded inline preview. Returns content_base64, mime_type, render and playground links. Fetches bytes even under URL-only. Large images use a PNG thumbnail in MCP Apps.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "diagram_type": "<diagram_type>",
      "code": "<code>"
    },
    "name": "generate_uml_image"
  }
}

Input Schema

Name	Required	Description	Default
`code`	Yes	Diagram source code in the syntax required by diagram_type.
`scale`	No	SVG scale factor; ignored unless output_format is svg.
`theme`	No	Optional theme: PlantUML name (e.g. cerulean), Mermaid default/dark/forest/neutral/base, D2 default/dark, or light/dark/bw.
`diagram_type`	Yes	Catalog key selecting the source language and renderer; discover keys with list_diagram_types.
`output_format`	No	Output format for the inline image; png (default), svg, or jpeg.	png

Output Schema

Name	Required	Description
`url`	No
`code`	Yes
`error`	No
`source`	No
`success`	No
`attempts`	No	Renderers tried, in order: backend, ok, status, duration_ms, error_summary, error_code, retry_count.
`cache_hit`	No
`mime_type`	No
`render_ms`	No
`local_path`	No
`playground`	No
`inline_note`	No
`diagram_type`	No
`error_detail`	No	Failed requests only: code, message, retryable, line, column, suggestion, diagram_type, backend.
`fallback_used`	No
`output_format`	No
`content_base64`	No	Bounded inline preview (max 48,000 base64 characters); larger images use a resized PNG preview when possible.
`inline_omitted`	No
`source_omitted`	No
`cache_lookup_ms`	No
`preview_resized`	No
`display_markdown`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.4.0Nov 5, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true, openWorldHint=true), the description discloses the payload shape (content_base64, mime_type, render and playground links) and two real behavioral traits: bytes are fetched even when the caller supplies a URL-only reference, and large images are silently downgraded to a PNG thumbnail in MCP Apps. That degradation behavior is exactly the kind of thing an agent could not infer from annotations. It does not cover failure modes or rate limits, keeping it below a 5.

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

Conciseness4/5

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

Four dense sentences, front-loaded with the core render action and the primary output before the edge cases. No filler, though phrases like "Fetches bytes even under URL-only" and "MCP Apps" are tersely stated and rely on the reader already knowing the surrounding tool family.

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?

An output schema exists, so the description need not explain return values, yet it usefully summarizes them anyway, and it flags format-specific behavior for the scale/theme/output_format parameters that live in the schema. The only real gap is routing guidance relative to the six sibling diagram 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%, with each of the five parameters documented inline (including diagram_type pointing to list_diagram_types and scale being ignored unless output_format is svg). The description adds no parameter-level meaning beyond that, so the baseline 3 is correct.

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?

"Render a diagram as MCP ImageContent for chat with a bounded inline preview" names a specific verb and the exact resource produced, so an agent can tell this is the image-returning variant rather than a link/text generator. It stops short of naming siblings like generate_uml or rerender_diagram, so the differentiation is inferable rather than explicit.

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?

Usage is implied by "for chat with a bounded inline preview" and by the thumbnail behavior in MCP Apps, so an agent can guess this is the tool for inline image display. However, there is no explicit statement of when to pick this over generate_uml, rerender_diagram, or download_diagram, and no exclusions or prerequisites are given.

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

Deploy Server