Skip to main content
Glama

Save Diagram Export as HTML File

diagrams_save_export

Save a PlantUML or Mermaid diagram as a self-contained HTML file in the diagrams root, with optional embedded source and no overwrite.

Instructions

Save a stored PlantUML or Mermaid diagram as one self-contained HTML file inside the diagrams root. 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 finished bundle is measured before the output directories or file are created. A bundle larger than 5000000 bytes is refused. The target must end in .html (case-insensitive) and must not exist: existing files are refused atomically, never overwritten. Saved HTML files are excluded from diagram listing and CRUD tools. To replace an export, choose a different output_path or remove the existing target yourself.

Args:

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

  • output_path (string, required): Path for the saved HTML file, relative to the diagrams root, ending in .html

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

Returns: A short acknowledgement as a text content block (not the HTML itself), plus a JSON summary: { "relative_path": string, // POSIX form of the source diagram "output_path": string, // POSIX form of the saved HTML file "diagram_type": "plantuml" | "mermaid", "format": "html", "bytes": number, // UTF-8 byte length of the saved 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: "Save the order-flow diagram as HTML inside the repo" -> relative_path="system/order-flow.puml", output_path="exports/order-flow.html"

  • Use when: "Save a standalone HTML of the checkout sequence without source" -> relative_path="system/checkout.mmd", output_path="exports/checkout.html", include_source=false

  • Don't use when: You want the HTML text back without writing a file (use diagrams_export, which returns the bundle and writes nothing)

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

Error Handling:

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

  • 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 saved..." when the finished bundle exceeds the cap, with nothing written

  • Returns "Error: HTML export '' already exists..." if the output file already exists; choose another output_path or remove the target yourself

  • Returns "Error: '' does not have the .html export extension..." if output_path does not end in .html

  • Returns "Error: Refused to access path outside the diagrams root" if relative_path or output_path attempts to escape the diagrams directory

  • 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
output_pathYesPath for the saved HTML file, relative to the diagrams root, ending in .html (case-insensitive). Intermediate directories are created. Existing files are refused, never overwritten.
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.8/5.0
Behavior5/5

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

Annotations declare a non-readonly, non-idempotent, non-destructive, open-world write; the description goes well beyond them, disclosing the atomic never-overwrite refusal, the 5,000,000-byte cap checked before any file is created, the CSP/script/external-resource restrictions, the mmdc-with-no-fallback requirement, and the HTTPS remote-PlantUML opt-in. This is exactly the extra context the annotations cannot carry, and nothing contradicts them.

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?

Front-loaded with the core purpose, then rendering rules, then caps and overwrite semantics; every section is purposeful. It is long, and the Args/Error Handling sections partly duplicate the prose above, but the density is justified by the number of distinct failure modes an agent must anticipate.

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?

Despite having no output schema, the description documents the return shape fully (text acknowledgement plus a JSON summary with bytes, svg_chars, source_included, truncated, rendered_with), enumerates ten distinct error strings, and covers path-escape refusal. Nothing an agent needs to invoke or recover from this tool is missing.

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?

Schema coverage is 100%, so the baseline is 3, and the description does add meaning: output_path must not exist and is refused atomically, the .html check is case-insensitive, and include_source's collapsible block is described as a native <details> element that works without JavaScript. The Args block largely restates the schema, which caps this below a 5.

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 and resource ('Save a stored PlantUML or Mermaid diagram as one self-contained HTML file inside the diagrams root') and immediately distinguishes itself from diagrams_export and diagrams_render via explicit 'Don't use when' routing. An agent can pick it out of a 14-sibling set without opening a 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?

Both positive examples ('Save the order-flow diagram as HTML inside the repo') and negative cases are given, with the alternative named and the selecting condition stated: diagrams_export returns the bundle without writing, diagrams_render returns the image alone. No inference required.

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