Skip to main content
Glama

mermaid-mcp

test npm

An MCP server that renders Mermaid diagrams to PNG, SVG, or PDF — or converts them to editable draw.io files. Give your LLM the ability to turn diagram syntax into actual images and documents.

Quick start

Claude Code

claude mcp add mermaid -- npx -y mermaid-render-mcp

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "mermaid": {
      "command": "npx",
      "args": ["-y", "mermaid-render-mcp"]
    }
  }
}

Note: the first run downloads headless Chromium (~150 MB), so the initial startup takes a few minutes. If you only need flowcharts and can work with editable files, the drawio fast path skips Chromium entirely.

Docker

No Node.js or Chromium download needed — the image ships with everything (including CJK fonts for Japanese/Chinese/Korean labels):

claude mcp add mermaid -- docker run -i --rm tcinebula/mermaid-render-mcp

To use output_path, mount a host directory and write into it:

{
  "mcpServers": {
    "mermaid": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-v", "C:\\diagrams:/out", "tcinebula/mermaid-render-mcp"]
    }
  }
}

Then pass output_path: "/out/figure.pdf" and the file appears in C:\diagrams.

Remote / self-hosted (HTTP)

The same server speaks Streamable HTTP when PORT is set (or MCP_TRANSPORT=http), so it can be deployed to any container host — Railway, Fly.io, etc. — straight from the Dockerfile:

  • Endpoint: POST /mcp (health check at /healthz)

  • Set AUTH_TOKEN to require Authorization: Bearer <token>

  • output_path is disabled in HTTP mode; base64/XML responses only

From source

git clone https://github.com/tci-nebula/mermaid-mcp.git
cd mermaid-mcp
npm install
claude mcp add mermaid -- node /path/to/mermaid-mcp/server.js

Related MCP server: Mermaid-MCP

Tool: render_diagram

Parameter

Type

Default

Description

syntax

string

(required)

Mermaid diagram definition

format

png | svg | pdf | drawio

png

Output format (drawio = editable draw.io XML, flowcharts only)

theme

default | dark | neutral | forest

default

Visual theme

background

string

white

CSS colour or transparent

width

number

1200

Canvas width in px (PNG only)

pdfFit

boolean

true

Scale the PDF page to fit the diagram (PDF only)

output_path

string

Write the result to this file path instead of returning base64

Returns the rendered image as base64-encoded data so MCP clients can display it inline — or, with output_path, writes the file to disk (handy for PDFs destined for printing or formal document submission).

Example

Ask your LLM:

"Draw me a flowchart of the OAuth login flow"

It generates the Mermaid syntax, calls render_diagram, and you get back a PNG.

The drawio fast path (no Chromium)

format: "drawio" is the one output that never touches a browser. It's pure JavaScript — parse, lay out with dagre, emit XML — so there's no Chromium download, no ~150 MB install, and no multi-minute first run. Conversion is effectively instant.

Reach for it when:

  • you want the diagram editable rather than flat — every shape stays a real draw.io object

  • you're on a constrained box (CI, a slim container, a locked-down laptop) where downloading Chromium isn't practical

  • you just want the diagram now and don't need a raster image

{
  "syntax": "flowchart TD\n  A[Start] --> B{OK?}\n  B -->|yes| C[Ship]\n  B -->|no| A",
  "format": "drawio",
  "output_path": "flow.drawio"
}

Open the result in draw.io (or the VS Code extension) and export to PNG/SVG/PDF from there if you do need an image — that's a complete Chromium-free round trip.

Limits

  • Flowcharts only. flowchart and graph diagrams convert; sequence, class, state, ER, and gantt throw an error. Use PNG/SVG/PDF for those.

  • theme, background, and width are ignored. Styling is draw.io's job once the file is open.

  • Node sizes are estimated from label length, not measured font metrics. draw.io re-measures text when it opens the file so boxes settle correctly — but treat the raw XML geometry as approximate.

Supported syntax: directions TD / TB / BT / LR / RL; shapes [rect], (rounded), {rhombus}, ((circle)), ([stadium]), [[subroutine]], [(cylinder)], {{hexagon}}; edges -->, ---, -.->, ==>, <-->, each optionally carrying a |label|.

How it works

PNG, SVG, and PDF rendering shells out to @mermaid-js/mermaid-cli (bundled as a dependency), which uses a headless Chromium to render diagrams. First npm install downloads Chromium (~150 MB), so it takes a few minutes.

draw.io export is pure JavaScript — a flowchart parser plus dagre layout (the same engine Mermaid uses) emit native mxGraphModel XML, so every shape stays individually editable in draw.io.

Requirements

Roadmap

  • PDF export (formal/legal document workflows)

  • draw.io XML export (editable diagrams — flowcharts)

  • npm package (mermaid-render-mcp)

  • Remote-hosted server option (Streamable HTTP transport)

License

MIT

Available Tools

1 tool
render_diagramA

Render Mermaid diagram syntax into a PNG, SVG, or PDF — or convert it to an editable draw.io (.drawio) file. Returns the result as base64-encoded data (drawio: XML text), or writes it to output_path if given. drawio format supports flowcharts only.

ParametersJSON Schema
NameRequiredDescriptionDefault
themeNoVisual theme for the diagram.default
widthNoCanvas width in pixels (PNG only).
formatNoOutput format. Defaults to png. drawio produces an editable draw.io XML file (flowcharts only).png
pdfFitNoScale the PDF page to fit the diagram (PDF only).
syntaxYesMermaid diagram definition (e.g. flowchart, sequenceDiagram, etc.)
backgroundNoBackground colour (CSS colour string or "transparent").white
output_pathNoAbsolute file path to write the result to. When given, the file is written to disk and no base64 data is returned — useful for documents destined for printing or formal submission.

TDQS

A4/5.0
Behavior3/5

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

With no annotations provided, the description discloses important behaviors: returns base64-encoded data (or XML for drawio), writes to output_path when provided, and limits drawio to flowcharts. Yet it omits edge cases like error handling, file overwriting, or invalid syntax behavior, which keeps it from being more transparent.

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 exactly three sentences, each adding distinct value: the main function, the return/write behavior, and the drawio caveat. It is well-structured and front-loaded with the core purpose.

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?

Given there is no output schema and no annotations, the description efficiently covers formats, return type, output_path behavior, and a format limitation. It is sufficient for an agent to invoke the tool correctly, though it could mention potential error conditions or overwrite behavior for full completeness.

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?

The input schema covers all 7 parameters with descriptions, so the schema carries the primary semantics. The description adds a bit of extra context by explaining the base64/drawio XML return behavior and how output_path changes the response, but it doesn't significantly exceed what the schema already provides.

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 renders Mermaid syntax into PNG, SVG, PDF, or an editable draw.io file. The verb 'Render' and specific output formats make the purpose unambiguous, even without sibling tools for comparison.

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 provides useful usage context, such as using output_path for printing/form submission and noting drawio format supports flowcharts only. However, it doesn't explicitly mention when not to use the tool or compare to alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.2.0
    • First observedrender_diagram

TDQS

A4/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap. The tool's purpose is clearly defined by its name and description.

Naming Consistency5/5

The single tool name 'render_diagram' follows a clear verb_noun pattern, which is consistent and predictable. There are no other tools to cause inconsistency.

Tool Count3/5

One tool is on the low end of the range and feels thin for a server, but the tool consolidates multiple output formats into a single function, which partially justifies the count.

Completeness3/5

The tool covers core rendering and conversion needs, but lacks separate validation or inspection utilities. This leaves minor gaps for complex diagramming workflows.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers