Skip to main content
Glama

Diagram to SVG/PNG

ai_diagram
Read-onlyIdempotent

Generate flowchart and graph diagrams from concise text or JSON, with automatic layout, and save them as SVG or PNG files.

Instructions

Draw a flowchart / graph diagram from a tiny text language and save it as SVG or PNG, laid out automatically (dagre). One statement per line: direction: LR (TB, LR, BT, RL), title: My flow, A [shape=diamond, label="Ready?", color=#fde68a] (shapes: box, round, diamond, circle, ellipse), edges A -> B: label, chains A -> B -> C, --> dashed, ==> thick, <-> both ends, -- no arrow; quote names with spaces ("Start here" -> A); \n in labels breaks lines; # starts a comment. Or pass JSON { nodes: [{id, label, shape, color}], edges: [{from, to, label, style, arrow}] } as "graph". Up to 500 nodes and 2000 edges. Labels use Helvetica/Arial metrics (Latin text is measured best).

Input Schema

NameRequiredDescriptionDefault
graphNoThe diagram as JSON instead of "source".
scaleNoPNG only: pixel density multiplier (2 = twice the SVG size, sharp on high-DPI screens). Default 2.
themeNolight
formatNoOutput format: svg (default) or png.svg
outputNoWhere to write the result: a file path, or a folder ending in "/". Default: the server output folder (a temp folder unless --out-dir is set).
sourceNoDiagram text in the DSL (or a JSON graph as text).
directionNoOverride the layout direction: TB (top-bottom, default), LR, BT, RL.
returnBase64NoAlso return the output as base64 in the result (only for small files). Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses the layout engine, hard limits (500 nodes, 2000 edges), the label-measurement caveat (Helvetica/Arial metrics, Latin text best), and that the default destination is a server output folder. The only notable silence is what the tool actually returns (path vs inline content), which the readOnlyHint does not cover.

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?

Purpose is front-loaded in the first clause, then the DSL grammar and limits follow in a single dense run-on. Every clause carries information, but the packed semicolon syntax makes it harder to scan than a short bulleted grammar would be.

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?

With 8 parameters, a nested object schema and no output schema, the description covers both input modes, size limits, layout behaviour, and destination defaults. The gap is the return contract (file path vs base64 payload) and the interplay of 'output' with 'returnBase64', which the agent must infer.

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 already 88%, but the description adds real value by fully specifying the DSL accepted by 'source' (direction, title, node shapes, edge operators, quoting, comments, line breaks) and the JSON shape for 'graph'. It says nothing extra about theme, scale, or returnBase64 beyond their schema descriptions, so it stops just short of 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 ('Draw a flowchart / graph diagram'), the output artifacts (SVG or PNG), and the layout engine (dagre). An agent can distinguish this from ai_chart (data charts) and image_svg_to_png (rasterising existing SVG) without opening the schema.

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 context is implied through the input modes ('tiny text language ... Or pass JSON ... as "graph"') and the limits, but there is no explicit statement of when this tool should be chosen over siblings like ai_chart or image_svg_to_png, and no when-not guidance. The agent must infer suitability from the diagram/DSL framing.

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