Skip to main content
Glama
mohammad-emad-dev

diagrams-mcp-server

by mohammad-emad-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Export Diagram as a Self-Contained HTML File

diagrams_export
Read-onlyIdempotent

Package a stored PlantUML or Mermaid diagram with its rendered SVG into one self-contained HTML file for sharing or opening outside the repo, with optional source and offline use.

Instructions

Package a stored PlantUML or Mermaid diagram and its rendered SVG into one self-contained HTML file you can share or open outside the repo. The SVG is encoded as a data image, so renderer markup is not parsed into the HTML DOM. SVG image processing disables scripts and external resource loading. A restrictive content security policy allows only data images and inline wrapper styles. SVG text is not selectable in the exported image. Diagram source is escaped in a native collapsible block when include_source is set, and the artifact works offline without new dependencies.

Rendering uses the same path and the same rules as diagrams_render: Mermaid requires the local 'mmdc' CLI with no fallback, and PlantUML prefers a local 'plantuml' CLI, falling back to the configured remote server only when ALLOW_REMOTE_PLANTUML=true and DISABLE_REMOTE_PLANTUML is not 'true'. Remote PlantUML rendering sends diagram source to that server over HTTPS.

The tool never writes a file: the HTML comes back as text and you decide where it lands. A bundle larger than 5000000 bytes is refused outright rather than cut down, because a half-rendered artifact is worse than none.

Args:

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

  • include_source (boolean, default true): Embed the diagram source in a collapsible block

Returns: The HTML as a text content block, plus a JSON summary: { "relative_path": string, // POSIX form, the only path in the bundle "diagram_type": "plantuml" | "mermaid", "format": "html", "bytes": number, // UTF-8 byte length of the returned HTML "svg_chars": number, // image source characters after XML preamble stripping, before base64 encoding "source_included": boolean, // whether the source block was embedded "truncated": false, // always false; over-cap is an error, never a cut file "rendered_with": "local-plantuml" | "remote-plantuml" | "mmdc" }

Examples:

  • Use when: "Package the order-flow diagram so I can send it to someone without the repo" -> relative_path="system/order-flow.puml"

  • Use when: "Give me a standalone HTML of the checkout sequence" -> relative_path="system/checkout.mmd", include_source=false

  • Don't use when: You want the image alone (use diagrams_render, which returns an image block)

  • Don't use when: You want to edit the diagram (use diagrams_get and diagrams_update)

Error Handling:

  • Returns "Error: Local renderer image exceeded the 5000000-byte limit..." for oversized local SVG output before HTML bundling

  • Returns "Error: No diagram found at ''" if the diagram does not exist, before any render is attempted

  • Returns "Error: Mermaid rendering requires the 'mmdc' CLI..." when rendering a Mermaid diagram without mmdc installed (no fallback exists)

  • 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 ..." when the opt-in remote fallback answers non-2xx

  • Returns "Error: The export bundle for '' is bytes, larger than the 5000000-byte limit, so it was not returned..." when the finished bundle exceeds the cap

  • 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
relative_pathYesPath to the diagram to export, relative to the diagrams root.
include_sourceNoEmbed the diagram source in a collapsible block so the artifact explains itself (default: true). The block is a native <details> element, so it works without JavaScript.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.0

TDQS

A4.7/5.0
Behavior5/5

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

With readOnly/destructive/idempotent annotations already covering the safety profile, the description adds substantial context beyond them: it never writes a file, the result is returned as text, the 5000000-byte cap is enforced as an error not truncation, remote PlantUML rendering requires ALLOW_REMOTE_PLANTUML=true, and Mermaid has no fallback without mmdc. It also discloses security behavior such as data-image encoding, CSP restrictions, and disabled script/external-resource loading. These are meaningful operational traits not present in the structured annotations.

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 front-loaded with the core purpose, then moves through rendering rules, return behavior, args, examples, and errors in a structured way. Although detailed, the length matches the complexity of the tool and each section earns its place by covering a distinct operational concern.

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?

There is no output schema, but the description fully documents the returned text and JSON summary fields, as well as expected error messages and the 5000000-byte cap. Combined with annotations that cover safety hints, the definition gives an agent everything needed to invoke the tool 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%, so the input schema already documents both parameters. The description's Args section largely repeats relative_path and include_source semantics, adding only minor context about the collapsible block and default. The baseline of 3 is appropriate when the schema carries the parameter documentation.

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 first sentence states a specific verb and resource: package a stored PlantUML or Mermaid diagram plus rendered SVG into a self-contained HTML file. It distinguishes the tool from siblings by later naming diagrams_render for image-only output and diagrams_get/diagrams_update for editing. An agent can identify it as the export-to-HTML tool without opening another schema.

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?

The Examples section gives explicit 'Use when' cases and 'Don't use when' cases with named alternatives: diagrams_render for an image alone and diagrams_get/diagrams_update for edits. This leaves no ambiguity about when to select this tool versus sibling tools.

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