Creates and opens diagrams in draw.io (diagrams.net) from XML, Mermaid, or CSV input.
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., "@drawio-mcp create a mermaid flowchart for user authentication"
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.
An MCP (Model Context Protocol) server that enables LLMs to create and open diagrams in draw.io. Supports native draw.io XML, Mermaid.js syntax, and CSV data formats.
When an LLM calls one of the tools, the server compresses the diagram content, builds a draw.io URL with the #create hash parameter, and opens it in your default browser — the diagram appears instantly in the draw.io editor, ready to edit and export.
Tool | Format | Best for |
| draw.io XML | Full control over styling and layout |
| Mermaid.js | Quick flowcharts, sequence diagrams, ER diagrams |
| CSV | Org charts and diagrams from tabular data |
Related MCP server: fcp-drawio
git clone https://github.com/mingrath/drawio-mcp.git
cd drawio-mcp
npm install
npm run buildOr install globally:
npm install -g drawio-mcpAdd to your ~/.claude/settings.json:
{
"mcpServers": {
"drawio-mcp": {
"command": "node",
"args": ["/absolute/path/to/drawio-mcp/dist/index.js"]
}
}
}Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"drawio-mcp": {
"command": "node",
"args": ["/absolute/path/to/drawio-mcp/dist/index.js"]
}
}
}<mxGraphModel>
<root>
<mxCell id="0"/>
<mxCell id="1" parent="0"/>
<mxCell id="2" value="Service A" style="rounded=1;fillColor=#dae8fc;strokeColor=#6c8ebf;" vertex="1" parent="1">
<mxGeometry x="100" y="100" width="140" height="60" as="geometry"/>
</mxCell>
<mxCell id="3" value="Service B" style="rounded=1;fillColor=#d5e8d4;strokeColor=#82b366;" vertex="1" parent="1">
<mxGeometry x="320" y="100" width="140" height="60" as="geometry"/>
</mxCell>
<mxCell id="4" style="endArrow=block;endFill=1;" edge="1" source="2" target="3" parent="1">
<mxGeometry relative="1" as="geometry"/>
</mxCell>
</root>
</mxGraphModel>graph TD
A[Start] --> B{Decision}
B -->|Yes| C[Action 1]
B -->|No| D[Action 2]
C --> E[End]
D --> EsequenceDiagram
participant Client
participant API
participant DB
Client->>API: POST /users
API->>DB: INSERT user
DB-->>API: OK
API-->>Client: 201 Created# label: %name%
# style: whiteSpace=wrap;html=1;rounded=1;fillColor=#dae8fc;strokeColor=#6c8ebf;
# connect: {"from":"manager","to":"name","invert":true,"style":"endArrow=blockThin;endFill=1;"}
# layout: auto
name,manager
CEO,
CTO,CEO
CFO,CEO
VP Engineering,CTO
VP Product,CTOAll three tools accept these optional parameters:
Parameter | Type | Default | Description |
| string | (required) | Diagram content or a URL pointing to content |
| boolean |
| Open in read-only lightbox mode |
|
|
| Dark mode setting |
The LLM calls a tool with diagram content (XML, Mermaid, or CSV).
The server URI-encodes and deflate-compresses the content.
A draw.io URL is constructed with the compressed data in a #create= hash fragment.
The URL opens in your default browser — draw.io reads the hash and renders the diagram.
Because the data lives in the URL hash fragment, it is never sent to any server.
npm run dev # Watch mode — recompiles on changes
npm run build # One-time build
npm start # Run the compiled serverNode.js >= 18
A browser (for opening diagrams)
MIT - Mingrath Mekavichai
Opens the draw.io editor with a diagram generated from CSV data or a URL to CSV data. The CSV format follows draw.io's CSV import specification for creating org charts, flowcharts, and other diagrams from tabular data.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The CSV content or a URL pointing to CSV content. Should follow draw.io's CSV import format with header comments for styling. | |
| lightbox | No | Open in lightbox mode (read-only view). Default: false | |
| dark | No | Dark mode setting. Default: auto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states it 'opens the editor' and mentions CSV format. No disclosure of side effects, permissions, or constraints beyond input format. The action is a mutation (editing), yet no behavioral implications are described.
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 sentences, each serving a purpose: first defines action and input, second adds format context. No redundant information. Could be slightly more structured but is efficient.
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 tool with no output schema, the description adequately covers input requirements and format context. It does not need to explain return values, which are implied (the editor UI). Completeness is good given tool complexity.
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 100% (all 3 parameters have descriptions). The description adds context about the CSV format following draw.io's specification, which enriches understanding but does not detail individual parameters. Baseline 3 is appropriate.
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 states 'Opens the draw.io editor with a diagram generated from CSV data', specifying the action (opens), resource (draw.io editor), and input format (CSV). It distinguishes from siblings (open_drawio_mermaid, open_drawio_xml) by focusing on CSV, making selection unambiguous.
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 implies use when CSV data is available, but does not explicitly state when to use this tool over siblings (e.g., Mermaid or XML formats). No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opens the draw.io editor with a diagram generated from Mermaid.js syntax or a URL to Mermaid content. Supports flowcharts (graph TD/LR), sequence diagrams, class diagrams, state diagrams, ER diagrams, Gantt charts, pie charts, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The Mermaid.js diagram definition or a URL pointing to Mermaid content. Example: 'graph TD; A-->B; B-->C;' | |
| lightbox | No | Open in lightbox mode (read-only view). Default: false | |
| dark | No | Dark mode setting. Default: auto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present. The description only states the tool's action without disclosing behavioral traits such as destructiveness, authentication requirements, or side effects (e.g., whether it modifies data or just displays). This leaves ambiguity for the agent.
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 concise: two sentences. The first sentence states the core action and content format, the second lists supported diagram types. There is no unnecessary information, and key details are front-loaded.
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 the tool's low complexity (3 parameters, no output schema, simple UI action), the description covers essential aspects. It could mention that the tool likely opens an interactive editor (non-destructive), but it is generally complete for agent decision-making.
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 coverage is 100%, so the input schema already describes all parameters. The description adds a list of supported diagram types, which provides context but does not significantly enhance parameter understanding beyond the schema's descriptions.
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 opens the draw.io editor with a diagram generated from Mermaid.js syntax or a URL, and lists supported diagram types. This distinguishes it from sibling tools (open_drawio_csv, open_drawio_xml) which handle different formats.
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 implies usage for Mermaid-based diagrams but does not explicitly state when to use this tool versus alternatives. No guidance on when not to use it or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opens the draw.io editor with a diagram from XML content or a URL to XML content. Use this to create, view, or edit diagrams in native draw.io/mxGraph XML format.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The draw.io XML content or a URL pointing to XML content. If a URL is provided, the content will be fetched automatically. | |
| lightbox | No | Open in lightbox mode (read-only view). Default: false | |
| dark | No | Dark mode setting. Default: auto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as side effects, permissions, error handling, or whether the editor is modal. It only says 'opens' without disclosing safety or lifecycle.
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 sentences with no redundancy. The description is efficient, front-loading the core action and 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 no output schema and low complexity, the description covers basic use but lacks behavioral depth. It is adequate but not comprehensive.
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 coverage is 100%, so the description adds little beyond explaining the content parameter accepts XML or URL. No additional meaning is provided for lightbox or dark parameters beyond schema.
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 it opens the draw.io editor with XML content or a URL, specifying the verb ('opens'), resource ('draw.io editor'), and format ('XML'). It distinguishes from siblings (CSV, Mermaid) by emphasizing native draw.io/mxGraph XML format.
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 implies that this tool is for XML diagrams, and siblings exist for other formats, but it does not explicitly state when to use this tool versus alternatives or provide exclusions.
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.
v1.0.0open_drawio_csvopen_drawio_mermaidopen_drawio_xmlScored across 3 tools
Each tool targets a distinct input format (CSV, Mermaid, XML) for generating diagrams, with no overlap in purpose.
All tools follow the consistent pattern 'open_drawio_{format}' using snake_case, making the naming predictable.
Three tools is an appropriate and focused count for a server dedicated to opening diagrams in draw.io, covering the primary input formats.
The three tools cover the main methods for creating diagrams in draw.io (CSV import, Mermaid, native XML), with no obvious gaps for the stated purpose.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
MCP server for AI dialogue using various LLM models via AceDataCloud
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
MCP server for Qwen Image 3 AI image generation