Skip to main content
Glama

Agentic Mermaid

by io.github.adewale

Render Mermaid as SVG

render_svg
Read-onlyIdempotent

Render a Mermaid source string to themeable SVG. Returns { ok, svg }. Layout is deterministic: identical input produces identical geometry. The hosted boundary forces security:'strict' and embedFontImport:false.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourceYesMermaid source.
optionsNoShared advanced RenderOptions object. Styles accept a registered Look (crisp, hand-drawn, excalidraw, pen-and-ink, freehand, watercolor, blueprint, look:tufte, accessible-high-contrast, patent-drawing, status-dashboard, ops-schematic, chalkboard, risograph, architectural-plan, publication-figure), Palette (paper, dusk, zinc-light, zinc-dark, tokyo-night, tokyo-night-storm, tokyo-night-light, catppuccin-mocha, catppuccin-latte, nord, nord-light, dracula, github-light, github-dark, solarized-light, solarized-dark, one-dark, salmon, salmon-dark, tufte-dark), inline record, or left-to-right stack.

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral details beyond those: deterministic layout ('identical input produces identical geometry') and hosted-boundary constraints ('forces security:\'strict\' and embedFontImport:false'). No contradiction 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.

Conciseness5/5

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

The description is three tight sentences: purpose, return shape, and behavioral constraints. It is front-loaded with the action and avoids redundant restatement of the title or annotations.

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

Completeness4/5

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

For a tool with a very large options schema, the description captures the core behavior, return shape, determinism, and security constraints. It does not cover error behavior or supported Mermaid families, but the schema and annotations compensate for most gaps, and the absence of an output schema is mitigated by the explicit { ok, svg } return note.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds only the phrase 'source string' and 'themeable SVG,' while the schema fully documents both parameters and all nested option properties. No additional semantic value is provided beyond what the schema already contains.

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 opens with a specific verb and resource: 'Render a Mermaid source string to themeable SVG.' It also names the return shape ({ ok, svg }), clearly distinguishing this tool from sibling renderers like render_ascii and render_png by output format.

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 gives clear context that this tool produces SVG output, which differentiates it from ASCII and PNG rendering siblings. It does not explicitly name alternatives or provide when-to-use/when-not-to-use guidance, but the output-type framing is sufficient for basic selection.

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