Skip to main content
Glama

Generate Visual

generate_visual
Read-only

Generates a visual (flowchart, mindmap, matrix, timeline, Gantt, ER, sequence, swimlane, block diagram) as a self-contained SVG. Powered by Jeda.ai · Visual AI.

REQUIRED post-processing on every success: the response's FIRST text block is a "SAVE THIS NOW" directive with a curl -fsSL one-liner (Step 1) and an inline-SVG fallback (Step 2). Always attempt Step 1 first; only fall back to Step 2 if curl exits non-zero. The user expects an "Image · SVG" file chip — not a markdown link or prose summary. The signed URL is safe to fetch (auth is in the query string).

Two modes: (1) natural-language prompt → Data Agent + Design Agent build the visual; (2) structured nodes + edges for precise control.

Visual types: matrix | mindmap | flowchart | block-diagram | timeline | gantt | er-diagram | sequence | process-flow. Default: auto-detected from prompt. Slash commands work too: /matrix SWOT, /timeline roadmap, /process-flow procurement approval with finance and legal lanes.

For style options (themes, fonts, arrow styles, animations, per-edge overrides, matrix/process-flow specifics) call get_style_options first. Default theme is pastel — only override when the user explicitly names another.

Example: { "prompt": "user signup with email verification", "theme": { "preset": "pastel" } }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYesDiagram type. Required when providing structured nodes/edges, optional with prompt.
edgesYes
nodesYesStructured node definitions. Required when not using prompt mode.
radarYesRadar/spider-chart payload. Required when type="radar". Fields: axes (string[], 3..50), series ({name, values: number[]}[], 1..10), maxValue (default 100), rings (default 4). Use multiple series for comparison overlays — first solid, rest dashed at 50% opacity.
styleYes
themeYes
titleYes
funnelYesFunnel-only payload. Required when type="funnel". Fields: stageLabels (string[], 1..50, ordered top→bottom), stageValues (optional string[]), dropOff (optional string[] of length stageLabels-1), bottomRatio (0.05..0.99, default 0.30). Sales pipeline, AARRR, ToFu/MoFu/BoFu.
layoutYes
promptYesNatural language description of the diagram to generate. When provided, the server uses AI to convert this into a structured diagram spec. Max 8000 characters. Example: "flowchart showing user login with validation and error handling"
pyramidYesPyramid-only payload. Required when type="pyramid". Fields: tierLabels (string[], 1..50, ordered base→tip), tierValues (optional string[]), inverted (boolean), tipRatio (0..0.95, default 0.15). Bloom's Taxonomy, Maslow's Hierarchy, Capability Maturity, DIKW.
metadataYesVisual-size + Best-fit metadata bag (v1.65.4 -> v1.67.12). All fields optional; legacy callers without `metadata` are byte-identical to today. The server echoes `metadata.size` back on the response so integrators can confirm the field was honoured.
sectionsYesMatrix sections. Each section has a title, optional subtitle, and items. Used with type="matrix".
subtitleYes
iconStyleYesIcon rendering style. "clean-mono" = precise strokes + single color, "clean-colorful" = precise strokes + vibrant colors, "calligraphy-mono" = hand-drawn ink + single color, "calligraphy-colorful" = hand-drawn ink + vibrant colors, "none" = hide icons.
fontFamilyYesFont family for diagram text. Options: inter, poppins (sans-serif); playfair (serif); kalam, handlee (handwritten); fredoka (display); mono (monospace). Omit for style-matched default (Handlee for calligraphy, Inter for clean).
matrixRowsYesRow header labels for 2D matrix grid (e.g., ["High Execution", "Low Execution"]).
shapeStyleYes
xAxisLabelYesX-axis title for 2D matrix grid (e.g., "Completeness of Vision").
yAxisLabelYesY-axis title for 2D matrix grid (e.g., "Ability to Execute").
defaultShadowYesDefault shadow level applied to all nodes.
ganttHolidaysYesGantt-only: ISO 8601 holiday dates (e.g. ["2026-12-25", "2026-01-01"]). Rendered as gray vertical stripes alongside Sat/Sun (always weekend). Only applies in date-driven mode (every node has start/end). Other diagram types ignore this field.
matrixColumnsYesColumn header labels for 2D matrix grid (e.g., ["High Vision", "Low Vision"]).
matrixItemStyleYesItem display style for matrix diagrams. "card" (default) = rectangular cards, "dot" = scatter points, "text" = plain text, "badge" = compact pills.
defaultArrowHeadYesDefault arrowhead style applied to all edges that don't specify their own.
defaultConnectorYesDefault connector type applied to all edges that don't specify their own.
defaultLineStyleYesv1.45.2+ — Default DASH PATTERN applied to all edges that don't specify their own. Options: "solid" | "dashed" | "dotted" | "dash-dot" | "long-dash". Combines orthogonally with `defaultArrowStyle` (calligraphy/clean/block) for 15 total visual combinations. Legacy values "calligraphy" and "block-arrow" are still accepted for backward compat (the renderer maps them to defaultArrowStyle="calligraphy"/"block" with lineStyle="solid"); new callers should use `defaultArrowStyle` for the aesthetic mode.
defaultArrowStyleYesConnector aesthetic mode applied to all edges that don't set their own `arrowStyle`. Options: "calligraphy" (default — hand-drawn ink-ribbon connectors) | "clean" (standard stroked-line connectors) | "block" (chunky outlined block-arrow connectors with integrated triangular head). Orthogonal to defaultLineStyle (which now controls dash pattern only) — all 15 combinations of arrowStyle × lineStyle are valid.
defaultTitleStyleYesTitle decoration treatment. Options: "plain" (default, just the title text), "accent-bar" (small accent-coloured vertical bar to the left of the title), "underline" (accent-coloured horizontal stroke below the title), "boxed" (title rendered in a subtle bordered + drop-shadowed pill — strongest framing). Affects only the diagram title, not subtitles or section headers.
defaultDividerStyleYesDivider / grid-line / table-border style. Governs the structural rule-lines a diagram emits: matrix grid lines, gantt phase column dividers, sequence lifelines, swimlane (process-flow) lane boundaries. Options: "subtle" (barely-there hairline), "normal" (default — pre-v1.55.0 baseline of 1 px / 25 % opacity), "bold" (emphasised grid presence), "dashed" (6,4 dasharray editorial feel), "dotted" (1,3 dasharray lightweight rhythm), "none" (no divider emission — cells separated only by colour banding). Useful for comparison tables (try "bold") or minimalist matrices (try "none").
defaultBlockArrowSizeYesDefault Block Arrow size when `defaultArrowStyle` (or per-edge arrowStyle) is "block". Options: "small" (slim — body ~14 px) | "medium" (default — body ~24 px) | "large" (chunky — body ~36 px). Or a raw body half-width number in px (1–60); head dimensions scale proportionally. Per-edge `blockArrowSize` overrides this default.
defaultSceneAnimationYesWhole-visual reveal animation. Plays ONCE when the SVG is displayed, freezes at the final state. Options: none (default) | fade (entire visual fades in) | zoom (scales in from 70% to 100%) | zoom-pan (Ken Burns camera move) | flow (each node + edge appears sequentially in spec order). Orthogonal to defaultConnectorAnimate — both can run together. SVG-only — PNG / WebP exports show the fully-revealed final state (rasteriser ignores SMIL; static attrs hold the final value). Animated GIF / MP4 client-side encoder ticks the scene through.
defaultShapeLineStyleYesDefault line style for shape outlines (node borders). v1.44.1 — also drives shape rendering mode: "calligraphy" gives hand-drawn rough shapes (ink-ribbon outlines); "solid" | "dashed" | "dotted" | "dash-dot" | "long-dash" give crisp geometric shapes with that outline pattern. Independent of edge/connector line style.
defaultConnectorAnimateYesAnimate every connector edge. Options: none (default) | flow (dashes march along the line) | pulse (gentle opacity breathing) | glow (subtle stroke-width pulse) | trace (bright dot traverses each edge) | wave (large stroke-width oscillation). SVG-only — exports to PNG / WebP / OG-image freeze on first frame.
defaultSceneAnimationLoopYesAnimation loop count. v1.50.9+ — applies to BOTH connector animations (flow / pulse / glow / wave / trace / lightning / beat / comet) AND scene animations (fade / zoom / zoom-pan / flow / wave-sweep / build-up / flow-zoom-pan). Options (all quoted strings): "once" (default — plays once and freezes) | "2" | "3" | "5" (repeat that many times then freeze) | "infinite" (loop forever; best for live presentations and the historical default for connector animations pre-v1.50.9). Maps to SMIL repeatCount.
defaultSceneAnimationSpeedYesScene animation speed. Options: slow (1.5× duration) | medium (default) | fast (0.6× duration).
defaultConnectorAnimateSpeedYesAnimation speed when defaultConnectorAnimate is set. Options: slow (3s cycle) | medium (2s, default) | fast (1s).

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already provide readOnlyHint, openWorldHint, etc. The description adds extensive behavioral details beyond annotations: the response format (SVG with a 'SAVE THIS NOW' directive), the curl fallback mechanism, two operational modes, and the default theme. No contradiction with annotations aside from the readOnlyHint issue noted separately.

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?

