draw.io

Official2 toolsLive

by jgraph · JavaScript

Create diagrams in chat, rendered as live interactive draw.io diagrams. 10,000+ searchable shapes.

io.draw/mcp (MCP) Server

The io.draw/mcp Model Context Protocol (MCP) server creates diagrams in chat and renders them as live, interactive draw.io diagrams. It is the official draw.io MCP server and supports creating and opening diagrams in the draw.io editor, with 10,000+ searchable shapes.

🛠️ Key Features

Live interactive draw.io diagrams rendered from chat
Create and open diagrams in the draw.io editor
10,000+ searchable shapes
Official draw.io MCP server

🚀 Use Cases

Generating diagrams from conversational prompts
Opening generated diagrams directly in draw.io for review/editing

⚡ Developer Benefits

Integration via Model Context Protocol for chat-driven diagram creation
Uses draw.io to view and work with the resulting diagrams

⚠️ Limitations

Description provided does not specify supported environments, authentication, or diagram export/import options

Captured live from the server via tools/list.

create_diagram

Creates and displays an interactive draw.io diagram. Accepts either draw.io XML or Mermaid.js syntax — provide exactly one. **Format decision — this is the first thing to settle before you write anything:** if the diagram type appears on the Mermaid list below, use `mermaid`. Only use `xml` when the diagram type isn't on that list (UI mockups, floorplans, cloud/network/electrical architecture with stencils, hand-placed UML, etc.) or when the user has explicitly asked for draw.io XML. **Use Mermaid** for the following diagram types (all rendered natively, no upstream mermaid runtime): - flowchart / graph (TD, LR, …) - sequenceDiagram - classDiagram - stateDiagram / stateDiagram-v2 - erDiagram - gantt - pie - journey (user-journey) - gitGraph - mindmap - timeline - quadrantChart - xychart-beta - sankey-beta - requirementDiagram - C4Context / C4Container / C4Component - block-beta - architecture-beta - packet-beta - kanban - radar-beta - treemap-beta - treeview-beta (draw.io-specific) - venn (draw.io-specific) — syntax: `venn` then `set A ["Label"]` for each set, `union A,B` for declared overlaps (informational), and `text A` / `text A,B` followed by `["Region label"]` for text inside a region. Do NOT use `A AND B[...]` or `A["..."]` shorthand — those lines are ignored. - ishikawa (draw.io-specific) - zenuml **Strong default: use Mermaid for every diagram type on that list above.** Mermaid is simpler, more reliable, and the native Mermaid layout handles positioning and routing for you. For a flowchart, state diagram, sequence, ER, class, gantt, gitGraph, mindmap, etc. — reach for the `mermaid` parameter, not `xml`. Do not default to XML for flowcharts. **Use XML** when the diagram type isn't on the Mermaid list above OR when the user explicitly asks for XML / draw.io format. Typical cases where XML is the right choice: - **UI mockups / wireframes / screen designs** — buttons, form fields, sidebars, modal dialogs (`shape=mxgraph.bootstrap.*`, `shape=mxgraph.ios.*`, `shape=mxgraph.android.*`) - **Floor plans / seating charts / room layouts** — rooms, doors, furniture (`shape=mxgraph.floorplan.*`) - **Cloud architecture** with AWS / Azure / GCP / Kubernetes icons (`shape=mxgraph.aws4.*`, `shape=mxgraph.azure.*`, `shape=mxgraph.gcp2.*`, `shape=mxgraph.kubernetes.*`) - **Network topology** with Cisco / Rack / networking shapes (`shape=mxgraph.cisco*.*`, `shape=mxgraph.rack.*`, `shape=mxgraph.networking.*`) - **P&ID / electrical / engineering schematics** (`shape=mxgraph.pid2.*`, `shape=mxgraph.electrical.*`, `shape=mxgraph.mscae.*`) - **Swimlanes / pools** with custom colors and hand-placed contents - **UML class / component / deployment diagrams** where positioning carries meaning - **Venn diagrams, quadrant charts, concept maps** with custom regions — anything where hand-placed geometry is the point - **Any diagram requiring specific colors, fonts, stencils, or layouts** that Mermaid can't control precisely Call `search_shapes` first when you need industry icons (AWS / Azure / Cisco / P&ID / Kubernetes / floorplan / mockup / electrical) or brand logos / pictorial concept icons (e.g. 'react', 'slack', 'shopping cart') to find the correct `style` string for each shape. --- **XML reasoning discipline (applies ONLY when you chose XML — skip this whole section if you're using Mermaid):** Your job in XML is declaring logical structure — nodes, edges, labels, groupings. Follow these steps in order: (1) **Decide `postLayout` and `routing` FIRST, before writing any XML.** If the XML diagram is a flowchart, state diagram, decision tree, or any directional/hierarchical process diagram (which you should rarely be writing as XML — prefer Mermaid), you MUST pass `postLayout: "elk"` (add `direction: "horizontal"` when the flow is drawn left-to-right; it defaults to vertical). Omit `postLayout` only when the layout carries hand-crafted meaning (swimlanes, containers, architecture, UML) — the typical reason you chose XML in the first place. When `postLayout` is set, your x/y coordinates

