Skip to main content
Glama
Sign In

CalderFlow

by com.calderflow
OverviewDiscussionsAdmin

create_flowchart

Create a presentation-ready flowchart or architecture diagram from Mermaid source. Use for branching processes, decision trees, and system architecture. Rules: start with 'flowchart TD' or 'flowchart LR'; solid arrows only (-->, optionally with |labels|); node shapes: A[Process] B{Decision} C([Start/End]). CalderFlow presents decisions as compact amber cards and terminals as green states, so use shapes semantically and do not add decorative classDef noise. CALIBRATE DETAIL: vague/ideation ask → 4-7 nodes, happy path + at most 2 essential decisions, NO subgraphs; detailed/spec-driven ask → subgraphs as phases, <=7 nodes per subgraph, <=18 nodes total (split the story into an overview plus detail chart beyond that). Consolidate checks that lead to the same outcome. If any subgraph is used, EVERY node—including starts, errors, and final outcomes—must be declared inside exactly one subgraph. Put internal edges inside their subgraph and cross-phase edges outside. Node labels 1-4 words; label every decision branch. Connect phases that hand off to each other. Returns the chart id + share URL. Give every node an icon with a %% nodeIcon line and mark the one step to remember with class keyStep (see the server instructions for icon names).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "title": "<title>",
      "mermaid": "<mermaid>"
    },
    "name": "create_flowchart"
  }
}

Input Schema

NameRequiredDescriptionDefault
titleYesChart title shown in the app and share page.
mermaidYesMermaid flowchart source code.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full burden and does so: it discloses the return values ('chart id + share URL'), how CalderFlow renders decisions as amber cards and terminals as green states, the semantic meaning of node shapes, the subgraph containment rule, and the nodeIcon/keyStep conventions. It also discourages decorative classDef noise, which prevents a predictable failure mode.

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

Conciseness4/5

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

Purpose and return value are front-loaded, then rules are grouped logically (syntax → detail calibration → subgraph containment → labeling → icons). It is dense and a few sentences pack several constraints at once, but essentially every clause is an actionable rule rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter, no-annotation, no-output-schema generator, the description covers everything an agent needs: what to emit, valid syntax, how much detail to include, structural constraints for subgraphs, and what comes back. The icon-name lookup is deferred explicitly to server instructions, which is an acceptable pointer rather than a gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for both parameters, so the baseline is 3, but the description adds substantial meaning to 'mermaid': required header ('flowchart TD' or 'flowchart LR'), arrow syntax, node shape tokens, label length, branch labeling, and the %% nodeIcon / keyStep lines. Only 'title' is left entirely to the schema, which is fine for a string field.

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

Purpose5/5

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

States a specific verb and resource ('Create a presentation-ready flowchart or architecture diagram from Mermaid source') and immediately narrows scope to branching processes, decision trees, and system architecture, which cleanly separates it from the sibling chart types (chevron, ERD, funnel, lifecycle, timeline).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

Gives a concrete use-case list plus a strong detail-calibration rule (vague ideation → 4-7 nodes, no subgraphs; spec-driven → subgraphs, <=18 nodes), which tells the agent how to size the output. It never names an alternative tool or an explicit 'use X instead when...' condition, so routing between sibling chart creators is left implicit.

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

All CalderFlow toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources