Clear Mermaid

Overview Schema Source Related Servers Discussions Admin

Create a Clear Mermaid diagram

clear_mermaid_render

Render a Mermaid flowchart as an interactive local browser view. Returns a private localhost link to explore nodes, connections, and save the source.

Instructions

Create an interactive local browser view of a Mermaid flowchart. Use for architecture, decisions, dependencies and retry paths. Returns a private localhost link; the user must open it on the same computer while this MCP connector is running. Only flowcharts are supported. No uploads or external API calls. The browser checks compatibility before drawing; do not claim visual verification until the page has been checked.

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": {
      "source": "<source>"
    },
    "name": "clear_mermaid_render"
  }
}

Input Schema

Name	Required	Description	Default
`title`	No	A short title people will recognise.
`source`	Yes	Mermaid flowchart source, starting flowchart LR or TD. Use named nodes, plain labels and explicit directed connections. No HTML, click directives or custom styling.

Output Schema

Name	Required	Description	Default
`url`	Yes
`nodes`	Yes
`title`	Yes
`expiresAt`	Yes
`validation`	Yes
`connections`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 5, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare the mutation/safety profile; the description adds substantial context they cannot convey: a private localhost link, the requirement that the user open it on the same computer while the connector runs, no uploads or external API calls, and the caveat not to claim visual verification until the page is checked. These are exactly the operational facts an agent needs before calling.

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?

Sentences are short and front-loaded, leading with the action before the caveats. A couple of clauses (only flowcharts, no uploads) partially restate schema constraints, so it is slightly redundant but never wasteful.

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?

With an output schema present, return values need no explanation, and the description still covers what an agent must know: the localhost prerequisite, sandboxing, and the verification limitation. Nothing needed to invoke or interpret the result is missing.

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

Parameters5/5

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

Schema description coverage is 100%, so both parameters are already documented in the schema, and the description adds little parameter-level detail. Baseline 3 applies: the description reinforces flowchart-only scope but does not extend the meaning of 'source' or 'title'.

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 opening sentence names a specific verb and artifact: 'Create an interactive local browser view of a Mermaid flowchart.' It immediately bounds the resource ('Only flowcharts are supported'), so an agent knows exactly what this tool produces and what it will not accept.

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?

It gives concrete use cases (architecture, decisions, dependencies, retry paths) and an explicit scope restriction to flowcharts. There are no sibling tools to route against, so no alternatives need naming; the only gap is that it never states a when-not-to-use case beyond the flowchart limitation.

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

Deploy Server

Other Tools

clear_mermaid_renderA