mermaid-mcp
The mermaid-mcp server renders Mermaid diagram syntax into images (PNG, SVG), PDF documents, and editable draw.io XML files (flowcharts only).
Render to PNG: Convert diagrams to PNG with configurable canvas width, theme, and background color.
Render to SVG: Export diagrams as scalable vector graphics.
Render to PDF: Generate PDF documents with an option to auto-fit the diagram to the page.
Export to draw.io XML: Transform Mermaid flowcharts into editable
.drawiofiles where each shape remains individually editable (flowcharts only).Customize appearance: Apply themes (
default,dark,neutral,forest) and set background colors (any CSS color ortransparent).Output options: Return results as base64-encoded data (default) for inline display, or save directly to a specified file path on disk.
Renders Mermaid diagram definitions to PNG, SVG, PDF, or editable draw.io XML with configurable themes, background, width, and optional file output.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@mermaid-mcpDraw me a flowchart of the OAuth login flow"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
mermaid-mcp
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-mcpClaude 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
drawiofast 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-mcpTo 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_TOKENto requireAuthorization: Bearer <token>output_pathis 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.jsRelated MCP server: Mermaid-MCP
Tool: render_diagram
Parameter | Type | Default | Description |
| string | (required) | Mermaid diagram definition |
|
|
| Output format ( |
|
|
| Visual theme |
| string |
| CSS colour or |
| number |
| Canvas width in px (PNG only) |
| boolean |
| Scale the PDF page to fit the diagram (PDF only) |
| 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.
flowchartandgraphdiagrams convert; sequence, class, state, ER, and gantt throw an error. Use PNG/SVG/PDF for those.theme,background, andwidthare 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
Node.js 18+
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
Available Tools
1 toolrender_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.
| Name | Required | Description | Default |
|---|---|---|---|
| theme | No | Visual theme for the diagram. | default |
| width | No | Canvas width in pixels (PNG only). | |
| format | No | Output format. Defaults to png. drawio produces an editable draw.io XML file (flowcharts only). | png |
| pdfFit | No | Scale the PDF page to fit the diagram (PDF only). | |
| syntax | Yes | Mermaid diagram definition (e.g. flowchart, sequenceDiagram, etc.) | |
| background | No | Background colour (CSS colour string or "transparent"). | white |
| output_path | No | Absolute 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
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.
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.
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.
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.
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.
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 tool update
v1.2.0- First observed
render_diagram
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion or overlap. The tool's purpose is clearly defined by its name and description.
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.
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.
The tool covers core rendering and conversion needs, but lacks separate validation or inspection utilities. This leaves minor gaps for complex diagramming workflows.
Maintenance
Related MCP Connectors
MCP server for Qwen Image 3 AI image generation
MCP server for Flux AI image generation
MCP server for generating rough-draft project plans from natural-language prompts.
Related MCP Servers
- AlicenseBqualityCmaintenanceA Model Context Protocol (MCP) server that converts Mermaid diagrams to PNG images.1113 npm234MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server that converts text inputs into visualized flowcharts, enabling AI clients to generate high-quality Mermaid diagrams directly from natural language descriptions or structured text.11MIT
- AlicenseAqualityDmaintenanceAn MCP server that generates diagrams from Mermaid code in multiple formats (PNG, PDF, SVG).21MIT
- FlicenseNot gradedqualityDmaintenanceMCP server that generates Mermaid diagrams with live browser preview, supports real-time rendering and SVG/PNG export.12-