Parameters5

xml	string	optional	draw.io XML content in mxGraphModel format. Must be well-formed XML: no XML comments (<!-- -->), no unescaped special characters in attribute values. Mutually exclusive with 'mermaid'.
mermaid	string	optional	Mermaid.js diagram definition (e.g. 'graph TD\n A-->B'). Supports 26 diagram types — see the tool description for the full list. The diagram is parsed and laid out natively (no upstream mermaid runtime) and converted to draw.io format. Mutually exclusive with 'xml'.
postLayout	string	optional	Optional client-side ELK (Eclipse Layout Kernel) layered-flow pass applied after the diagram renders. The only value is `"elk"`. Vertices animate (morph) from the positions you supplied to the layered layout — they are replaced, so only your edge topology survives. Set it for directional/hierarchical diagrams: flowcharts, process diagrams, state diagrams, decision flows, pipelines, ER/class diagrams with clear parent→child direction. Flow direction (top-down vs left-to-right): for Mermaid it is taken from the flowchart code (`flowchart TD/TB` → top-down, `LR/RL` → left-to-right) — do not try to set it here; for XML set the optional `direction` field (defaults to top-down). Omit for diagrams whose layout carries meaning you hand-crafted: swimlanes/pools, containers, architecture / deployment / network topology with grouped regions, P&ID or circuit schematics, floor plans, UML diagrams with deliberate placement. For Mermaid flowcharts, the native parser does its own layout, but it produces cramped or unbalanced output once the diagram has any structural complexity. Request `postLayout: "elk"` whenever ANY of the following holds: ≥ ~20 nodes, OR ≥ 3 decision diamonds (`{...}` shapes), OR any feedback/back-edges (an edge that points to an earlier node, e.g. an error path looping back to a retry), OR ≥ 3 distinct endpoints — the flow direction follows the flowchart code, so you never pass `direction` for Mermaid. Skip for simple flowcharts (linear chains, < 20 nodes, no branching/back-edges) and for non-flowchart Mermaid types (sequence, class, ER, sankey, etc. — postLayout doesn't apply).
direction	string	optional	XML only — the flow direction for `postLayout: "elk"` on XML diagrams: `vertical` (top-down) or `horizontal` (left-to-right). Defaults to `vertical`. Ignored for Mermaid, where direction is read from the flowchart code (`flowchart TD/TB` vs `LR/RL`). Only meaningful together with `postLayout: "elk"`.
routing	string	optional	XML only — optional obstacle-avoiding orthogonal edge-routing pass (libavoid). The only value is `"libavoid"`. Unlike `postLayout`, this does not move any vertices — it keeps your hand-placed coordinates and only recomputes each edge's path so wires run in clean right-angle segments that route around the boxes instead of cutting through them. Set it for XML diagrams where you have placed nodes deliberately (architecture, network topology, deployment, swimlanes, UML, floor plans) and want tidy connectors without overlaps — exactly the diagrams where you'd OMIT `postLayout`. draw.io's default router is basic (straight or simple right-angle lines with no obstacle avoidance — wires cut straight through any box between the endpoints), so reach for `"libavoid"` whenever edges would otherwise cross shapes or you want uniformly clean orthogonal wiring on a layout you placed yourself. Think of `routing` and `postLayout` as alternatives: use `routing: "libavoid"` to keep your positions and only fix the wires, or `postLayout: "elk"` to re-lay-out the vertices — and note ELK already routes its edges decently, so when you use `postLayout` you normally should not also set `routing` (the combination is redundant in almost all cases). Do not add `<Array as="points">` waypoints yourself when routing is set; libavoid computes them. Ignored for Mermaid (its native/ELK layout already routes).

Raw schema

{
  "type": "object",
  "properties": {
    "xml": {
      "type": "string",
      "description": "draw.io XML content in mxGraphModel format. Must be well-formed XML: no XML comments (<!-- -->), no unescaped special characters in attribute values. Mutually exclusive with 'mermaid'."
    },
    "mermaid": {
      "type": "string",
      "description": "Mermaid.js diagram definition (e.g. 'graph TD\\n  A-->B'). Supports 26 diagram types — see the tool description for the full list. The diagram is parsed and laid out natively (no upstream mermaid runtime) and converted to draw.io format. Mutually exclusive with 'xml'."
    },
    "postLayout": {
      "type": "string",
      "enum": [
        "elk"
      ],
      "description": "Optional client-side ELK (Eclipse Layout Kernel) layered-flow pass applied after the diagram renders. The only value is `\"elk\"`. Vertices animate (morph) from the positions you supplied to the layered layout — they are **replaced**, so only your edge topology survives. Set it for directional/hierarchical diagrams: flowcharts, process diagrams, state diagrams, decision flows, pipelines, ER/class diagrams with clear parent→child direction. Flow direction (top-down vs left-to-right): for **Mermaid** it is taken from the flowchart code (`flowchart TD/TB` → top-down, `LR/RL` → left-to-right) — do not try to set it here; for **XML** set the optional `direction` field (defaults to top-down).\n**Omit** for diagrams whose layout carries meaning you hand-crafted: swimlanes/pools, containers, architecture / deployment / network topology with grouped regions, P&ID or circuit schematics, floor plans, UML diagrams with deliberate placement.\n\n**For Mermaid flowcharts**, the native parser does its own layout, but it produces cramped or unbalanced output once the diagram has any structural complexity. Request `postLayout: \"elk\"` whenever ANY of the following holds: ≥ ~20 nodes, OR ≥ 3 decision diamonds (`{...}` shapes), OR any feedback/back-edges (an edge that points to an earlier node, e.g. an error path looping back to a retry), OR ≥ 3 distinct endpoints — the flow direction follows the flowchart code, so you never pass `direction` for Mermaid. Skip for simple flowcharts (linear chains, < 20 nodes, no branching/back-edges) and for non-flowchart Mermaid types (sequence, class, ER, sankey, etc. — postLayout doesn't apply)."
    },
    "direction": {
      "type": "string",
      "enum": [
        "vertical",
        "horizontal"
      ],
      "description": "**XML only** — the flow direction for `postLayout: \"elk\"` on XML diagrams: `vertical` (top-down) or `horizontal` (left-to-right). Defaults to `vertical`. **Ignored for Mermaid**, where direction is read from the flowchart code (`flowchart TD/TB` vs `LR/RL`). Only meaningful together with `postLayout: \"elk\"`."
    },
    "routing": {
      "type": "string",
      "enum": [
        "libavoid"
      ],
      "description": "**XML only** — optional obstacle-avoiding orthogonal **edge-routing** pass (libavoid). The only value is `\"libavoid\"`. Unlike `postLayout`, this does **not** move any vertices — it keeps your hand-placed coordinates and only recomputes each edge's path so wires run in clean right-angle segments that route *around* the boxes instead of cutting through them. Set it for XML diagrams where you have placed nodes deliberately (architecture, network topology, deployment, swimlanes, UML, floor plans) and want tidy connectors without overlaps — exactly the diagrams where you'd OMIT `postLayout`.\ndraw.io's default router is basic (straight or simple right-angle lines with **no obstacle avoidance** — wires cut straight through any box between the endpoints), so reach for `\"libavoid\"` whenever edges would otherwise cross shapes or you want uniformly clean orthogonal wiring on a layout you placed yourself. Think of `routing` and `postLayout` as **alternatives**: use `routing: \"libavoid\"` to keep your positions and only fix the wires, or `postLayout: \"elk\"` to re-lay-out the vertices — and note ELK already routes its edges decently, so when you use `postLayout` you normally should **not** also set `routing` (the combination is redundant in almost all cases). Do not add `<Array as=\"points\">` waypoints yourself when routing is set; libavoid computes them. **Ignored for Mermaid** (its native/ELK layout already routes)."
    }
  },
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

search_shapes

Search the draw.io shape library by keywords. Returns matching shapes with their exact style strings, dimensions, and titles. Covers ~10,000 built-in stencils (cloud architecture, network topology, P&ID, electrical, Cisco, Kubernetes, BPMN) and, when those are sparse, supplements results with the draw.io icon service (brand/product logos and general-purpose concept icons, e.g. 'react', 'slack', 'shopping cart', 'solar panel'). Use ONLY for diagrams that need industry-specific, branded, or pictorial icons. Do NOT use for standard diagram types like flowcharts, UML, ERD, org charts, or mind maps — these use basic geometric shapes (rectangles, diamonds, circles, cylinders) that are already covered in the XML reference. Also skip if the user asks to use basic/simple shapes or says not to search. The style string from the results can be used directly in mxCell style attributes.

Parameters2

query	string	required	Space-separated search keywords (e.g. 'pid globe valve', 'aws lambda', 'cisco router', 'kubernetes pod')
limit	number	optional	Maximum number of results to return (default: 10, max: 50)

Raw schema

{
  "type": "object",
  "properties": {
    "query": {
      "type": "string",
      "description": "Space-separated search keywords (e.g. 'pid globe valve', 'aws lambda', 'cisco router', 'kubernetes pod')"
    },
    "limit": {
      "type": "number",
      "description": "Maximum number of results to return (default: 10, max: 50)"
    }
  },
  "required": [
    "query"
  ],
  "additionalProperties": false,
  "$schema": "http://json-schema.org/draft-07/schema#"
}

README.md14 KBView on GitHub

Draw.io MCP Server

The official draw.io MCP (Model Context Protocol) server that enables LLMs to create and open diagrams in the draw.io editor.

Four Ways to Create Diagrams

This repository offers four approaches for integrating draw.io with AI assistants. Pick the one that fits your setup:

	MCP App Server	MCP Tool Server	Assistant Plugins	Project Instructions
How it works	Renders diagrams inline in chat	Opens diagrams in your browser	Generates `.drawio` files, optional PNG/SVG/PDF export or browser URL	Claude generates draw.io URLs via Python
Diagram output	Interactive viewer embedded in conversation	draw.io editor in a new tab	`.drawio`, `.drawio.png` / `.svg` / `.pdf`, or browser URL	Clickable link to draw.io
Requires installation	No (hosted at `mcp.draw.io`)	Yes (npm package)	One-line plugin install (draw.io Desktop only for PNG/SVG/PDF export)	No — just paste instructions
Supports XML, CSV, Mermaid	XML only	✅ All three	XML only (native format)	✅ All three
Editable in draw.io	Via "Open in draw.io" button	✅ Directly	✅ Directly	Via link
Works with	Claude.ai, VS Code, Cursor, any MCP Apps host	Claude Desktop, Cursor, OpenCode, any MCP client	Claude Code, Codex CLI, GitHub Copilot, OpenCode	Claude.ai (with Projects)
Best for	Inline previews in chat	Local desktop workflows	Local development workflows	Quick setup, no install needed

MCP App Server

The MCP App server renders draw.io diagrams inline in AI chat interfaces using the MCP Apps protocol. Instead of opening a browser tab, diagrams appear directly in the conversation as interactive iframes.

The official hosted endpoint is available at:

code

https://mcp.draw.io/mcp

Add this URL as a remote MCP server in Claude.ai, Cursor, or any MCP Apps-compatible host — no installation required. On Claude.ai, draw.io is also listed in the connector directory and can be added from there in one click. In Cursor (≥ 2.6), diagrams render inline in the Agent chat (one-click install); on older builds, use the stdio @drawio/mcp tool server instead.

You can also run the server locally via Node.js or Docker, or deploy your own instance to Cloudflare Workers.

Tools:

create_diagram — Renders draw.io XML as an interactive diagram inline in chat
search_shapes — Searches 10,000+ shapes across all draw.io libraries (AWS, Azure, GCP, P&ID, electrical, Cisco, Kubernetes, UML, BPMN, etc.) by keyword, supplemented by the draw.io icon service (brand logos and general-purpose concept icons) when the built-in libraries have no good match. Returns exact style strings that can be used directly in XML. Use this to find the correct shape before calling create_diagram.

Full documentation →

Note: Inline diagram rendering requires an MCP host that supports the MCP Apps extension. In hosts without MCP Apps support, the tool still works but returns the XML as text.

MCP Tool Server

The original MCP server that opens diagrams directly in the draw.io editor. Supports XML, CSV, and Mermaid.js formats with lightbox and dark mode options. Published as @drawio/mcp on npm.

Quick start: npx @drawio/mcp

Setup instructions are available for Claude Desktop, Claude Code, VS Code (GitHub Copilot), Cursor (with one-click install), and OpenCode.

Full documentation →

Assistant Plugins (Claude Code, Codex CLI, GitHub Copilot)

The drawio skill packaged as a plugin for AI coding assistants (under plugins/): it generates native .drawio files, with optional export to PNG, SVG, or PDF (with embedded XML so the exported file remains editable in draw.io) — or a browser URL that opens the diagram directly in app.diagrams.net. No MCP setup required. The same skill ships for three hosts:

Claude Code (full documentation →) — install from this repo's marketplace:

code

/plugin marketplace add jgraph/drawio-mcp
/plugin install drawio@drawio

Or load it directly from a local clone with claude --plugin-dir ./plugins/claude-code.

Codex CLI (full documentation →) — install from the same marketplace repo:

bash

codex plugin marketplace add jgraph/drawio-mcp
codex plugin add drawio@drawio

GitHub Copilot CLI (full documentation →) — install from the same marketplace repo:

bash

copilot plugin marketplace add jgraph/drawio-mcp
copilot plugin install drawio@drawio

Other Copilot surfaces (VS Code agent mode, the coding agent, code review) load the same skill from a repo's .github/skills/ directory instead — see the plugin README.

OpenCode needs no plugin at all: it discovers skills in .opencode/skills/ and .claude/skills/ (and their ~/ equivalents), so the Claude Code skill folder works as-is — see OpenCode (no plugin needed) for the one-line install.

By default, the plugin writes a .drawio file and opens it in draw.io. Mention a format in your request to change the output:

png / svg / pdf — exports using the draw.io desktop CLI with --embed-diagram
url — compresses the XML with Node.js's built-in zlib and opens the result at app.diagrams.net. No draw.io Desktop needed; the .drawio file is kept locally as a persistent copy.

Alternative: Project Instructions (No MCP Required)

An alternative approach that works without installing anything. Add instructions to a Claude Project that teach Claude to generate draw.io URLs using Python code execution. No MCP server, no desktop app — just paste and go.

Full documentation →

Diagram layouts

Two optional, independent layout passes can run after the AI generates a diagram — one re-arranges the nodes, the other only reroutes the edges. Which are available depends on the approach:

Layout pass	What it does	App Server (`create_diagram`)	Tool Server (`open_drawio_xml`)	Assistant Plugins	Project Instructions
ELK auto-layout (`postLayout: "elk"`)	Re-arranges nodes into a clean layered layout; routes the edges as part of it	✅	—	✅ via draw.io Desktop CLI (`--layout`)	—
libavoid routing (`routing: "libavoid"`)	Keeps node positions; reroutes connectors orthogonally around the shapes	✅	✅ from v1.3.0	✅ via draw.io Desktop CLI (`--layout libavoid`)	—

These apply to draw.io XML diagrams. Mermaid diagrams are auto-laid-out already, so neither pass is needed.
The App Server applies these in the inline viewer after the diagram renders; the Tool Server applies libavoid server-side before opening the draw.io editor; the plugins run them through the locally installed draw.io Desktop CLI.
Pick one, not both: ELK already routes its own edges, so adding libavoid on top is redundant. Use postLayout to re-arrange a layout, or routing to tidy the connectors on a layout you placed deliberately.

Data Residency & Offline Use

If you're deploying in an environment with strict data restrictions, here is exactly where diagram data goes for each approach.

No component sends your diagram to a cloud rasterizer. convert.diagrams.net (or any cloud export endpoint) is not called anywhere in this repository, and there is no "local dependency missing → fall back to cloud" path. PNG/SVG/PDF export happens only in the assistant plugins, which shell out to your locally installed draw.io Desktop CLI (located via which drawio); if it isn't installed, the .drawio file is kept and nothing is sent.

Does your diagram leave the machine?

Approach	Diagram leaves the machine?
MCP App Server — hosted (`mcp.draw.io`)	Yes — it is sent to the draw.io server as the MCP request. Self-host instead (below) to keep it local.
MCP App Server — self-hosted (local Node or your own Cloudflare)	No — processed by your server and embedded in HTML that renders client-side.
MCP Tool Server (`@drawio/mcp`)	No — carried in the URL `#fragment`, which browsers do not transmit to the server.
Assistant Plugins (Claude Code, Codex CLI, GitHub Copilot)	No — written locally and exported by your local draw.io Desktop CLI.

By default the servers do not write diagram content to their logs — only request metadata (method, session, status, timing). The Cloudflare-hosted App Server logs response bodies only when run with DEBUG=true.

Reducing external requests

Even when the diagram itself stays local, the rendering loads draw.io's web-app / viewer code from app.diagrams.net and viewer.diagrams.net by default. These fetch application code and assets — not your diagram — but they are still outbound requests. To reduce or remove them:

App Server: build with the VIEWER_PATH environment variable to inline the viewer instead of loading it from viewer.diagrams.net.
Tool Server: set the DRAWIO_BASE_URL environment variable to a self-hosted draw.io instance. Its two server-side passes also fetch code from viewer.diagrams.net once per draw.io release and cache it per user: the libavoid routing core (routing: "libavoid", also primed at install time) and the drawio-elk bundle (postLayout: "elk", fetched on first use, overridable with DRAWIO_ELK_URL). Not requesting those passes makes no such call; the diagram is never part of one either way.
Assistant Plugins: the opt-in url output mode opens the diagram at app.diagrams.net (hardcoded — no DRAWIO_BASE_URL equivalent). Use the default .drawio output or local Desktop export instead if you need to avoid that request.

Your LLM is a separate consideration

The diagram is generated by the LLM. If you use a hosted model, the diagram content is produced in that provider's cloud regardless of where this MCP server runs. End-to-end isolation requires a locally hosted model as well.

Verifying

The only reliable way to confirm a deployment makes no outbound calls is to run it with network egress blocked (or watch the browser's Network tab) and verify it still renders. We recommend this for any strict-isolation deployment.

XML Reference (Single Source of Truth)

The draw.io XML generation reference — covering edge routing, containers, layers, tags, metadata, dark mode, style properties, and XML well-formedness — lives in a single canonical file:

shared/xml-reference.md

All four approaches above use this file as their single source of truth for LLM prompts:

Approach	How it accesses the reference
MCP App Server	Reads the file at startup / build time and includes it in the tool description
MCP Tool Server	Reads the file at startup (from repo or bundled copy via `prepack`)
Assistant Plugins (Claude Code, Codex CLI, GitHub Copilot)	Reference the GitHub raw URL
Project Instructions	Users copy its contents into their Claude Project

When updating XML generation guidance, edit only shared/xml-reference.md — changes propagate to all consumers automatically.

Shape Search Index

The search_shapes tool is powered by a pre-built index of all draw.io shapes. The index is generated from the live draw.io client (https://app.diagrams.net/js/app.min.js) by running all sidebar palette initializations in Node.js via jsdom and capturing the shape data.

Icons from the draw.io icon service (icons.diagrams.net — the same grouped icon search the editor sidebar uses) are not part of this index: search_shapes queries the service live when the local index has no strong match for a query, returning the icons as shape=image styles. Set DRAWIO_ICON_SERVICE_URL to a self-hosted service to override the endpoint, or to off to disable icon supplementation.

shape-search/search-index.json is committed to the repository and is automatically refreshed on every draw.io release via the Update Shape Search Index GitHub Action — no manual step is required to stay in sync with the latest shapes.

To regenerate the index manually (e.g. when iterating on the generator itself):

bash

cd shape-search
npm install
npm run generate

# Rebuild the MCP App Server worker to embed the updated index
cd ../mcp-app-server
npm run build:worker

The generator fetches app.min.js directly from the public draw.io web app, so no local checkout of the draw.io source is needed.

Development

bash

# MCP App Server
cd mcp-app-server
npm install
npm start

# MCP Tool Server
cd mcp-tool-server
npm install
npm start

draw.io - Free online diagram editor
draw.io Desktop - Desktop application
@drawio/mcp on npm - This package on npm
drawio-mcp on GitHub - Source code repository
Mermaid.js Documentation
MCP Specification
MCP Apps Extension

Install

Tools (2)

create_diagramsearch_shapes

Remote endpoint

Streamable HTTP

Hosted server - connect over the network, no local install.

url

https://mcp.draw.io/mcp

Add to VS Code Add to Cursor

claude_desktop_config.json

json

{
  "mcpServers": {
    "mcp": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.draw.io/mcp"
      ]
    }
  }
}

Desktop config is stdio-only; this bridges via mcp-remote. Native remote: Settings > Connectors.

io.draw/mcp (MCP) Server

🛠️ Key Features

🚀 Use Cases

⚡ Developer Benefits

⚠️ Limitations

create_diagram

search_shapes

Draw.io MCP Server

Four Ways to Create Diagrams

MCP App Server

MCP Tool Server

Assistant Plugins (Claude Code, Codex CLI, GitHub Copilot)

Alternative: Project Instructions (No MCP Required)

Diagram layouts

Data Residency & Offline Use

Does your diagram leave the machine?

Reducing external requests

Your LLM is a separate consideration

Verifying

XML Reference (Single Source of Truth)

Shape Search Index

Development

Related Resources

Install

Remote endpoint

Related servers