Skip to main content
Glama

Agentic Mermaid

by io.github.adewale

Build Mermaid diagram

build
Read-onlyIdempotent

Author a new Mermaid diagram from blank by folding a list of structured ops over an empty diagram of family. The declarative counterpart to hand-writing source. Returns the same envelope as mutate: { ok, family, source, verify } or { ok:false, family, opIndex, error }. Call describe_sdk for the family before authoring unfamiliar ops.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opsYesNon-empty ordered list of ops; each is { kind, ...fields }.
familyYesDiagram family to author (one of: flowchart, state, sequence, timeline, class, er, journey, architecture, xychart, pie, quadrant, gantt, mindmap, gitgraph, radar).

TDQS

A4.5/5.0
Behavior4/5

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

The description discloses the return envelope in both success and failure cases, and notes a prerequisite (`describe_sdk`). Annotations already indicate readOnly, idempotent, and non-destructive behavior, so the description adds value by explaining the process of folding ops and the exact response shape.

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

Conciseness5/5

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

The description is three sentences long, front-loaded with the primary action, and each sentence earns its place: the core action, a clarifying analog, and the return/usage caveat. No wasted words.

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?

No output schema exists, but the description fully covers the return values, error format, and necessary prerequisites. With only two parameters and good annotations, the description gives the agent enough to understand behavior and integration with siblings.

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%, so the baseline is 3. The description adds meaning by explaining that ops are 'folded' over an empty diagram, giving operational context beyond the schema's listing of `{ kind, ...fields }`. It also clarifies the role of `family` by naming it as the diagram type.

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?

The description clearly states the tool's purpose: author a new Mermaid diagram from blank using structured ops. It distinguishes itself from siblings by being 'the declarative counterpart to hand-writing source' and returns the same envelope as `mutate`, implying a different operation from that mutation tool.

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?

The description implies when to use this tool: when authoring a new diagram declaratively via ops rather than writing source directly. It also advises calling `describe_sdk` for unfamiliar ops. It does not explicitly name alternatives, but the reference to `mutate` and the broader sibling list provide enough context.

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

All Agentic Mermaid toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation4/5

Most tools have clear, distinct purposes: build and mutate are separated by create-vs-edit, describe and verify are separated by semantic-explain-vs-validate, and render_* variants differ by output format. The only potential ambiguity is between execute and build/mutate, but the descriptions explicitly steer users away from execute for straightforward structured edits.

Naming Consistency3/5

Tool names mix two conventions: bare verbs (build, describe, execute, mutate, verify) and verb_noun with underscore (describe_sdk, render_ascii, render_png, render_svg). While readable and lower-case throughout, the inconsistency prevents a higher score.

Tool Count5/5

9 tools is well within the 3-15 sweet spot and covers the domain of diagram authoring, editing, inspecting, verifying, and rendering without bloat. Each tool earns its place: build/mutate/execute for editing, describe/verify for analysis, render_* for output, and describe_sdk for schema discovery.

Completeness5/5

The tool set forms a complete lifecycle: create (build), edit (mutate, execute), inspect (describe, verify), and output (render_svg/png/ascii). describe_sdk provides schema discovery so agents can author valid operations. There are no obvious dead ends; even unsupported families are handled gracefully in the broader SDK design.

Resources