Connection check
verified live · 27h ago
jgraph-mcp
Create diagrams in chat, rendered as live interactive draw.io diagrams. 10,000+ searchable shapes.
Tools
2
GitHub stars
—
Installs / wk
12k
Licence
—
Transport
streamable-http, stdio
Last checked
27h ago
Tools & capabilities
2 toolsRead from the running server on 27h ago.
create_diagram
read-only
xmlmermaidroutingdirectionpostLayout
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 b… 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 only need to express rough direction; ELK re-lays out the vertices. For those hand-placed diagrams where you omit `postLayout`, consider `routing: "libavoid"` — it leaves your positions untouched and only routes the edges around the boxes in clean right angles (set it whenever connectors would otherwise overlap or cut through shapes). Treat `postLayout` and `routing` as alternatives: ELK already routes its own edges, so if you set `postLayout: "elk"` do NOT also set `routing` (redundant); use `routing` only on a hand-placed layout where you are NOT re-laying-out with ELK. (2) Pick ONE concrete scenario on your first impulse and commit — do not pitch alternatives, do not flip-flop between approaches. (3) Use the rigid grid in the XML reference (`x = col*180 + 40`, `y = row*120 + 40`) without computing spacings, canvas dimensions, or overlap checks. (4) Never add `<Array as="points">` waypoints or `exitX/exitY/entryX/entryY` — when postLayout or routing runs it sets them; otherwise drawio's edge router handles it. (5) Do NOT narrate in your reasoning: no "building the diagram", no column enumeration, no coordinate math in prose, no coordinate re-verification after placement. Go straight to XML. **User preference override — XML only.** If the user expresses a preference for draw.io XML over Mermaid in any phrasing (examples: "no mermaid", "skip mermaid", "use xml", "I want drawio format", "stop using mermaid", "give me the xml", "native drawio only", etc.), from that point onward in the conversation you MUST use the `xml` parameter exclusively and MUST NOT use the `mermaid` parameter, even for diagram types where Mermaid would normally be preferable. This preference persists for the remainder of the conversation unless the user clearly reverses it (e.g. "mermaid is fine again"). When the preference is active, translate any diagram request — including flowcharts, sequence diagrams, ER diagrams, etc. — directly to well-formed mxGraphModel XML. When using XML: IMPORTANT — the XML must be well-formed. Do NOT include ANY XML comments (<!-- -->) in the output. # draw.io XML Reference Detailed reference for styles, edge routing, containers, layers, tags, metadata, and dark mode. Consult this when generating draw.io XML diagrams. ## Reasoning budget (read this first) Your job is to declare the **logical structure** of the diagram — what nodes exist, what edges connect them, what labels they carry, what lane/container groups them. draw.io's edge router and (when available) a post-layout pass handle routing and placement; you do **not** need to do layout math. **Do NOT** in your reasoning: - Do NOT debate the topic. The user asked for a flowchart / architecture / sequence / etc. — pick one concrete scenario on your first impulse and commit. Never write "Actually, let me think of something else…" or pitch alternatives. - Do NOT debate flat-lanes vs nested-pools, horizontal vs vertical orientation, one vs multiple variations. Pick the first reasonable option (almost always: flat swimlanes, top-down or left-right based on what fits the content). Do not flip-flop. - Do NOT compute x/y coordinates in prose. No "column spacings of 160px totaling 1840px width — that's too wide, let me tighten to 1700…" loops. Use the rigid grid below; do the arithmetic in your head and write the XML. - Do NOT re-derive drawio mechanics (`horizontal=0`, `startSize=110`, nested-lane coordinates). Use the templates below as-is. - Do NOT enumerate columns ("customer lane columns 0-10, web app 1-7"). Place a node, move on. - Do NOT add `<Array as="points">` waypoints. Edges are routed automatically. - Do NOT set `exitX` / `exitY` / `entryX` / `entryY` connection-point overrides unless you have specific geometric intent. - Do NOT verify, re-check, or adjust coordinates after placing a node. - Do NOT narrate "building the diagram / finalizing the XML / now let me…". J
search_shapes
read-only
limitquery*