jeda-ai
Server Details
Visual AI for strategic thinking — SWOT, flowcharts, mindmaps, Gantt diagrams as polished SVG.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 5 of 5 tools scored. Lowest: 3.7/5.
Tools have mostly distinct purposes, but the deprecated `generate_diagram` (alias for `generate_visual`) introduces potential ambiguity. Additionally, `generate_framework_analysis` also produces SVG visuals, overlapping with `generate_visual`. Detailed descriptions help agents choose correctly, but the overlap slightly reduces clarity.
All tool names use lowercase_snake_case and follow a verb_noun pattern (`generate_*`, `get_*`, `recommend_*`). However, `generate_diagram` and `generate_visual` are nearly identical, and the deprecated nature of `generate_diagram` is a naming inconsistency. Overall, the pattern is mostly consistent.
With 5 tools, the server is well-scoped for generating visuals and analyzing business frameworks. The count feels appropriate—not too few to be incomplete, nor too many to be unwieldy. The deprecated tool slightly inflates the count but does not detract significantly.
The toolset covers the core workflows: recommending a framework, analyzing it with a visual, and generating custom visuals with style options. A minor gap is the lack of a tool to list or browse available frameworks without relying on recommendations, and the deprecated tool's duplicate functionality could be removed. Overall, the surface is reasonably complete.
Available Tools
5 toolsgenerate_diagramGenerate Diagram (deprecated)ARead-onlyIdempotentInspect
DEPRECATED alias for generate_visual (removed no earlier than v1.24.x). Use generate_visual going forward — identical behaviour.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Diagram type. Required when providing structured nodes/edges, optional with prompt. | |
| edges | Yes | ||
| nodes | Yes | Structured node definitions. Required when not using prompt mode. | |
| radar | Yes | Radar/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. | |
| style | Yes | ||
| theme | Yes | ||
| title | Yes | ||
| funnel | Yes | Funnel-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. | |
| layout | Yes | ||
| prompt | Yes | Natural 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" | |
| pyramid | Yes | Pyramid-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. | |
| metadata | Yes | Visual-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. | |
| sections | Yes | Matrix sections. Each section has a title, optional subtitle, and items. Used with type="matrix". | |
| subtitle | Yes | ||
| iconStyle | Yes | Icon 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. | |
| fontFamily | Yes | Font 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). | |
| matrixRows | Yes | Row header labels for 2D matrix grid (e.g., ["High Execution", "Low Execution"]). | |
| shapeStyle | Yes | ||
| xAxisLabel | Yes | X-axis title for 2D matrix grid (e.g., "Completeness of Vision"). | |
| yAxisLabel | Yes | Y-axis title for 2D matrix grid (e.g., "Ability to Execute"). | |
| defaultShadow | Yes | Default shadow level applied to all nodes. | |
| ganttHolidays | Yes | Gantt-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. | |
| matrixColumns | Yes | Column header labels for 2D matrix grid (e.g., ["High Vision", "Low Vision"]). | |
| matrixItemStyle | Yes | Item display style for matrix diagrams. "card" (default) = rectangular cards, "dot" = scatter points, "text" = plain text, "badge" = compact pills. | |
| defaultArrowHead | Yes | Default arrowhead style applied to all edges that don't specify their own. | |
| defaultConnector | Yes | Default connector type applied to all edges that don't specify their own. | |
| defaultLineStyle | Yes | v1.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. | |
| defaultArrowStyle | Yes | Connector 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. | |
| defaultTitleStyle | Yes | Title 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. | |
| defaultDividerStyle | Yes | Divider / 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"). | |
| defaultBlockArrowSize | Yes | Default 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. | |
| defaultSceneAnimation | Yes | Whole-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. | |
| defaultShapeLineStyle | Yes | Default 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. | |
| defaultConnectorAnimate | Yes | Animate 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. | |
| defaultSceneAnimationLoop | Yes | Animation 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. | |
| defaultSceneAnimationSpeed | Yes | Scene animation speed. Options: slow (1.5× duration) | medium (default) | fast (0.6× duration). | |
| defaultConnectorAnimateSpeed | Yes | Animation speed when defaultConnectorAnimate is set. Options: slow (3s cycle) | medium (2s, default) | fast (1s). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds no further behavioral context beyond 'identical behaviour,' which is too vague to be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with two sentences that deliver the essential deprecation message. Every word adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is deprecated and redirects to `generate_visual`, the description is adequate for its purpose. However, for a full tool definition with 37 parameters, it lacks context about usage, behavior, and return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (81%), so the schema already documents most parameters. The description adds no parameter-specific information, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a deprecated alias for `generate_visual`, which implies the same purpose of generating diagrams. However, it does not elaborate on the specific verb or resource, relying on the user knowing `generate_visual`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to use `generate_visual` going forward, providing a clear alternative and avoiding misuse of the deprecated tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_framework_analysisGenerate Framework AnalysisARead-onlyInspect
Runs a specific framework against a user's inputs and produces a full analysis: prose explanation + structured fields + a self-contained SVG visualisation. Powered by the Jeda.ai · Visual AI framework knowledge graph.
ALWAYS call recommend_framework FIRST to obtain a valid framework_id -- it returns the exact namespaced slug to pass here. Framework ids are namespaced by category (e.g. SWOT = "cms_swot-analysis", Porter's 5 Forces = "cms_porters-five-forces"); a bare slug like "swot-analysis" will 404.
REQUIRED post-processing on success: the response's first text block contains a curl -fsSL save-directive for the SVG. Save the file locally and surface it as a file chip — do NOT summarise the visual in prose.
Input: framework_id (namespaced slug from recommend_framework) + user_inputs object (per-framework field set), OR a free-text raw_prompt fallback.
Example: { "framework_id": "cms_swot-analysis", "user_inputs": { "subject": "Q3 EU market entry", "context": "B2B SaaS, $5M ARR, US-headquartered" } }
| Name | Required | Description | Default |
|---|---|---|---|
| theme | No | Theme preset for the SVG render. Default: pastel. | |
| raw_prompt | No | Optional free-text prompt that REPLACES the auto-derived prompt. | |
| user_inputs | No | Object whose keys match the framework user-input form fields. | |
| framework_id | Yes | Namespaced framework slug (e.g. "cms_swot-analysis"). Get one from `recommend_framework` -- bare slugs like "swot-analysis" are not valid ids. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true (no side effects). The description adds behavioral context: the SVG save directive and the fact that raw_prompt replaces auto-derived prompt. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections for purpose, prerequisites, post-processing, and input details. Slightly verbose but every sentence is informative and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (4 params, nested objects, special prerequisite, no output schema), the description thoroughly covers workflow, example, and post-processing. All necessary context for correct invocation is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant meaning: explains that framework_id must be namespaced and obtained from recommend_framework, user_inputs is per-framework field set, and provides an illustrative example with valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a specific framework against user inputs to produce a full analysis including prose, structured fields, and an SVG visualization. It distinguishes itself from siblings like recommend_framework (which provides the id) and generate_diagram/generate_visual (different output types).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call recommend_framework FIRST to get a valid namespaced framework_id, warns that bare slugs will 404, and details required post-processing for the SVG. Provides clear when-to-use and prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_visualGenerate VisualARead-onlyInspect
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" } }
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Diagram type. Required when providing structured nodes/edges, optional with prompt. | |
| edges | Yes | ||
| nodes | Yes | Structured node definitions. Required when not using prompt mode. | |
| radar | Yes | Radar/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. | |
| style | Yes | ||
| theme | Yes | ||
| title | Yes | ||
| funnel | Yes | Funnel-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. | |
| layout | Yes | ||
| prompt | Yes | Natural 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" | |
| pyramid | Yes | Pyramid-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. | |
| metadata | Yes | Visual-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. | |
| sections | Yes | Matrix sections. Each section has a title, optional subtitle, and items. Used with type="matrix". | |
| subtitle | Yes | ||
| iconStyle | Yes | Icon 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. | |
| fontFamily | Yes | Font 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). | |
| matrixRows | Yes | Row header labels for 2D matrix grid (e.g., ["High Execution", "Low Execution"]). | |
| shapeStyle | Yes | ||
| xAxisLabel | Yes | X-axis title for 2D matrix grid (e.g., "Completeness of Vision"). | |
| yAxisLabel | Yes | Y-axis title for 2D matrix grid (e.g., "Ability to Execute"). | |
| defaultShadow | Yes | Default shadow level applied to all nodes. | |
| ganttHolidays | Yes | Gantt-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. | |
| matrixColumns | Yes | Column header labels for 2D matrix grid (e.g., ["High Vision", "Low Vision"]). | |
| matrixItemStyle | Yes | Item display style for matrix diagrams. "card" (default) = rectangular cards, "dot" = scatter points, "text" = plain text, "badge" = compact pills. | |
| defaultArrowHead | Yes | Default arrowhead style applied to all edges that don't specify their own. | |
| defaultConnector | Yes | Default connector type applied to all edges that don't specify their own. | |
| defaultLineStyle | Yes | v1.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. | |
| defaultArrowStyle | Yes | Connector 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. | |
| defaultTitleStyle | Yes | Title 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. | |
| defaultDividerStyle | Yes | Divider / 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"). | |
| defaultBlockArrowSize | Yes | Default 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. | |
| defaultSceneAnimation | Yes | Whole-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. | |
| defaultShapeLineStyle | Yes | Default 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. | |
| defaultConnectorAnimate | Yes | Animate 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. | |
| defaultSceneAnimationLoop | Yes | Animation 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. | |
| defaultSceneAnimationSpeed | Yes | Scene animation speed. Options: slow (1.5× duration) | medium (default) | fast (0.6× duration). | |
| defaultConnectorAnimateSpeed | Yes | Animation speed when defaultConnectorAnimate is set. Options: slow (3s cycle) | medium (2s, default) | fast (1s). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and the description adds key behaviors: required post-processing (curl one-liner), behavior of animations (SVG-only, frozen in exports), default theme, and signed URL safety. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably structured with clear sections (purpose, post-processing, modes, types, example) but is verbose. It could be more concise while retaining essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 37 parameters and no output schema, the description covers main modes and post-processing but lacks details on error handling, return value structure, or edge cases. It adequately conveys the outputs (SVG) but could be more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 81% (high), so baseline is 3. The description adds contextual value by explaining the two modes and giving examples, but does not significantly expand on parameter details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 SVG, listing specific types (flowchart, mindmap, etc.). It distinguishes itself from siblings by covering a wide range of diagram types and mentioning two modes (prompt vs structured).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the prompt mode vs nodes/edges, and advises calling get_style_options for style options. It lacks explicit differentiation from siblings like generate_diagram, but the context implies this is the comprehensive visual tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_style_optionsGet Style Options for generate_visualARead-onlyIdempotentInspect
Returns the full style-options catalog for generate_visual — theme presets, fonts, arrow styles, line styles, arrowheads, scene/connector animations, layout directions, per-edge overrides, and matrix/process-flow specifics. Call this once when you need to expose specific style choices to the user (e.g. "what themes are available?") or before composing a generate_visual call that needs non-default styling. Output is plain text, ~4 KB.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Diagram type. Required when providing structured nodes/edges, optional with prompt. | |
| edges | Yes | ||
| nodes | Yes | Structured node definitions. Required when not using prompt mode. | |
| radar | Yes | Radar/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. | |
| style | Yes | ||
| theme | Yes | ||
| title | Yes | ||
| funnel | Yes | Funnel-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. | |
| layout | Yes | ||
| prompt | Yes | Natural 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" | |
| pyramid | Yes | Pyramid-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. | |
| metadata | Yes | Visual-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. | |
| sections | Yes | Matrix sections. Each section has a title, optional subtitle, and items. Used with type="matrix". | |
| subtitle | Yes | ||
| iconStyle | Yes | Icon 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. | |
| fontFamily | Yes | Font 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). | |
| matrixRows | Yes | Row header labels for 2D matrix grid (e.g., ["High Execution", "Low Execution"]). | |
| shapeStyle | Yes | ||
| xAxisLabel | Yes | X-axis title for 2D matrix grid (e.g., "Completeness of Vision"). | |
| yAxisLabel | Yes | Y-axis title for 2D matrix grid (e.g., "Ability to Execute"). | |
| defaultShadow | Yes | Default shadow level applied to all nodes. | |
| ganttHolidays | Yes | Gantt-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. | |
| matrixColumns | Yes | Column header labels for 2D matrix grid (e.g., ["High Vision", "Low Vision"]). | |
| matrixItemStyle | Yes | Item display style for matrix diagrams. "card" (default) = rectangular cards, "dot" = scatter points, "text" = plain text, "badge" = compact pills. | |
| defaultArrowHead | Yes | Default arrowhead style applied to all edges that don't specify their own. | |
| defaultConnector | Yes | Default connector type applied to all edges that don't specify their own. | |
| defaultLineStyle | Yes | v1.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. | |
| defaultArrowStyle | Yes | Connector 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. | |
| defaultTitleStyle | Yes | Title 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. | |
| defaultDividerStyle | Yes | Divider / 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"). | |
| defaultBlockArrowSize | Yes | Default 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. | |
| defaultSceneAnimation | Yes | Whole-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. | |
| defaultShapeLineStyle | Yes | Default 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. | |
| defaultConnectorAnimate | Yes | Animate 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. | |
| defaultSceneAnimationLoop | Yes | Animation 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. | |
| defaultSceneAnimationSpeed | Yes | Scene animation speed. Options: slow (1.5× duration) | medium (default) | fast (0.6× duration). | |
| defaultConnectorAnimateSpeed | Yes | Animation speed when defaultConnectorAnimate is set. Options: slow (3s cycle) | medium (2s, default) | fast (1s). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is safe and idempotent. The description adds that the output is plain text (~4 KB), providing useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. The first lists the catalog contents, the second gives usage context and output format. No wasted words, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that simply returns a style catalog, the description covers what it returns, when to use it, and the output nature (plain text, ~4 KB). No output schema needed; the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 37 parameters with 81% description coverage, so the schema already documents them. The description does not add meaning for individual parameters; it focuses on the output. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool returns the style-options catalog for generate_visual, listing all categories. It distinguishes from siblings by being an informational helper for style choices, not a generation tool. The usage guidance is clear: call before generating with non-default styling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use it: before exposing style choices to the user or composing a generate_visual call with non-default styling. It implies when not needed (default styling). However, it does not explicitly mention alternatives among siblings, though the context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_frameworkRecommend FrameworkARead-onlyIdempotentInspect
Recommends business / strategy / risk frameworks for a stated problem. Powered by the Jeda.ai · Visual AI framework knowledge graph (~2,100 frameworks across 19 categories, edge-curated).
Use when the user describes a business problem ("customer churn rising", "evaluating market entry", "need to assess vendor risk") rather than naming a specific framework. Returns top-N frameworks ranked by fit, each with a concrete reason citing the specific problem signals matched.
Input: just the problem statement is enough. Optional faceted filters (persona, regulation, decision_stage) narrow the candidate set. Set limit between 3 and 10 for picker UIs.
Pair with generate_framework_analysis to actually run a recommended framework against the user's inputs.
Example: { "problem_statement": "We need to decide whether to enter the EU SMB market in Q3", "decision_stage": "decide", "limit": 5 }
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of frameworks to return. Default 5; cap 20. | |
| persona | No | Persona slug (e.g. "ciso", "pm", "cfo"). | |
| regulation | No | Regulation slug (e.g. "sox", "gdpr", "iso-31000"). | |
| decision_stage | No | Decision-lifecycle stage. | |
| problem_statement | Yes | Plain-English description of the business problem. 10–2000 chars. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide read-only, idempotent, non-destructive hints. Description adds that it returns ranked frameworks with reasons, optional filters, and includes an example. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose, then source, usage, input details, pairing suggestion, and example. No wasted text, each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description thoroughly explains input requirements, output characteristics (ranked with reasons), and complementary tool. Complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3. Description adds meaning by explaining optional filters narrow candidates, typical limit range (3-10), and provides an example, enhancing beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool recommends business/strategy/risk frameworks for a stated problem, specifies the knowledge graph source, and distinguishes from sibling tools like generate_framework_analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use when the user describes a business problem rather than naming a specific framework, and pairs with generate_framework_analysis for execution. Provides clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!