Validate Mermaid syntax and get error details your coding agent can use to correct a diagram. Check the source again before adding it to your documentation. Validation works without saving a diagram.
Render SVG, PNG, or PDF, save diagrams privately, and publish selected snapshots. Your existing agent writes and corrects the source; MermaidDesk checks and renders it. Validation checks syntax, not whether a diagram accurately describes a system.
Connect through MCP with Streamable HTTP and a scoped bearer API key. Enable MERMAID_RENDER for validation and rendering. A REST API is also available.
MCP setup: https://www.mermaiddesk.com/developers/mcp REST API guide: https://www.mermaiddesk.com/developers/api
Scored across 2 tools
render_mermaid and validate_mermaid perform clearly different actions on the same artifact (produce output vs. check syntax), with no overlap in intent. An agent can trivially choose between producing a diagram and checking one before producing it.
Both tools follow the exact verb_noun pattern (render_mermaid, validate_mermaid) with a shared subject suffix, making the pair read as a deliberate, predictable family.
Two tools is on the thin side, but for a focused Mermaid rendering utility the render/validate pair covers the essential operations and neither tool is filler. Nothing suggests the surface should be padded out further.
The stated scope (stateless render + syntax check) is fully covered, and both tools explicitly disclose that they persist nothing, so there is no hidden dead end. Minor gaps exist for workflow convenience, such as no option/theme discovery or batch rendering, but agents can work around these.
Render supplied Mermaid as an inline SVG resource, PNG image, or PDF resource. Saves and publishes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| theme | No | dark | |
| format | Yes | ||
| source | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context — that nothing is persisted or published, which readOnlyHint alone does not state — but it omits what happens on invalid Mermaid input.
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 short sentences, front-loaded with the action and output types, with the non-persistence clause appended as a compact caveat. Nothing redundant.
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 simple three-parameter render tool with full annotations and no output schema, the description covers what is produced and that no side effects occur. The remaining gap is error behavior for malformed Mermaid, which matters given the existence of validate_mermaid.
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 0%, so the description must compensate; it partially does by enumerating the three format values (svg, png, pdf) that map to the format parameter. It says nothing about source or the theme parameter's light/dark default, leaving those to the enum and type alone.
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?
States a specific verb (render) and resource (Mermaid source) plus the exact output formats (inline SVG, PNG, PDF). It is naturally distinguishable from the sibling validate_mermaid by verb alone, but never names that sibling or states the render-vs-validate boundary explicitly.
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 phrase "Saves and publishes nothing" sets a useful scope exclusion, but there is no guidance on when to call this instead of validate_mermaid, nor whether validation should precede rendering. Usage is only implied by the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Mermaid syntax and return error details. A valid result confirms syntax only. It does not confirm that the diagram accurately describes a real system. Saves and publishes nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the bar is lower. The description adds genuine value by clarifying the semantic ceiling of a success result and restating that nothing is saved or published — important for an agent deciding whether validation is a safe, repeatable step.
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?
Four short sentences, front-loaded with the core action and zero filler. The closing 'Saves and publishes nothing' slightly overlaps the readOnly annotation but still reads as deliberate scoping.
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?
With no output schema, the description should convey what 'error details' look like (line numbers, messages), and it does not. The safety and semantic-scope story is complete, but the return-value shape and the meaning of the sole parameter are left open.
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 single parameter 'source' has 0% schema description coverage, so the description carries the full burden — but it never states that 'source' is the Mermaid diagram text, nor any format expectations. The agent can only infer this from 'Check Mermaid syntax'.
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?
States a specific verb+resource: check Mermaid syntax and return error details. It implicitly distinguishes itself from render_mermaid via 'Saves and publishes nothing', but never names that sibling, so the differentiation requires inference.
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?
Explains what a valid result does and does not mean ('confirms syntax only', 'not that the diagram accurately describes a real system'), which helps an agent decide how much to trust the outcome. However, it never says when to call this versus render_mermaid, which is the only sibling and the obvious alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
render_mermaidvalidate_mermaidRender, verify, describe, and safely edit Mermaid diagrams through MCP.
Create and manage Mermaid.js flowcharts and diagrams with AI agents via MCP.
Generate dynamic Mermaid diagrams and charts with AI assistance. Customize styles and export diagr…
Render, validate, encode/decode PlantUML diagram-as-code; 22 diagram types. Free, no auth.
Add one secure layer between your agents and this server.
