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/5 across 5 of 5 tools scored. Lowest: 3/5.
All tools have clearly distinct purposes: recommend_framework suggests frameworks, generate_framework_analysis runs a chosen framework, generate_visual produces generic visuals, get_style_options provides styling info, and generate_diagram is clearly marked as a deprecated alias. No overlap.
All tool names follow a consistent verb_noun pattern (e.g., generate_visual, recommend_framework) with lowercase and underscores. No mixing of conventions.
With 5 tools (one deprecated), the server is tightly scoped to visual generation and analysis. The count feels right for the domain—neither sparse nor bloated.
Core workflows are covered: framework recommendation, analysis with visual, generic visual generation, and style customization. A minor gap is the lack of a direct way to list all available framework IDs, though recommend_framework can be used for discovery.
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. | |
| 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?
Beyond stating 'identical behaviour' to generate_visual, the description adds no behavioral details. Annotations provide some hints, but the description itself is insufficient for understanding side effects or constraints.
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?
Two sentences with front-loaded 'DEPRECATED alias' – highly concise and efficient. Every word serves a purpose.
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?
Despite a complex input schema with 28 parameters and nested objects, the description provides almost no operational context. The agent would need to consult generate_visual for full understanding, making this inadequate.
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 description does not describe any parameters; with 82% schema coverage, the schema already handles parameter descriptions. Description adds no additional meaning, so baseline score of 3 applies.
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 identifies the tool as a deprecated alias for generate_visual, implying it generates diagrams. The verb 'generate' and resource 'diagram' are evident from the name and context, though not spelled out in the description.
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 directs agents to use generate_visual instead, providing clear when-to-use and when-not-to-use guidance. This is exemplary for a 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.
Required for any framework analysis flow. The companion tool recommend_framework returns framework_ids that are valid here. Pre-discovered framework_ids (SWOT = "swot-analysis", PESTEL = "pestel-analysis", Porter's 5 Forces = "porters-five-forces", etc.) work without a recommendation step.
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 (slug) + user_inputs object. The user_inputs schema is per-framework; call recommend_framework first if you don't know the field set, OR send a raw_prompt as a free-text fallback.
Example: { "framework_id": "swot-analysis", "user_inputs": { "subject": "Q3 EU market entry", "context": "B2B SaaS, $5M ARR, US-headquartered" } }
| Name | Required | Description | Default |
|---|---|---|---|
| theme | Yes | Theme preset for the SVG render. Default: pastel. | |
| raw_prompt | Yes | Optional free-text prompt that REPLACES the auto-derived prompt. | |
| user_inputs | Yes | Object whose keys match the framework user-input form fields. | |
| framework_id | Yes | Framework slug. Get one from `recommend_framework` or use a known slug. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true and openWorldHint=true. Description adds behavioral details: produces SVG requiring post-processing with a save-directive, and is powered by a knowledge graph. 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?
Description is well-structured: starts with core functionality, then usage context, then post-processing instructions, then parameter details. Slightly verbose but 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 tool complexity (4 params, no output schema), description covers tool purpose, usage flow, parameter details, output handling, and companion tool. Complete enough for correct agent invocation.
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?
All 4 parameters have descriptions in schema (100% coverage). Description additionally explains framework_id is a slug, gives known values, clarifies user_inputs is per-framework, and describes raw_prompt as fallback. Provides an example.
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 'Runs a specific framework against a user's inputs and produces a full analysis: prose explanation + structured fields + a self-contained SVG visualisation.' This distinguishes it from sibling tools like generate_diagram and recommend_framework, which have different purposes.
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 says 'Required for any framework analysis flow' and provides companion tool usage: 'The companion tool recommend_framework returns framework_ids that are valid here.' It also gives fallback instructions for raw_prompt and example known IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_visualGenerate VisualBRead-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. | |
| 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?
The description explicitly requires saving the SVG output as a file chip, indicating a side effect (file creation). This contradicts the annotation 'readOnlyHint: true', which suggests no side effects. Additional behavioral traits like auth needs or rate limits are not disclosed.
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 comprehensive but verbose, including lengthy details about post-processing and many style options. It is front-loaded with the main purpose, but could be more concise by reducing redundancy with the schema.
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's complexity (28 parameters, nested objects, no output schema), the description covers most aspects: modes, parameters, styles, and post-processing. However, it lacks explicit description of response structure or error handling, which is important for tool invocation.
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 (82%), so the baseline is 3. The description adds meaningful context beyond the schema, such as default values (e.g., theme pastel), recommended usage patterns, and explanations for compact parameter tuples (d, e, n, p, s, t).
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 structured visuals (e.g., flowchart, mindmap) as SVG, with two modes. However, it does not differentiate from the sibling tool 'generate_diagram', which may have overlapping functionality.
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 natural language vs structured mode and emphasizes the required post-processing steps. However, it lacks explicit guidance on when not to use this tool or scenarios where the sibling 'generate_diagram' would be more appropriate.
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. | |
| 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?
Description adds output format (plain text) and size (~4 KB) beyond annotations which already confirm readOnly, idempotent, non-destructive. No contradictions; the extra details help agent understand the tool's behavior.
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?
Two sentences: first lists contents, second gives usage context. Every word adds value, no fluff. Front-loaded with purpose, well-structured for quick parsing.
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?
Covers when to use and output format, but fails to explain the role of the 33 required parameters. This is a critical gap for a tool with such a complex schema. Without understanding parameter semantics, the agent risks misusing the tool.
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?
Description does not explain why the tool has 33 required parameters (same as generate_visual) when it's supposed to return a catalog. Schema coverage is high (79%) but the purpose of parameters is unclear; description should clarify how inputs affect output but does not.
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?
Description clearly states it returns the full style-options catalog for generate_visual, listing categories like themes, fonts, arrows. This verb-resource pairing plus specific contents makes purpose unambiguous and distinct from sibling tools generate_diagram and 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 says to call when exposing style choices to user or before composing a generate_visual call with non-default styling. Provides concrete use cases but lacks explicit guidance on when not to use or alternatives.
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 | Yes | Number of frameworks to return. Default 5; cap 20. | |
| persona | Yes | Persona slug (e.g. "ciso", "pm", "cfo"). | |
| regulation | Yes | Regulation slug (e.g. "sox", "gdpr", "iso-31000"). | |
| decision_stage | Yes | 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 declare readOnlyHint, idempotentHint, destructiveHint; description adds details about knowledge graph, ranking with reasons, and optional filters. No contradictions, but could mention rate limits or accuracy caveats.
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?
Concise (~100 words), well-structured: purpose, when to use, input details, pairing advice, example. No redundant sentences.
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?
Covers input, optional filters, limit, pairing with sibling tool; describes output format adequately for no output schema. Could mention possible errors or performance, but sufficient for common use.
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%; description adds practical guidance: 'just the problem statement is enough', suggests limit range 3-10 for picker UIs, and explains optional filters. Enhances parameter meaning 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?
Description clearly states it recommends business/strategy/risk frameworks for a problem, specifies knowledge graph source, and output format (ranked with reasons). Distinguishes from sibling 'generate_framework_analysis' by noting it's to run a recommended framework.
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 says 'Use when the user describes a business problem rather than naming a specific framework', and advises to pair with 'generate_framework_analysis' for execution. Provides optional filters and limit guidance.
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!