Skip to main content
Glama
mohammad-emad-dev

diagrams-mcp-server

by mohammad-emad-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Render Diagram to Image

diagrams_render
Read-onlyIdempotent

Render PlantUML or Mermaid diagrams to SVG or PNG and return base64-encoded image content. Use it to preview or inspect diagram output without reading raw source.

Instructions

Render a PlantUML or Mermaid diagram to an image (SVG or PNG) and return it as base64-encoded image content.

Rendering requirements:

  • Mermaid: requires the 'mmdc' CLI (install with: npm install -g @mermaid-js/mermaid-cli). No fallback exists.

  • PlantUML: uses a local 'plantuml' CLI if installed. Without one, rendering fails unless remote rendering is explicitly enabled with ALLOW_REMOTE_PLANTUML=true, in which case it falls back to the configured PlantUML rendering server over HTTPS (requires internet access; sends diagram source to that server). DISABLE_REMOTE_PLANTUML=true always disables the fallback, even when the allow flag is set.

Args:

  • relative_path (string): Path to the diagram, relative to the diagrams root

  • format ('svg' | 'png'): Output image format (default: 'svg')

Returns: An image content block (base64-encoded), plus a JSON summary: { "relative_path": string, "format": "svg" | "png", "rendered": true }

Examples:

  • Use when: "Show me what the order-flow diagram looks like" -> relative_path="system/order-flow.puml", format="svg"

  • Don't use when: You just need the raw source text (use diagrams_get instead, it's much cheaper)

Error Handling:

  • Returns "Error: Local renderer image exceeded the 5000000-byte limit..." for oversized local SVG or PNG output; simplify or split the diagram

  • Returns "Error: No diagram found at ''" if the file doesn't exist

  • Returns "Error: Mermaid rendering requires the 'mmdc' CLI..." if rendering a Mermaid diagram without mmdc installed

  • Returns "Error: PlantUML rendering requires a local 'plantuml' CLI..." when no local CLI is installed and remote rendering is not explicitly enabled (set ALLOW_REMOTE_PLANTUML=true to opt in)

  • Returns "Error: PlantUML rendering server responded with ..." if both local and remote PlantUML rendering fail

  • Unexpected internal failures return a generic "Error: Unexpected internal error ..." with isError:true and are logged to stderr without source, paths, or secrets

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNoOutput image format (default: 'svg').svg
relative_pathYesPath to the diagram to render, relative to the diagrams root.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare readOnly/idempotent/openWorld, but the description adds critical behavior they cannot: per-format CLI prerequisites (mmdc, plantuml), the remote-rendering fallback that sends diagram source over HTTPS, the env flags governing it, a 5MB output limit, and the exact user-facing error strings. That is substantial operational context beyond structured fields.

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?

Clearly sectioned (requirements, args, returns, examples, error handling) and front-loaded with the one-line purpose. Given the tool's environment-dependent complexity, every section earns its place and nothing is padded.

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?

With no output schema, the description still specifies the return value (base64 image block plus JSON summary) and enumerates the failure modes an agent should anticipate. For a tool with external CLI and network dependencies, this is complete enough to call correctly.

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% and both parameters are already documented in the schema (including the default and enum), so the description adds little semantic detail. The args and example mainly restate what the schema provides, making the baseline 3 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?

States a specific verb (Render), the resource (PlantUML/Mermaid diagram), the output format (SVG/PNG), and the return shape (base64 image content). It is immediately distinguishable from siblings like diagrams_get, which the description explicitly contrasts.

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?

Provides an explicit 'Use when' example mapping a natural-language request to concrete args, plus a 'Don't use when' rule routing to diagrams_get with a cost rationale ('much cheaper'). When/when-not/alternative are all covered.

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

Deploy Server

Other Tools