Skip to main content
Glama
jgraph

drawio MCP Server

Official
by jgraph
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

open_drawio_mermaid

Open the draw.io editor with an editable diagram generated from Mermaid.js syntax. Convert flowcharts, sequence, class, ER, and other supported Mermaid types for editing in draw.io.

Instructions

Opens the draw.io editor with a diagram generated from Mermaid.js syntax, converted into an editable draw.io diagram. The recommended default for flowcharts, sequence, class, state and ER diagrams, gantt charts, mind maps, timelines, C4, architecture and the other types draw.io's Mermaid parser supports (28 in all).

Call get_drawio_reference with format "mermaid" once before your first Mermaid diagram in a conversation: it lists the header keyword and syntax hints for every supported type (a misspelled header yields a blank diagram) and flowchart styling.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
darkNoDark mode setting. Default: auto
contentYesThe Mermaid.js diagram definition. Example: 'graph TD; A-->B; B-->C;'
lightboxNoOpen in lightbox mode (read-only view). Default: false
postLayoutNoOptional ELK layered layout for Mermaid FLOWCHARTS. The only value is "elk". draw.io's native Mermaid parser does its own layout, but it produces cramped or unbalanced output once the diagram has any structural complexity — request "elk" whenever ANY of these holds: >= ~20 nodes, OR >= 3 decision diamonds (`{...}` shapes), OR any feedback/back-edges (an edge pointing back to an earlier node, e.g. an error path looping to a retry), OR >= 3 distinct endpoints. The flow direction follows the flowchart code (`flowchart TD/TB` vs `LR/RL`), so there is no direction field here. Ignored for non-flowchart diagram types (sequence, class, ER, gantt, …), which lay themselves out.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations present, the description carries the full burden and does reasonably well: it discloses that the editor opens with an editable diagram, and warns that a misspelled header keyword yields a blank diagram, which is a real failure mode an agent needs. It does not discuss permissions, side effects on existing pages, or whether the edit persists, leaving some behavioral gaps for a mutation-like tool.

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?

Two tight paragraphs, front-loaded with the core purpose and supported types, followed by the reference-call prerequisite. Every sentence is load-bearing, though the '28 in all' enumeration is slightly padded.

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 4-parameter tool with 100% schema coverage and no output schema, the description supplies the missing context an agent needs: the supported type list, the get_drawio_reference prerequisite, and the blank-diagram pitfall. Absence of persistence/authorization details is the only meaningful gap.

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% and the schema already documents dark, lightbox, and the detailed postLayout heuristics. The description adds only the pointer to get_drawio_reference for header syntax, so per the baseline rule a 3 is appropriate.

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?

States a specific verb and resource ('Opens the draw.io editor with a diagram generated from Mermaid.js syntax') and explicitly distinguishes itself from siblings by contrasting the Mermaid input path with the csv/xml alternatives. The enumeration of supported diagram types makes the scope unambiguous.

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?

Clearly positions itself as 'the recommended default for flowcharts, sequence, class, state and ER diagrams...' and gives an explicit prerequisite ('Call get_drawio_reference with format "mermaid" once before your first Mermaid diagram'). It lacks an explicit when-NOT-to-use statement versus open_drawio_xml or open_drawio_csv, which keeps it short of a 5.

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