Skip to main content
Glama

Draw a diagram from Mermaid or an infographic spec

compose_diagram

Draws into an existing diagram as one agent change (revert_change can revert it): either a Mermaid flowchart (subgraphs become frames, or containers such as network.vpc when you map their ids; map ids, classes or "@shape" to node types with types; unmapped nodes become core.box; options layout, direction ("auto" picks the readable one), frame), or an infographic spec (infographic: theme + blocks; each block is { block, …the node type’s props }, e.g. header, kpi-row, chart, progress, funnel, timeline, process, icon-grid, versus, source) that the server measures and lays out on a 12-column poster — the spec gives data and order, not coordinates. Pie, xychart, timeline, quadrantChart and venn Mermaid diagrams become infographic blocks. It takes exactly one of mermaid and infographic. dryRun checks without writing; with dryRun, preview "light" or "dark" also returns a PNG (a poster exactly as export_diagram draws it). read_me topic "infographics" describes the blocks. Returns applied, seq, batchId, effects, bounds and warnings; Mermaid adds nodeIds, groupIds, edgeIds ("A->B" → edge id) and frameId plus the direction used, an infographic adds idMap, posterId, nodeIds, blocks (node ids and bounds), quota and layout, and each infographic warning’s fix says which span, field or poster size to change. status (≤ 80 characters) is shown to people next to your cursor.

Input Schema

NameRequiredDescriptionDefault
frameNo{ title } wraps a Mermaid drawing in a new frame; { id } puts the drawing or the poster inside an existing container (frame, namespace, VPC…) below its children and grows the container if needed.
typesNoMaps Mermaid node ids, subgraph ids, classes (":::name" / "class A name") or "@shape" (e.g. "@cylinder") to node types from search_node_types (e.g. {"db":"cloud.database","vpc":"network.vpc"}). A subgraph takes a container type (network.vpc, k8s.namespace, cloud.region, c4.system-boundary…). Unmapped nodes become core.box (non-rectangular Mermaid shapes become core.shape), unmapped subgraphs core.frame. Edges between mindmap.* or org.* nodes become mind-map branches / reporting lines.
dryRunNoCheck the drawing against the current state without writing. Ids in a dry-run result are placeholders; the call that writes returns the real ones.
layoutNoLayout engine (default layered).
statusNo
mermaidNoMermaid source: a flowchart ("flowchart LR" / "graph TD", subgraphs included), or a pie, xychart, timeline, quadrantChart or venn-beta chart, which is drawn as one infographic block. Other Mermaid diagram kinds are not supported; the error names the Archboard node types to use instead.
previewNoWith dryRun: also render a PNG (the whole poster, as export_diagram draws it).
diagramIdYesDiagram id (from list_diagrams or create_diagram).
directionNoFlow direction; overrides the Mermaid header. "auto" keeps the header direction unless the drawing gets much wider than tall (or taller than wide), then uses the other one; the result says which.
placementNoWhere to put the drawing: "auto" (default; right of existing content, or 0,0 on an empty canvas), "right", "below", or a top-left point { x, y } in world pixels.
infographicNoInfographic spec: theme + blocks; the server measures and lays the blocks out on a 12-column poster. Read read_me topic "infographics".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations: it declares the write is a single revertable agent change (revert_change), that dryRun writes nothing and returns placeholder ids, that preview renders a full poster PNG, and that warnings carry actionable fixes naming span, field or poster size. It also discloses quota and layout in the result, none of which the annotations convey.

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

Conciseness3/5

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

No filler, but the opening sentence is a single run-on covering both modes, nested parentheses and type mappings, which makes the wall of text harder to scan than the content warrants. Front-loading is good; formatting is not.

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 11 parameters, no output schema and nested objects, the description carries the right load: it enumerates the returned fields per mode (applied, seq, batchId, effects, bounds, nodeIds, idMap, posterId, quota, warnings) and explains the fallback typing rules. Nothing essential for a correct invocation 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 91%, so the schema already documents most parameters, but the description adds semantics the schema lacks: the types mapping behavior (unmapped nodes become core.box, subgraphs need container types), that 'auto' direction may flip and reports which was used, and that status is surfaced to people next to the cursor. The infographic spec is framed as data-and-order-only, which is genuine meaning beyond the nested schema.

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+resource (draws into an existing diagram) and immediately distinguishes the two supported inputs, Mermaid source or an infographic spec, with scope ('as one agent change') that separates it from create_diagram. An agent can tell what it draws and what it does not (other Mermaid kinds are rejected) 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly constrains input ('takes exactly one of mermaid and infographic'), explains dryRun-with-preview as an alternative to writing, and points to read_me topic "infographics" for block authoring. It doesn't compare itself to apply_ops or create_diagram for cases where those are the better path, so routing is strong but not exhaustive.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.