The description is lengthy and includes detailed post-processing instructions, which could be more concise. However, it is well-structured with clear sections (what it generates, post-processing, modes, types, style reference, example), aiding readability for an AI agent.

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?

Given the complex tool with 37 parameters and no output schema, the description covers the essential behavioral aspects: output format, required post-processing, modes, and a style options reference. It does not detail error handling, but the schema constraints and known alternatives (get_style_options) mitigate that gap.

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 81%, so the input schema already provides detailed descriptions for most parameters. The tool description adds a concrete example and mentions two modes, but does not significantly augment the parameter semantics beyond what the schema already provides. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates a visual as a self-contained SVG and lists many diagram types. It mentions two modes (prompt-based or structured nodes/edges), which clarifies scope. However, it does not explicitly differentiate from the sibling tool 'generate_diagram', which likely overlaps in purpose.

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 description provides explicit guidance on when to use the tool (for generating visuals via prompt or structured input) and when to use an alternative (calling get_style_options for style configuration). It also includes required post-processing steps and default theme advice, making usage very clear.

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.

TDQS

A4.4/5.0
Disambiguation3/5

Tools are mostly distinct but generate_diagram is a deprecated alias for generate_visual, creating potential confusion. Additionally, generate_framework_analysis and generate_visual both produce SVG visuals, though their intended use cases differ. An agent might struggle to choose between them without context.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: generate_diagram, generate_framework_analysis, generate_visual, get_style_options, recommend_framework. The naming is predictable and clear.

Tool Count5/5

With 5 tools, the server is well-scoped for its purpose of generating visuals and framework analyses. Each tool serves a distinct role without unnecessary duplication.

Completeness4/5

The tool surface covers the main workflows: framework recommendation, analysis with visual output, general visual generation, and style configuration. Minor gaps like lack of a tool to list all frameworks or manage past outputs exist, but core functionality is covered.

Resources