@drawio/mcp

What changed

Changed 2026-10-15 11:39 UTC

2 descriptions rewritten, 1 tool added.

+ tool added: get_drawio_reference

--- pinned/open_drawio_mermaid
+++ observed/open_drawio_mermaid
  {
-   "description": "Opens the draw.io editor with a diagram generated from Mermaid.js syntax. Supports flowcharts, sequence diagrams, class diagrams, state diagrams, entity relationship diagrams, and more using Mermaid.js syntax.\n\n# Mermaid Reference\n\nShort hints for generating Mermaid diagrams that render correctly in draw.io. draw.io's Mermaid parser covers 28 diagram types — the header keyword on the first non-directive line selects the type.\n\n_Canonical list & dialog/ELK docs: <https://github.com/jgraph/drawio/discussions/5643>._\n\n## General rules\n\n- **Pick the type keyword carefully.** `graph`/`flowchart`, `classDiagram`, `stateDiagram-v2`, `erDiagram`, `sequenceDiagram`, `gitGraph`, `journey`, `pie`, `gantt`, `mindmap`, `timeline`, `quadrantChart`, `requirementDiagram`, `sankey-beta`, `xychart-beta`, `block-beta`, `c4Context`/`C4Container`/`C4Component`, `architecture-beta`, `radar-beta`, `packet-beta`, `venn-beta`, `treemap-beta`, `treeView-beta`, `ishikawa-beta`, `kanban`, `zenuml`, `wardley-beta`, `eventmodeling`. Misspelling the header yields a blank diagram.\n- **No trailing punctuation on node IDs.** IDs are identifiers (`myNode`, `node_1`, `A`) — spaces, hyphens (in some contexts), and reserved words (`end`, `class`, `subgraph`) break the parse. Put display text in brackets or quotes instead: `A[\"User's Account\"]`.\n- **One statement per line.** Separate statements with newlines; `;` works as a delimiter in flowchart but not everywhere.\n- **Quote labels with special characters** (`:`, `-`, parentheses, non-ASCII). Use `\"` not `'`.\n- **HTML in labels:** only `<br>`, `<b>`, `<i>`, `<u>` are reliable across types. Use `#` for hex colors in styles, never `rgb()`.\n- **Diagrams can take a title block** for some types:\n  ```\n  ---\n  title: My Diagram\n  ---\n  flowchart TD\n  ```\n- **Match the language of labels to the user's language** — if the user writes in German, French, etc., the diagram labels should be in that language too.\n\n## Flowchart (most common)\n\n```\nflowchart TD\n  A[Start] --> B{Decision?}\n  B -->|Yes| C[Do thing]\n  B -->|No| D[Skip]\n  C --> E((End))\n  D --> E\n```\n\n- **Direction:** `TD`/`TB` (top-down), `BT`, `LR`, `RL`.\n- **Node shapes by bracket:** `[rect]`, `(rounded)`, `([stadium])`, `[[subroutine]]`, `[(cylinder)]`, `((circle))`, `{rhombus}`, `{{hexagon}}`, `[/parallelogram/]`, `[\\parallelogram alt\\]`, `[/trapezoid\\]`, `>asymmetric]`.\n- **Edges:** `-->` arrow, `---` no arrow, `-.->` dotted, `==>` thick, `<-->` bidirectional. Inline label: `A -- text --> B` or `A -->|text| B`.\n- **Subgraphs:**\n  ```\n  subgraph Frontend\n    A --> B\n  end\n  ```\n\n### Layout for complex flowcharts\n\ndraw.io's Mermaid parser lays flowcharts out itself, but the result gets cramped or unbalanced once the diagram has any structural complexity. Switch that flowchart to the **ELK layered layout** (the same engine as draw.io's *Arrange ▸ Layout ▸ Vertical/Horizontal Flow*) when ANY of these holds:\n\n- ≥ ~20 nodes, OR\n- ≥ 3 decision diamonds (`{...}`), OR\n- any feedback/back-edge (an edge pointing back to an earlier node — an error path looping to a retry), OR\n- ≥ 3 distinct endpoints.\n\nTwo ways to ask for it, depending on the tool:\n\n- **A `postLayout: \"elk\"` field** on the call, if the tool offers one — use it.\n- **Otherwise select it in the source**, as a YAML frontmatter block at the very top. draw.io honors it wherever it converts Mermaid (editor, opened link, desktop CLI):\n  ```\n  ---\n  config:\n    layout: elk\n  ---\n  flowchart TD\n    A[Start] --> B{Retry?}\n  ```\n  Combines with a `title:` — both are keys of the same frontmatter block.\n\nThe flow direction always follows the flowchart code (`TD`/`TB` vs `LR`/`RL`). **Flowcharts only** — sequence, class, ER, gantt and the rest lay themselves out and ignore the setting. Simple flowcharts (linear chains, < 20 nodes, no branching or back-edges) don't need it either.\n\n### Styling & colors\n\nThree ways — pick one, don't mix for the same node:\n\n**1. Inline per-node (`style`):**\n```\nflowchart LR\n  A[Start] --> B[End]\n  style A fill:#f9f,stroke:#333,stroke-width:2px,color:#fff\n  style B fill:#bbf,stroke:#f66,stroke-dasharray:5 5\n```\n\n**2. Reusable classes (`classDef` + `:::`):**\n```\nflowchart LR\n  A:::happy --> B:::sad\n  classDef happy fill:#dfd,stroke:#0a0\n  classDef sad fill:#fdd,stroke:#a00\n```\nOr apply to many: `class A,B,C happy`.\n\n**3. Link styling (edges):**\n```\nlinkStyle 0 stroke:#f00,stroke-width:3px\nlinkStyle default stroke:#999\n```\n`0` = first edge in order defined; `default` targets unstyled edges.\n\nStyle properties that work: `fill`, `stroke`, `stroke-width`, `stroke-dasharray`, `color` (font color).\n\n## Sequence diagram\n\n```\nsequenceDiagram\n  participant U as User\n  participant S as Server\n  U->>S: Request\n  S-->>U: Response\n  Note right of S: Logged\n```\n\n- **Arrows:** `->` (no head), `->>` (arrow), `-->>` (dashed), `-x` (X end), `--x` (dashed X).\n- **Activate/deactivate:** `activate S` / `deactivate S` or `S->>+S2: call` / `S2-->>-S: return`.\n- **Blocks:** `alt/else/end`, `opt/end`, `loop/end`, `par/and/end`, `critical/option/end`.\n- **Notes:** `Note left of A`, `Note over A,B: text`.\n- Optional `autonumber` after header numbers the messages.\n\n## Class diagram\n\n```\nclassDiagram\n  class Animal {\n    +String name\n    +int age\n    +eat() void\n  }\n  class Dog\n  Animal <|-- Dog : inherits\n  Dog \"1\" --> \"*\" Bone : has\n```\n\n- **Relations:** `<|--` inherit, `*--` composition, `o--` aggregation, `-->` association, `..>` dependency, `..|>` realize, `<-->` bidirectional.\n- **Visibility:** `+` public, `-` private, `#` protected, `~` package.\n- **Annotations:** `<<interface>>`, `<<abstract>>`, `<<enumeration>>` inside the class block or via `Animal <<interface>>`.\n- **Cardinality:** quoted strings flanking the arrow (`\"1\"`, `\"0..*\"`, `\"*\"`).\n\n## State diagram\n\n```\nstateDiagram-v2\n  [*] --> Idle\n  Idle --> Running : start\n  Running --> Idle : stop\n  Running --> [*]\n  state Running {\n    [*] --> Working\n    Working --> Waiting : block\n    Waiting --> Working : unblock\n  }\n```\n\n- Use `stateDiagram-v2`, not `stateDiagram` (v1 is legacy).\n- `[*]` = start (source) or end (target) depending on direction.\n- `state X { ... }` nests a compound state; `state fork1 <<fork>>`, `<<join>>`, `<<choice>>` mark junction nodes.\n- Transition labels: `A --> B : event [guard] / action`.\n\n## ER diagram\n\n```\nerDiagram\n  CUSTOMER ||--o{ ORDER : places\n  ORDER ||--|{ LINE-ITEM : contains\n  CUSTOMER {\n    string name\n    string email PK\n  }\n```\n\n- **Cardinality symbols:** `|o` zero-or-one, `||` exactly-one, `}o` zero-or-many, `}|` one-or-many. Mirror on both sides (e.g., `||--o{`).\n- Attribute blocks list `type name [PK|FK|UK]` plus optional comment in quotes.\n- Entity names are typically UPPERCASE by convention.\n\n## Journey\n\n```\njourney\n  title Morning routine\n  section Wake up\n    Coffee: 5: Me\n    Read news: 3: Me\n  section Commute\n    Drive: 2: Me, Traffic\n```\n\nEach task: `Name: score(1-5): Actor[, Actor...]`. Section headers group tasks.\n\n## Pie\n\n```\npie showData title Browser share\n  \"Chrome\" : 60\n  \"Firefox\" : 20\n  \"Safari\" : 20\n```\n\n`showData` is optional (renders the numbers). Quotes on labels, colon, numeric value.\n\n## Gantt\n\n```\ngantt\n  title Project timeline\n  dateFormat YYYY-MM-DD\n  section Phase 1\n  Design : a1, 2025-01-01, 7d\n  Build  : after a1, 14d\n  section Phase 2\n  Test   : 2025-01-25, 5d\n```\n\n- `dateFormat` is mandatory.\n- Task line: `Name : [id,] [after id | YYYY-MM-DD], duration[d/w]`.\n- Status tags: `done`, `active`, `crit` before the id (`crit a1`).\n\n## Gitgraph\n\n```\ngitGraph\n  commit\n  branch develop\n  checkout develop\n  commit\n  commit\n  checkout main\n  merge develop\n```\n\nCommands: `commit [id: \"x\"] [tag: \"v1\"]`, `branch name`, `checkout name`, `merge name`, `cherry-pick id: \"x\"`.\n\n## Mindmap\n\n```\nmindmap\n  root((Project))\n    Frontend\n      React\n      CSS\n    Backend\n      Node\n      DB\n```\n\n- Indentation (2-space increments) defines hierarchy.\n- Root shape: `((circle))`, `[rect]`, `(rounded)`, `))cloud((`, `)hexagon(`, `{{hexagon}}`.\n- No edges — they are implied by nesting.\n\n## Timeline\n\n```\ntimeline\n  title Company history\n  section 2020s\n    2021 : Founded\n    2022 : Series A\n         : Launched product\n  section 2030s\n    2030 : IPO\n```\n\nColon separates year/label; multiple `:` lines under one year add sub-events.\n\n## Quadrant chart\n\n```\nquadrantChart\n  title Reach vs Engagement\n  x-axis Low --> High\n  y-axis Low --> High\n  quadrant-1 Stars\n  quadrant-2 Question Marks\n  quadrant-3 Dogs\n  quadrant-4 Cash Cows\n  Campaign A: [0.3, 0.6]\n  Campaign B: [0.75, 0.85]\n```\n\nPoint coords are `[0..1, 0..1]`.\n\n## Requirement diagram\n\n```\nrequirementDiagram\n  requirement req1 {\n    id: \"1\"\n    text: \"The system shall...\"\n    risk: high\n    verifymethod: test\n  }\n  element user_story {\n    type: \"story\"\n  }\n  user_story - satisfies -> req1\n```\n\nRequirement types: `requirement`, `functionalRequirement`, `performanceRequirement`, `interfaceRequirement`, `physicalRequirement`, `designConstraint`. Relations: `contains`, `copies`, `derives`, `satisfies`, `verifies`, `refines`, `traces`.\n\n## Sankey\n\n```\nsankey-beta\nSource,Intermediate,10\nSource,Direct,5\nIntermediate,Sink,10\n```\n\nCSV-style: `source,target,value`. No header. No `title` (use frontmatter).\n\n## XY chart\n\n```\nxychart-beta\n  title \"Revenue\"\n  x-axis [jan, feb, mar, apr]\n  y-axis \"USD\" 0 --> 10000\n  bar [2500, 5000, 7500, 9000]\n  line [3000, 4500, 6500, 8500]\n```\n\n`bar [...]` and `line [...]` can stack; order matters (later overlays earlier).\n\n## Block\n\n```\nblock-beta\n  columns 3\n  A B C\n  D[\"Wide\"]:2 E\n  A --> D\n```\n\n`columns N` sets grid width. `Name:N` spans N columns. Edges use flowchart arrow syntax.\n\n## C4\n\n```\nC4Context\n  Person(user, \"User\")\n  System(app, \"App\", \"Does things\")\n  Rel(user, app, \"Uses\")\n```\n\n- Variants: `C4Context`, `C4Container`, `C4Component`, `C4Dynamic`, `C4Deployment`.\n- Element helpers: `Person`, `System`, `System_Ext`, `Container`, `ComponentDb`, `Boundary(id, \"label\", \"type\")`, etc. Arguments are positional: `(id, label, [type/tech], [description])`.\n- `UpdateElementStyle(tag, $bgColor=\"#…\")` and `AddElementTag` tweak appearance.\n\n## Architecture\n\n```\narchitecture-beta\n  group cloud(cloud)[Cloud]\n  service api(server)[API] in cloud\n  service db(database)[DB] in cloud\n  api:R --> L:db\n```\n\n- Built-in icons: `cloud`, `server`, `database`, `disk`, `internet`. Suffix edge ends with `:T`, `:B`, `:L`, `:R` to pick the side.\n- `group id(icon)[Label]` then `in groupId` on services places nodes.\n\n## Radar\n\n```\nradar-beta\n  title Skills\n  axis js[\"JS\"], py[\"Python\"], go[\"Go\"]\n  curve alice[\"Alice\"]{80, 60, 70}\n  curve bob[\"Bob\"]{50, 90, 65}\n```\n\nAxes and curves are positionally aligned — list values in axis order, 0–100.\n\n## Packet\n\n```\npacket-beta\n  0-15: \"Source Port\"\n  16-31: \"Dest Port\"\n  32-63: \"Seq Number\"\n```\n\n`start-end` (bit ranges) or single-bit `N`. Use a title frontmatter.\n\n## Venn\n\n```\nvenn-beta\n  set A [\"Set A\"]\n  set B [\"Set B\"]\n  union A,B\n  text A [\"only A\"]\n  text A,B [\"shared\"]\n```\n\nDefine every `union` combination whose region you plan to label. `text A,B [...]` places text in intersections.\n\n## Treemap\n\n```\ntreemap-beta\n\"Category\"\n    \"Leaf 1\": 40\n    \"Leaf 2\": 60\n```\n\nNumbers are values (area-weighted). Indent (2+ spaces) for hierarchy.\n\n## Tree view\n\n```\ntreeView-beta\n  \"Root\"\n    \"Child 1\"\n      \"Grandchild\"\n    \"Child 2\"\n```\n\nPure indentation hierarchy, no numbers.\n\n## Ishikawa (fishbone)\n\n```\nishikawa-beta\n  Main Problem\n    Category\n      Cause\n      Sub-cause\n    Another Category\n      Cause\n```\n\nFirst line after header is the problem; top-level indents are categories (Materials, Methods, Machinery, etc. — use whatever makes sense).\n\n## Kanban\n\n```\nkanban\n  todo[To Do]\n    task1[Write spec]@{ assigned: \"Alice\", priority: \"High\" }\n  doing[In progress]\n    task2[Build feature]\n  done[Done]\n```\n\nColumns are `id[Label]` at indent 0; cards are `id[Label]@{ metadata }` inside. Metadata keys: `assigned`, `priority` (`Very Low`/`Low`/`Medium`/`High`/`Very High`), `ticket`.\n\n## ZenUML\n\n```\nzenuml\n  @Actor User\n  @Boundary Web\n  @Control Service\n  User -> Web: request\n  Web -> Service: process()\n  Service -> Web: result\n```\n\nParticipant roles: `@Actor`, `@Boundary`, `@Control`, `@Entity`, `@Database`. Messages use `->` with a colon-separated label. Supports `if/else`, `while`, `par` blocks like sequence diagrams.\n\n## Wardley map\n\n```\nwardley-beta\n  title Tea Shop\n  anchor Business [0.95, 0.63]\n  component Cup of Tea [0.79, 0.61]\n  component Kettle [0.43, 0.35] (inertia)\n  Business -> Cup of Tea\n  Cup of Tea -> Kettle\n  evolve Kettle 0.62\n```\n\n- Header `wardley` or `wardley-beta`; `title` optional.\n- `anchor`/`component Name [visibility, evolution]` — coords are `[0..1, 0..1]` (y = value-chain visibility, x = evolution from Genesis to Commodity).\n- Component evolution markers in parens: `(inertia)`, `(build)`, `(buy)`, `(outsource)`, `(market)`.\n- Links: `A -> B` dependency, `A +> B` flow. `evolve Name <x>` adds an evolution target; `evolution Genesis -> Custom -> Product -> Commodity` relabels the x-axis stages.\n- Extras: `note \"text\" [x,y]`, `annotation N,[x,y] \"text\"`, `accelerator`/`deaccelerator \"text\" [x,y]`.\n\n## Event Modeling\n\n```\neventmodeling\n  tf 01 ui CartUI\n  tf 02 cmd AddItem\n  tf 03 evt ItemAdded\n  tf 04 rmo Cart\n```\n\n- Each `tf <id> <type> <Name>` is a time-frame (column). Types: `ui` / `pcr` (processor), `cmd` / `command`, `rmo` / `readmodel`, `evt` / `event` — placed on the UI/Automation, Command/Read-Model, and Events swimlanes.\n- Wire frames with `->>`: `tf 04 evt ItemChanged ->> 02 ->> 03` links frame 04 back to 02 and 03.\n- `Namespace.Name` groups frames into slices (e.g. `Order.ChangeOrder`).\n- `data <id> { ... }` blocks attach payloads, referenced inline with `[[id]]`: `tf 02 cmd AddItem [[AddItem01]]`.\n\n## When to prefer XML over Mermaid\n\n- Precise positions / custom coordinates.\n- draw.io-native shapes (AWS, Azure, GCP, P&ID, Cisco, electrical).\n- Mixed shape libraries or complex multi-layer diagrams.\n- Anything that needs exact colors per element with many variations — Mermaid's styling works but at scale XML is easier to reason about.\n\nDefault to Mermaid for the standard types above; reach for XML only when Mermaid's syntax clearly can't express what's needed.\n",
+   "description": "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).\n\nCall 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.",
    "inputSchema": {
      "properties": {
        "content": {

--- pinned/open_drawio_xml
+++ observed/open_drawio_xml
  {
-   "description": "Opens the draw.io editor with a diagram from XML content. Use this to view, edit, or create diagrams in draw.io format. The XML should be valid draw.io/mxGraph XML format.\n\n# draw.io XML Reference\n\nDetailed reference for styles, edge routing, containers, layers, tags, metadata, and dark mode. Consult this when generating draw.io XML diagrams.\n\n## Reasoning budget (read this first)\n\nYour 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. The edge router and the optional layout pass (`postLayout: \"elk\"`, see **Edge routing & layout passes**) handle routing and placement; you do **not** need to do layout math.\n\n**Do NOT** in your reasoning:\n\n- 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.\n- 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.\n- 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.\n- Do NOT re-derive drawio mechanics (`horizontal=0`, `startSize=110`, nested-lane coordinates). Use the templates below as-is.\n- Do NOT enumerate columns (\"customer lane columns 0-10, web app 1-7\"). Place a node, move on.\n- Do NOT add `<Array as=\"points\">` waypoints. Edges are routed automatically.\n- Do NOT set `exitX` / `exitY` / `entryX` / `entryY` connection-point overrides unless you have specific geometric intent.\n- Do NOT verify, re-check, or adjust coordinates after placing a node.\n- Do NOT narrate \"building the diagram / finalizing the XML / now let me…\". Just emit XML.\n- Do NOT write out lists of node positions as planning text. Emit them as `<mxCell>` elements directly.\n\n**Do** in your reasoning:\n\n- Identify the diagram type + actors/stages (1-2 short sentences).\n- Identify any grouping (swimlanes? containers? none?).\n- Go straight to XML.\n\n**Rigid grid — use for every XML diagram:**\n\n- Column x = `col_index * 180 + 40`  (col 0 = 40, col 1 = 220, col 2 = 400, …)\n- Row y = `row_index * 120 + 40`     (row 0 = 40, row 1 = 160, row 2 = 280, …)\n- Node size: rectangles `140×60`, diamonds `140×80`, circles `60×60`, documents `120×80`, cylinders `100×70`\n\nPick a `(col, row)` for each node. Don't think about centers or exact gaps — the grid already spaces nodes apart, and slight misalignment is invisible in the result.\n\n**Give every node its own `(col, row)` cell.** Two nodes in the same cell land on top of each other. With `postLayout: \"elk\"` the positions are only a rough starting direction (ELK re-places everything); without it they are the final positions, so the cell you pick is what the user sees.\n\n## General principles\n\n- **Use proper draw.io shapes and connectors** — choose the semantically correct shape for each element (e.g., `shape=cylinder3` for databases and tanks, `rhombus` for decisions, `shape=mxgraph.pid2valves.*` for valves in P&IDs). draw.io has extensive shape libraries; prefer domain-appropriate shapes over generic rectangles.\n- **Decide whether to search for shapes** — before generating a diagram, decide if it needs domain-specific shapes from draw.io's extended libraries. **Skip `search_shapes`** for standard diagram types that use basic geometric shapes: flowcharts, UML (class, sequence, state, activity), ERD, org charts, mind maps, Venn diagrams, timelines, wireframes, and any diagram using only rectangles, diamonds, circles, cylinders, and arrows. Also skip if the user explicitly asks to use basic/simple shapes or says not to search. **Use `search_shapes`** when the diagram requires industry-specific or branded icons: cloud architecture (AWS, Azure, GCP), network topology (Cisco, rack equipment), P&ID (valves, instruments, vessels), electrical/circuit diagrams, Kubernetes, BPMN with specific task types, or any domain where the user expects realistic/standardized symbols rather than labeled boxes. It also finds brand/product logos and general-purpose pictorial icons (e.g. `react`, `slack`, `shopping cart`, `solar panel`) — returned as ready-to-use `shape=image` styles — so use it too when the user asks for logos or everyday concept icons.\n- **Match the language of labels to the user's language** — if the user writes in German, French, Japanese, etc., all diagram labels, titles, and annotations should be in that same language.\n- **Group related nodes, and surface a hub when edges converge** — put nodes that belong together inside a container or swimlane, and keep external actors (users, files, third-party systems) outside implementation containers. When many edges converge on one area or cross several groups, route them through a single hub/gateway node (a registry, broker, event log, …) instead of drawing every low-level dependency across the canvas — fewer crossings, clearer contract.\n- **Encode secondary detail in node text, not edges** — draw an edge only when the relationship itself carries meaning; push incidental detail into the node label so the connector layer stays readable.\n- **File each edge at the innermost container holding BOTH endpoints** — `parent=\"<container_id>\"` when both ends sit in the same container (at any nesting depth), `parent=\"1\"` when one end is outside all containers. Auto-layout reads an edge's coordinates in its parent's frame, so an edge parked further out than its endpoints is laid out in the wrong place. Details under [Nested architecture containers](#nested-architecture-containers-cloud-infra-network-topologies).\n\n## Common styles\n\n**Rounded rectangle:**\n```xml\n<mxCell id=\"2\" value=\"Label\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"100\" y=\"100\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n```\n\n**Diamond (decision):**\n```xml\n<mxCell id=\"3\" value=\"Condition?\" style=\"rhombus;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"100\" y=\"200\" width=\"120\" height=\"80\" as=\"geometry\"/>\n</mxCell>\n```\n\n**Arrow (edge):**\n```xml\n<mxCell id=\"4\" value=\"\" style=\"edgeStyle=orthogonalEdgeStyle;html=1;\" edge=\"1\" source=\"2\" target=\"3\" parent=\"1\">\n  <mxGeometry relative=\"1\" as=\"geometry\"/>\n</mxCell>\n```\n\n**Labeled arrow:**\n```xml\n<mxCell id=\"5\" value=\"Yes\" style=\"edgeStyle=orthogonalEdgeStyle;html=1;\" edge=\"1\" source=\"3\" target=\"6\" parent=\"1\">\n  <mxGeometry relative=\"1\" as=\"geometry\"/>\n</mxCell>\n```\n\n## Style properties\n\n| Property | Values | Use for |\n|----------|--------|---------|\n| `rounded=1` | 0 or 1 | Rounded corners |\n| `whiteSpace=wrap` | wrap | Text wrapping |\n| `fillColor=#dae8fc` | Hex color | Background color |\n| `strokeColor=#6c8ebf` | Hex color | Border color |\n| `fontColor=#333333` | Hex color | Text color |\n| `shape=cylinder3` | shape name | Database cylinders |\n| `shape=mxgraph.flowchart.document` | shape name | Document shapes |\n| `ellipse` | style keyword | Circles/ovals |\n| `rhombus` | style keyword | Diamonds |\n| `edgeStyle=orthogonalEdgeStyle` | style keyword | Right-angle connectors |\n| `edgeStyle=elbowEdgeStyle` | style keyword | Elbow connectors |\n| `dashed=1` | 0 or 1 | Dashed lines |\n| `swimlane` | style keyword | Swimlane containers |\n| `group` | style keyword | Invisible container (pointerEvents=0) |\n| `container=1` | 0 or 1 | Enable container behavior on any shape |\n| `pointerEvents=0` | 0 or 1 | Prevent container from capturing child connections |\n| `html=1` | 0 or 1 | Enable HTML rendering in labels (required for `<b>`, `<br>`, `<font>`, etc.) |\n| `shape=umlLifeline;perimeter=lifelinePerimeter;size=16` | shape | UML sequence diagram lifeline (size = header height) |\n\n## HTML labels\n\n**Always include `html=1` in the style** when the `value` attribute contains any HTML tags (`<b>`, `<br>`, `<font>`, `<i>`, `<u>`, `<hr>`, `<p>`, `<table>`, etc.). Without `html=1`, HTML tags are displayed as literal text instead of being rendered.\n\nHTML in attribute values must be **XML-escaped**: `<` → `&lt;`, `>` → `&gt;`, `&` → `&amp;`, `\"` → `&quot;`\n\n```xml\n<mxCell value=\"&lt;b&gt;Title&lt;/b&gt;&lt;br&gt;Description\"\n        style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"100\" y=\"100\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n```\n\n**Line breaks:** Use `&#xa;` (works with both `html=1` and `html=0`) or `&lt;br&gt;` (requires `html=1`) for line breaks — never use `\\n`, which renders as literal backslash-n text instead of a newline.\n\n**Best practice:** Always include `html=1` in every cell style. This ensures labels render correctly whether they contain HTML or plain text — plain text is unaffected by the flag.\n\n**Bold/italic/underline:** Use `fontStyle` in the style string when the entire label should be bold (`fontStyle=1`), italic (`fontStyle=2`), or underline (`fontStyle=4`). Values can be combined via bitwise OR (e.g., `fontStyle=3` = bold+italic). Use HTML tags (`<b>`, `<i>`, `<u>`) only when formatting part of the label (e.g., bold title with normal description). Never combine `fontStyle` with HTML tags for the same effect — this is redundant and causes visible raw tags if `html=1` is missing.\n\n## Edges\n\n**CRITICAL: Every edge `mxCell` must contain a `<mxGeometry relative=\"1\" as=\"geometry\" />` child element.** Self-closing edge cells (e.g. `<mxCell ... edge=\"1\" ... />`) are invalid and will not render correctly. Always use the expanded form:\n```xml\n<mxCell id=\"e1\" edge=\"1\" parent=\"1\" source=\"a\" target=\"b\" style=\"...\">\n  <mxGeometry relative=\"1\" as=\"geometry\" />\n</mxCell>\n```\n\n**Don't hand-route edges.** Just declare `source` and `target`. You do **not** need to:\n- Add `<mxPoint>` waypoints\n- Set `exitX` / `exitY` / `entryX` / `entryY`\n- Route around obstacles\n- Worry about edge-vertex collisions or parallel edge spacing\n\ndraw.io's built-in router is **basic**: it draws each edge as a straight line or a simple right-angle path between `source` and `target`, with **no awareness of other shapes** — a wire will run straight across any box that sits between its endpoints. That's fine when connected nodes have open space between them. When edges would otherwise cross over shapes, or you want consistently clean orthogonal wires that route *around* the boxes, set **`routing: \"libavoid\"`**; for a full re-layout use **`postLayout: \"elk\"`** (see **Edge routing & layout passes** below). Both compute the waypoints for you — you never add them by hand either way.\n\n**What you still choose: the edge style.** The style determines the overall look (orthogonal angles, curves, straight lines) — the router honors the style family.\n\n| Style | Syntax | Best for |\n|-------|--------|---------|\n| **Orthogonal** | `edgeStyle=orthogonalEdgeStyle` | Flowcharts, architecture, network diagrams, BPMN — any diagram with right-angle connectors |\n| **Straight** | no `edgeStyle` | UML class/sequence diagrams, direct point-to-point connections. For sequence diagram messages use `endSize=6;startSize=6;` to keep arrowheads small |\n| **Entity Relation** | `edgeStyle=entityRelationEdgeStyle` | ER diagrams — creates perpendicular stubs at both ends |\n| **Curved** | `curved=1` | Mind maps, informal diagrams |\n| **Elbow** | `edgeStyle=elbowEdgeStyle;elbow=vertical;` | Rarely needed — `orthogonalEdgeStyle` handles almost all cases; use this only for simple 1-bend linear flows |\n\n**Use a consistent edge style within each diagram.** Pick one based on diagram type and apply it to all edges: ER → `entityRelationEdgeStyle`; UML class → straight; mind maps → curved; flowcharts/architecture/network → `orthogonalEdgeStyle`.\n\n**Useful edge style attributes** that apply regardless of routing:\n- `rounded=1` — rounded corners at bend points (recommended for orthogonal)\n- `endArrow=classic` / `endArrow=none` — arrow heads\n- `dashed=1` — dashed line\n- `strokeColor=#...`, `strokeWidth=2` — color/width\n- Edge labels: set `value` directly on the edge cell\n\n**Keep edge labels short and meaningful** — one to three words (`Yes`, `async`, `reads`). Drop labels that merely restate an obvious action (`call`, `register`); move longer explanations into node text or a small legend node.\n\n**Visual semantics — stay consistent, add a legend when mixing styles.** Within one diagram apply `dashed=1`, `strokeColor`, and `strokeWidth` consistently for one chosen meaning (e.g. dashed = optional / async / inferred relationship). Don't mix several dashed meanings without a small legend explaining them.\n\n## Containers and groups\n\nFor architecture diagrams or any diagram with nested elements, use draw.io's proper parent-child containment — do **not** just place shapes on top of larger shapes.\n\n### How containment works\n\nSet `parent=\"containerId\"` on child cells. Children use **relative coordinates** within the container.\n\n### Container types\n\n| Type | Style | When to use |\n|------|-------|-------------|\n| **Group** (invisible) | `group;` | No visual border needed, container has no connections. Includes `pointerEvents=0` so child connections are not captured |\n| **Swimlane** (titled) | `swimlane;startSize=30;` | Container needs a visible title bar/header, or the container itself has connections |\n| **Custom container** | Add `container=1;pointerEvents=0;` to any shape style | Any shape acting as a container without its own connections |\n\n### Key rules\n\n- **Edges to children inside containers naturally cross the container boundary** — this is correct and expected. Do not add extra waypoints or complex routing to avoid a parent container when connecting to shapes inside it.\n- **Always add `pointerEvents=0;`** to container styles that should not capture connections being rewired between children\n- Only omit `pointerEvents=0` when the container itself needs to be connectable — in that case, use `swimlane` style which handles this correctly (the client area is transparent for mouse events while the header remains connectable)\n- Children must set `parent=\"containerId\"` and use coordinates **relative to the container**\n\n### Example: Architecture container with swimlane\n\n```xml\n<mxCell id=\"svc1\" value=\"User Service\" style=\"swimlane;startSize=30;fillColor=#dae8fc;strokeColor=#6c8ebf;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"100\" y=\"100\" width=\"300\" height=\"200\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"api1\" value=\"REST API\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"svc1\">\n  <mxGeometry x=\"20\" y=\"40\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"db1\" value=\"Database\" style=\"shape=cylinder3;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"svc1\">\n  <mxGeometry x=\"160\" y=\"40\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n```\n\n### Example: Invisible group container\n\n```xml\n<mxCell id=\"grp1\" value=\"\" style=\"group;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"100\" y=\"100\" width=\"300\" height=\"200\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"c1\" value=\"Component A\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"grp1\">\n  <mxGeometry x=\"10\" y=\"10\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n```\n\n### Swimlanes for grouped actors (BPMN-style flowcharts)\n\nUse **flat swimlanes** at `parent=\"1\"`, stacked vertically. One row of nodes per lane.\n\n**Fixed values — do not compute or debate:**\n- Lane size: `x=0, y=lane_index*150, width=CANVAS_W, height=150`\n- Lane style: `swimlane;horizontal=0;startSize=110;fillColor=<pastel>;html=1;`\n- Child nodes inside a lane: `parent=\"<lane_id>\"`, `x = 120 + col*180`, `y = 45` (always 45), size 140×60 (or 140×80 for diamonds)\n- Cross-lane edges: `parent=\"1\"` (not inside a lane)\n\nPick `CANVAS_W = max_col * 180 + 300`. Choose lane colors from `#f5f5f5, #e8f4f8, #fff0e6, #e8f5e9, #fff9e6, #fce4ec` in that order.\n\n```xml\n<mxCell id=\"lane1\" value=\"Customer\" style=\"swimlane;horizontal=0;startSize=110;fillColor=#f5f5f5;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"0\" y=\"0\" width=\"1800\" height=\"150\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"n1\" value=\"Place Order\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"lane1\">\n  <mxGeometry x=\"120\" y=\"45\" width=\"140\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"lane2\" value=\"System\" style=\"swimlane;horizontal=0;startSize=110;fillColor=#e8f4f8;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"0\" y=\"150\" width=\"1800\" height=\"150\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"n2\" value=\"Validate\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"lane2\">\n  <mxGeometry x=\"300\" y=\"45\" width=\"140\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"e1\" edge=\"1\" parent=\"1\" source=\"n1\" target=\"n2\" style=\"edgeStyle=orthogonalEdgeStyle;rounded=1;html=1;\">\n  <mxGeometry relative=\"1\" as=\"geometry\"/>\n</mxCell>\n```\n\nDo NOT nest lanes inside a pool. Do NOT vary lane heights. Do NOT compute title-area offset — it is always 110, children start at x=120 to clear it.\n\n### Nested architecture containers (cloud, infra, network topologies)\n\nFor diagrams with **nested groupings** — VPC → Availability Zone → EC2 instance, Datacenter → Rack → Server, Region → Environment → Service — use nested swimlanes. This is where the AI most often flattens hierarchy that should be nested. Treat each level as a swimlane container.\n\n**Rules:**\n- Every container is a `swimlane` with `startSize=24` (title area at the top).\n- Child cells set `parent=\"<container_id>\"` and use coordinates **relative to their parent** (origin 0,0 is the parent's top-left, below the title).\n- **An edge belongs to the innermost container that holds BOTH of its endpoints.** Walk up from both ends until you reach a container that contains both: two cells in the same subnet → that subnet; a web tier and a database tier inside one region → that region; anything with one endpoint outside all containers → `parent=\"1\"`, the layer. This is the rule the draw.io editor's own model maintains, and auto-layout reads an edge's coordinates in its parent's frame, so an edge filed too far out lands in the wrong place.\n- For industry-specific icons (AWS/Azure/GCP logos, Cisco equipment, etc.), call `search_shapes` to get the exact `style` string and substitute it into a regular vertex — the container structure stays the same.\n\n```xml\n<mxCell id=\"vpc\" value=\"VPC\" style=\"swimlane;startSize=24;fillColor=#dae8fc;strokeColor=#6c8ebf;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"0\" y=\"0\" width=\"720\" height=\"360\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"az1\" value=\"AZ us-east-1a\" style=\"swimlane;startSize=24;fillColor=#fff2cc;strokeColor=#d6b656;html=1;\" vertex=\"1\" parent=\"vpc\">\n  <mxGeometry x=\"20\" y=\"36\" width=\"320\" height=\"300\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"web1\" value=\"web-1\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"az1\">\n  <mxGeometry x=\"30\" y=\"40\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"db1\" value=\"db-1\" style=\"shape=cylinder3;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"az1\">\n  <mxGeometry x=\"180\" y=\"40\" width=\"100\" height=\"70\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"az2\" value=\"AZ us-east-1b\" style=\"swimlane;startSize=24;fillColor=#fff2cc;strokeColor=#d6b656;html=1;\" vertex=\"1\" parent=\"vpc\">\n  <mxGeometry x=\"360\" y=\"36\" width=\"340\" height=\"300\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"web2\" value=\"web-2\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"az2\">\n  <mxGeometry x=\"30\" y=\"40\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"e1\" edge=\"1\" parent=\"1\" source=\"web1\" target=\"web2\" style=\"edgeStyle=orthogonalEdgeStyle;rounded=1;html=1;\">\n  <mxGeometry relative=\"1\" as=\"geometry\"/>\n</mxCell>\n```\n\n### Cross-functional flowcharts (actor × phase grid, as a table)\n\nCross-functional flowcharts show a process across **two axes at once** — actors (rows) and phases (columns). Use drawio's `table` shape, which auto-arranges cells into a grid via `childLayout=tableLayout`. This is the canonical draw.io pattern and is distinct from plain swimlanes (which only group on one axis).\n\n**Structure:**\n- Outer container: `shape=table;childLayout=tableLayout;startSize=0;collapsible=0;fillColor=none;`\n- Rows are children of the table: `shape=tableRow;horizontal=0;startSize=0;collapsible=0;`\n- Cells are children of rows — regular vertices, one per (actor, phase) intersection\n- Row heights and cell widths are set via `mxGeometry`; they tile automatically\n- First row = phase headers; first cell of every other row = actor label\n- Process nodes go INSIDE the appropriate cell (parent = cell id) at coordinates relative to the cell\n- Cross-cell edges must use `parent=\"1\"` (same rule as containers)\n\n```xml\n<mxCell id=\"tbl\" style=\"shape=table;childLayout=tableLayout;startSize=0;collapsible=0;fillColor=none;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"0\" y=\"0\" width=\"900\" height=\"320\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"r0\" style=\"shape=tableRow;horizontal=0;startSize=0;collapsible=0;\" vertex=\"1\" parent=\"tbl\">\n  <mxGeometry width=\"900\" height=\"40\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"h0\" style=\"text;html=1;\" vertex=\"1\" parent=\"r0\">\n  <mxGeometry width=\"140\" height=\"40\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"h1\" value=\"Order\" style=\"text;align=center;fontStyle=1;fillColor=#e8e8e8;\" vertex=\"1\" parent=\"r0\">\n  <mxGeometry x=\"140\" width=\"380\" height=\"40\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"h2\" value=\"Fulfill\" style=\"text;align=center;fontStyle=1;fillColor=#e8e8e8;\" vertex=\"1\" parent=\"r0\">\n  <mxGeometry x=\"520\" width=\"380\" height=\"40\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"r1\" style=\"shape=tableRow;horizontal=0;startSize=0;collapsible=0;\" vertex=\"1\" parent=\"tbl\">\n  <mxGeometry y=\"40\" width=\"900\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"a1\" value=\"Customer\" style=\"fillColor=#dae8fc;fontStyle=1;\" vertex=\"1\" parent=\"r1\">\n  <mxGeometry width=\"140\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"c_cust_order\" style=\"fillColor=none;\" vertex=\"1\" parent=\"r1\">\n  <mxGeometry x=\"140\" width=\"380\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"t_place\" value=\"Place Order\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"c_cust_order\">\n  <mxGeometry x=\"120\" y=\"40\" width=\"140\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"c_cust_fulfill\" style=\"fillColor=none;\" vertex=\"1\" parent=\"r1\">\n  <mxGeometry x=\"520\" width=\"380\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"r2\" style=\"shape=tableRow;horizontal=0;startSize=0;collapsible=0;\" vertex=\"1\" parent=\"tbl\">\n  <mxGeometry y=\"180\" width=\"900\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"a2\" value=\"System\" style=\"fillColor=#d5e8d4;fontStyle=1;\" vertex=\"1\" parent=\"r2\">\n  <mxGeometry width=\"140\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"c_sys_order\" style=\"fillColor=none;\" vertex=\"1\" parent=\"r2\">\n  <mxGeometry x=\"140\" width=\"380\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"t_validate\" value=\"Validate\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"c_sys_order\">\n  <mxGeometry x=\"120\" y=\"40\" width=\"140\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"c_sys_fulfill\" style=\"fillColor=none;\" vertex=\"1\" parent=\"r2\">\n  <mxGeometry x=\"520\" width=\"380\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"t_ship\" value=\"Ship\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"c_sys_fulfill\">\n  <mxGeometry x=\"120\" y=\"40\" width=\"140\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"e1\" edge=\"1\" parent=\"1\" source=\"t_place\" target=\"t_validate\" style=\"edgeStyle=orthogonalEdgeStyle;rounded=1;html=1;\">\n  <mxGeometry relative=\"1\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"e2\" edge=\"1\" parent=\"1\" source=\"t_validate\" target=\"t_ship\" style=\"edgeStyle=orthogonalEdgeStyle;rounded=1;html=1;\">\n  <mxGeometry relative=\"1\" as=\"geometry\"/>\n</mxCell>\n```\n\n**When to use cross-functional tables vs flat swimlanes:**\n- Flat swimlanes — one-dimensional (actors only, or phases only). Simpler. Use this when you just need to show who does what in sequence.\n- Cross-functional table — two-dimensional (actors AND phases). Use this when **both** the actor and the process stage matter, and every step belongs to a specific (actor, phase) cell.\n\n**Do NOT** nest swimlanes inside a table row, do NOT set `startSize` on rows or cells (columns tile from `x=0`), and do NOT rely on the AI to produce exact widths that sum to the table width — close-enough totals are fine, the `tableLayout` normalizes them.\n\n## Layers\n\nLayers control visibility and z-order. Every cell belongs to exactly one layer. Use layers to manage diagram complexity — viewers can toggle layer visibility to show or hide groups of elements (e.g., \"Physical Infrastructure\" vs \"Logical Network\" vs \"Security Zones\").\n\nCell `id=\"0\"` is the root and cell `id=\"1\"` is the default layer — both always exist. Additional layers are `mxCell` elements with `parent=\"0\"`:\n\n```xml\n<mxGraphModel>\n  <root>\n    <mxCell id=\"0\"/>\n    <mxCell id=\"1\" parent=\"0\"/>\n    <mxCell id=\"2\" value=\"Annotations\" parent=\"0\"/>\n    <mxCell id=\"10\" value=\"Server\" style=\"rounded=1;html=1;\" vertex=\"1\" parent=\"1\">\n      <mxGeometry x=\"100\" y=\"100\" width=\"120\" height=\"60\" as=\"geometry\"/>\n    </mxCell>\n    <mxCell id=\"20\" value=\"Note: deprecated\" style=\"text;\" vertex=\"1\" parent=\"2\">\n      <mxGeometry x=\"100\" y=\"170\" width=\"120\" height=\"30\" as=\"geometry\"/>\n    </mxCell>\n  </root>\n</mxGraphModel>\n```\n\n- A layer is an `mxCell` with `parent=\"0\"` and no `vertex` or `edge` attribute\n- Assign shapes to a layer by setting `parent` to the layer's id\n- Later layers render on top of earlier layers (higher z-order)\n- Add `visible=\"0\"` as an attribute on the layer cell to hide it by default\n- Use layers when the diagram has distinct conceptual groupings that viewers may want to toggle independently\n\n## Tags\n\nTags are visual filters that let viewers show or hide elements by category. Unlike layers, a single element can have multiple tags, making tags ideal for cross-cutting concerns (e.g., tagging shapes as \"critical\", \"v2\", or \"backend\").\n\nTags require wrapping `mxCell` in an `<object>` element. Tags are assigned via the `tags` attribute as a space-separated string:\n\n```xml\n<mxGraphModel>\n  <root>\n    <mxCell id=\"0\"/>\n    <mxCell id=\"1\" parent=\"0\"/>\n    <object id=\"2\" label=\"Auth Service\" tags=\"critical v2\">\n      <mxCell style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"1\">\n        <mxGeometry x=\"100\" y=\"100\" width=\"120\" height=\"60\" as=\"geometry\"/>\n      </mxCell>\n    </object>\n    <object id=\"3\" label=\"Legacy API\" tags=\"critical deprecated\">\n      <mxCell style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"1\">\n        <mxGeometry x=\"300\" y=\"100\" width=\"120\" height=\"60\" as=\"geometry\"/>\n      </mxCell>\n    </object>\n  </root>\n</mxGraphModel>\n```\n\n- Tags require the `<object>` wrapper — a plain `mxCell` cannot have tags\n- The `label` attribute on `<object>` replaces `value` on `mxCell`\n- Tags are space-separated in the `tags` attribute\n- Viewers filter the diagram by selecting tags in the draw.io UI (Edit > Tags)\n- Tags do not affect z-order or structural grouping — they are purely a visibility filter\n\n## Metadata and placeholders\n\nMetadata stores custom key-value properties on shapes as additional attributes on the `<object>` wrapper element. Combined with placeholders, metadata values can be displayed in labels — useful for data-driven diagrams showing status, owner, IP addresses, or versions on each shape.\n\nSet `placeholders=\"1\"` on the `<object>` to enable `%propertyName%` substitution in the `label`:\n\n```xml\n<mxGraphModel>\n  <root>\n    <mxCell id=\"0\"/>\n    <mxCell id=\"1\" parent=\"0\"/>\n    <object id=\"2\" label=\"&lt;b&gt;%component%&lt;/b&gt;&lt;br&gt;Owner: %owner%&lt;br&gt;Status: %status%\"\n            placeholders=\"1\" component=\"Auth Service\" owner=\"Team Backend\" status=\"Active\">\n      <mxCell style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"1\">\n        <mxGeometry x=\"100\" y=\"100\" width=\"160\" height=\"80\" as=\"geometry\"/>\n      </mxCell>\n    </object>\n  </root>\n</mxGraphModel>\n```\n\n- Custom properties are plain XML attributes on `<object>` (e.g., `component=\"Auth Service\"`)\n- Set `placeholders=\"1\"` to enable `%key%` substitution in the label and tooltip\n- The label must use `html=1` style when using HTML formatting with placeholders\n- Placeholders resolve by walking up the containment hierarchy: shape attributes first, then parent container, then layer, then root — first match wins\n- Predefined placeholders work without custom properties: `%id%`, `%width%`, `%height%`, `%date%`, `%time%`, `%timestamp%`, `%page%`, `%pagenumber%`, `%pagecount%`, `%filename%`\n- Use `%%` for a literal percent sign in labels\n- Tags, metadata, and placeholders can all be combined on the same `<object>` element\n- Use metadata when shapes represent data records (servers, services, components) and you want to attach structured information beyond the visible label\n\n## Dark mode colors\n\ndraw.io supports automatic dark mode rendering. How colors behave depends on the property:\n\n- **`strokeColor`, `fillColor`, `fontColor`** default to `\"default\"`, which renders as black in light theme and white in dark theme. When no explicit color is set, colors adapt automatically.\n- **Explicit colors** (e.g. `fillColor=#DAE8FC`) specify the light-mode color. The dark-mode color is computed automatically by inverting the RGB values (blending toward the inverse at 93%) and rotating the hue by 180° (via `mxUtils.getInverseColor`).\n- **`light-dark()` function** — To specify both colors explicitly, use `light-dark(lightColor,darkColor)` in the style string, e.g. `fontColor=light-dark(#7EA6E0,#FF0000)`. The first argument is used in light mode, the second in dark mode.\n\nTo enable dark mode color adaptation, the `mxGraphModel` element must include `adaptiveColors=\"auto\"`.\n\nWhen generating diagrams, you generally do not need to specify dark-mode colors — the automatic inversion handles most cases. Use `light-dark()` only when the automatic inverse color is unsatisfactory.\n\n## Edge routing & layout passes\n\nBy default, edges are drawn by draw.io's **built-in router**, which is intentionally basic: each edge is a straight line or a simple right-angle path between its endpoints, with **no obstacle avoidance** — a connector runs straight through any shape lying between its `source` and `target`. Two **opt-in** passes upgrade this. Set them as fields on the same call that carries the diagram; the result you open, export or copy always reflects the finished pass.\n\n- **`routing: \"libavoid\"`** (XML only) — obstacle-avoiding orthogonal **edge routing**. Vertices stay exactly where you placed them; only the connectors are recomputed, so they run in clean right-angle segments that route *around* the boxes (and spread apart when parallel) instead of cutting across them. Use it for diagrams you laid out deliberately — architecture, network topology, deployment, swimlanes, UML, floor plans — where you want tidy wires without disturbing your layout.\n- **`postLayout: \"elk\"`** — a **full re-layout** (ELK `layered` flow). Vertices move from your positions to canonical hierarchical ones, and the edges are routed as part of that. Node sizes are kept exactly as you declare them, so a label still has to fit the box you gave it. Best for flowcharts, process/state diagrams, decision flows, pipelines, and other directional/hierarchical diagrams. (You should rarely hand-write these as XML — prefer Mermaid.) Flow **direction**: on XML set the optional `direction` field (`\"vertical\"` (default) / `\"horizontal\"`); on Mermaid it is read from the flowchart code (`flowchart TD/TB` vs `LR/RL`) and `direction` is ignored.\n\nThe four combinations:\n\n| `postLayout` | `routing` | Result |\n|---|---|---|\n| — | — | basic built-in router (straight / simple right-angle, no obstacle avoidance); your positions kept |\n| — | `libavoid` | your positions kept; wires re-routed orthogonally *around* the shapes |\n| `elk` | — | ELK places the vertices **and** routes the edges (decent routing built in) |\n| `elk` | `libavoid` | rarely worth it — ELK already routes; only add `libavoid` if ELK's routing specifically comes out poor |\n\n**Pick ONE — they are essentially alternatives, not a stack:**\n- **Neither** — fine when connected nodes sit in clear rows/columns with open space between them, so the basic router's straight/right-angle lines won't cross another shape. Simplest and lightest; do this by default for sparse layouts.\n- **`routing: \"libavoid\"`** — keep your hand-placed layout but clean up the wires: use whenever an edge would otherwise cut across a box, or you want consistently clean orthogonal wires routed around shapes (architecture, network topology, deployment, UML, floor plans — anything densely connected).\n- **`postLayout: \"elk\"`** — when you want a canonical re-layout (vertices moved). ELK routes the edges itself as part of the layout, so **do not also set `routing`** — the combination is redundant in almost all cases. Add `direction: \"horizontal\"` for left-to-right flow.\n\n**When you are passing Mermaid instead of XML: see the `postLayout` parameter description for when to set it.** Complex Mermaid flowcharts (≥ ~20 nodes, ≥ 3 decision diamonds, feedback edges, or ≥ 3 endpoints) need `postLayout: \"elk\"` because the native parser's layout goes cramped or unbalanced past that threshold — the direction follows the flowchart code, so no `direction` is needed. Simple flowcharts and all non-flowchart Mermaid types (sequence, class, ER, sankey, …) need no `postLayout`.\n\n**When NOT to use (XML):**\n- The user has asked for specific positions (swim lanes with exact lanes, architecture diagrams with meaningful spatial arrangement).\n- The diagram relies on containers/grouping where spatial layout encodes information.\n\n## Style reference\n\nComplete style reference (all shape types, style properties, color palettes, HTML labels, and more): https://github.com/jgraph/drawio-mcp/blob/main/shared/style-reference.md\n\nXML Schema (XSD): https://github.com/jgraph/drawio-mcp/blob/main/shared/mxfile.xsd\n\n## CRITICAL: XML well-formedness\n\nWhen generating draw.io XML, the output **must** be well-formed XML:\n- **NEVER include ANY XML comments (`<!-- -->`) in the output.** XML comments are strictly forbidden — they waste tokens, can cause parse errors, and serve no purpose in diagram XML.\n- Escape special characters in attribute values: `&amp;`, `&lt;`, `&gt;`, `&quot;`\n- Always use unique `id` values for each `mxCell`\n",
+   "description": "Opens the draw.io editor with a diagram from draw.io XML. Use it for custom styling, precise positioning and stencil-based diagrams (cloud, network, P&ID, UI mockups, floor plans); prefer open_drawio_mermaid for flowcharts, sequence, class, ER and the other types Mermaid covers.\n\nXML rules:\n- Skeleton: <mxGraphModel adaptiveColors=\"auto\"><root><mxCell id=\"0\"/><mxCell id=\"1\" parent=\"0\"/>…</root></mxGraphModel>. Unique ids. No XML comments.\n- Vertex: <mxCell id=\"a\" value=\"Label\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"1\"><mxGeometry x=\"40\" y=\"40\" width=\"140\" height=\"60\" as=\"geometry\"/></mxCell>\n- Edge: <mxCell id=\"e1\" style=\"edgeStyle=orthogonalEdgeStyle;rounded=1;html=1;\" edge=\"1\" source=\"a\" target=\"b\" parent=\"1\"><mxGeometry relative=\"1\" as=\"geometry\"/></mxCell>. Never self-closing. No waypoints or exitX/entryX.\n- Labels: html=1 in every style; escape HTML in values (&lt;b&gt;Name&lt;/b&gt;&lt;br&gt;detail); line break &lt;br&gt;, never \\n.\n- Shapes: rhombus (decision), ellipse, shape=cylinder3 (database), text.\n- Grid, no layout math: x=col*180+40, y=row*120+40, one node per cell; 140×60 boxes, 140×80 diamonds.\n- Containers: swimlane;startSize=24; (titled) or group; (invisible); children set parent=\"<id>\" with coordinates relative to it. An edge's parent is the innermost container holding both its ends, else \"1\".\n- Lanes: swimlane;horizontal=0;startSize=110; at x=0, y=lane*150, height 150; nodes inside at x=120+col*180, y=45.\n- Edges: orthogonal; entityRelationEdgeStyle for ER; labels 1-3 words; dashed=1 for one meaning, with a legend.\n- Cloud/network/P&ID icons or logos: call search_shapes, use its style.\n- Set postLayout \"elk\" for flowcharts, process and tree diagrams (ELK places nodes and routes edges), or routing \"libavoid\" for hand-placed layouts whose edges would cross shapes. Never both.\n\nOnly when the diagram needs layers, tags, metadata and placeholders, tables, cross-functional grids or dark-mode colors, call get_drawio_reference with format \"xml\" for the full reference.",
    "inputSchema": {
      "properties": {
        "content": {

Changed 2026-10-05 14:51 UTC

2 descriptions rewritten.

--- pinned/open_drawio_mermaid
+++ observed/open_drawio_mermaid
  {
-   "description": "Opens the draw.io editor with a diagram generated from Mermaid.js syntax. Supports flowcharts, sequence diagrams, class diagrams, state diagrams, entity relationship diagrams, and more using Mermaid.js syntax.\n\n# Mermaid Reference\n\nShort hints for generating Mermaid diagrams that render correctly in draw.io. draw.io's Mermaid parser covers 28 diagram types — the header keyword on the first non-directive line selects the type.\n\n_Canonical list & dialog/ELK docs: <https://github.com/jgraph/drawio/discussions/5643>._\n\n## General rules\n\n- **Pick the type keyword carefully.** `graph`/`flowchart`, `classDiagram`, `stateDiagram-v2`, `erDiagram`, `sequenceDiagram`, `gitGraph`, `journey`, `pie`, `gantt`, `mindmap`, `timeline`, `quadrantChart`, `requirementDiagram`, `sankey-beta`, `xychart-beta`, `block-beta`, `c4Context`/`C4Container`/`C4Component`, `architecture-beta`, `radar-beta`, `packet-beta`, `venn-beta`, `treemap-beta`, `treeView-beta`, `ishikawa-beta`, `kanban`, `zenuml`, `wardley-beta`, `eventmodeling`. Misspelling the header yields a blank diagram.\n- **No trailing punctuation on node IDs.** IDs are identifiers (`myNode`, `node_1`, `A`) — spaces, hyphens (in some contexts), and reserved words (`end`, `class`, `subgraph`) break the parse. Put display text in brackets or quotes instead: `A[\"User's Account\"]`.\n- **One statement per line.** Separate statements with newlines; `;` works as a delimiter in flowchart but not everywhere.\n- **Quote labels with special characters** (`:`, `-`, parentheses, non-ASCII). Use `\"` not `'`.\n- **HTML in labels:** only `<br>`, `<b>`, `<i>`, `<u>` are reliable across types. Use `#` for hex colors in styles, never `rgb()`.\n- **Diagrams can take a title block** for some types:\n  ```\n  ---\n  title: My Diagram\n  ---\n  flowchart TD\n  ```\n- **Match the language of labels to the user's language** — if the user writes in German, French, etc., the diagram labels should be in that language too.\n\n## Flowchart (most common)\n\n```\nflowchart TD\n  A[Start] --> B{Decision?}\n  B -->|Yes| C[Do thing]\n  B -->|No| D[Skip]\n  C --> E((End))\n  D --> E\n```\n\n- **Direction:** `TD`/`TB` (top-down), `BT`, `LR`, `RL`.\n- **Node shapes by bracket:** `[rect]`, `(rounded)`, `([stadium])`, `[[subroutine]]`, `[(cylinder)]`, `((circle))`, `{rhombus}`, `{{hexagon}}`, `[/parallelogram/]`, `[\\parallelogram alt\\]`, `[/trapezoid\\]`, `>asymmetric]`.\n- **Edges:** `-->` arrow, `---` no arrow, `-.->` dotted, `==>` thick, `<-->` bidirectional. Inline label: `A -- text --> B` or `A -->|text| B`.\n- **Subgraphs:**\n  ```\n  subgraph Frontend\n    A --> B\n  end\n  ```\n\n### Styling & colors\n\nThree ways — pick one, don't mix for the same node:\n\n**1. Inline per-node (`style`):**\n```\nflowchart LR\n  A[Start] --> B[End]\n  style A fill:#f9f,stroke:#333,stroke-width:2px,color:#fff\n  style B fill:#bbf,stroke:#f66,stroke-dasharray:5 5\n```\n\n**2. Reusable classes (`classDef` + `:::`):**\n```\nflowchart LR\n  A:::happy --> B:::sad\n  classDef happy fill:#dfd,stroke:#0a0\n  classDef sad fill:#fdd,stroke:#a00\n```\nOr apply to many: `class A,B,C happy`.\n\n**3. Link styling (edges):**\n```\nlinkStyle 0 stroke:#f00,stroke-width:3px\nlinkStyle default stroke:#999\n```\n`0` = first edge in order defined; `default` targets unstyled edges.\n\nStyle properties that work: `fill`, `stroke`, `stroke-width`, `stroke-dasharray`, `color` (font color).\n\n## Sequence diagram\n\n```\nsequenceDiagram\n  participant U as User\n  participant S as Server\n  U->>S: Request\n  S-->>U: Response\n  Note right of S: Logged\n```\n\n- **Arrows:** `->` (no head), `->>` (arrow), `-->>` (dashed), `-x` (X end), `--x` (dashed X).\n- **Activate/deactivate:** `activate S` / `deactivate S` or `S->>+S2: call` / `S2-->>-S: return`.\n- **Blocks:** `alt/else/end`, `opt/end`, `loop/end`, `par/and/end`, `critical/option/end`.\n- **Notes:** `Note left of A`, `Note over A,B: text`.\n- Optional `autonumber` after header numbers the messages.\n\n## Class diagram\n\n```\nclassDiagram\n  class Animal {\n    +String name\n    +int age\n    +eat() void\n  }\n  class Dog\n  Animal <|-- Dog : inherits\n  Dog \"1\" --> \"*\" Bone : has\n```\n\n- **Relations:** `<|--` inherit, `*--` composition, `o--` aggregation, `-->` association, `..>` dependency, `..|>` realize, `<-->` bidirectional.\n- **Visibility:** `+` public, `-` private, `#` protected, `~` package.\n- **Annotations:** `<<interface>>`, `<<abstract>>`, `<<enumeration>>` inside the class block or via `Animal <<interface>>`.\n- **Cardinality:** quoted strings flanking the arrow (`\"1\"`, `\"0..*\"`, `\"*\"`).\n\n## State diagram\n\n```\nstateDiagram-v2\n  [*] --> Idle\n  Idle --> Running : start\n  Running --> Idle : stop\n  Running --> [*]\n  state Running {\n    [*] --> Working\n    Working --> Waiting : block\n    Waiting --> Working : unblock\n  }\n```\n\n- Use `stateDiagram-v2`, not `stateDiagram` (v1 is legacy).\n- `[*]` = start (source) or end (target) depending on direction.\n- `state X { ... }` nests a compound state; `state fork1 <<fork>>`, `<<join>>`, `<<choice>>` mark junction nodes.\n- Transition labels: `A --> B : event [guard] / action`.\n\n## ER diagram\n\n```\nerDiagram\n  CUSTOMER ||--o{ ORDER : places\n  ORDER ||--|{ LINE-ITEM : contains\n  CUSTOMER {\n    string name\n    string email PK\n  }\n```\n\n- **Cardinality symbols:** `|o` zero-or-one, `||` exactly-one, `}o` zero-or-many, `}|` one-or-many. Mirror on both sides (e.g., `||--o{`).\n- Attribute blocks list `type name [PK|FK|UK]` plus optional comment in quotes.\n- Entity names are typically UPPERCASE by convention.\n\n## Journey\n\n```\njourney\n  title Morning routine\n  section Wake up\n    Coffee: 5: Me\n    Read news: 3: Me\n  section Commute\n    Drive: 2: Me, Traffic\n```\n\nEach task: `Name: score(1-5): Actor[, Actor...]`. Section headers group tasks.\n\n## Pie\n\n```\npie showData title Browser share\n  \"Chrome\" : 60\n  \"Firefox\" : 20\n  \"Safari\" : 20\n```\n\n`showData` is optional (renders the numbers). Quotes on labels, colon, numeric value.\n\n## Gantt\n\n```\ngantt\n  title Project timeline\n  dateFormat YYYY-MM-DD\n  section Phase 1\n  Design : a1, 2025-01-01, 7d\n  Build  : after a1, 14d\n  section Phase 2\n  Test   : 2025-01-25, 5d\n```\n\n- `dateFormat` is mandatory.\n- Task line: `Name : [id,] [after id | YYYY-MM-DD], duration[d/w]`.\n- Status tags: `done`, `active`, `crit` before the id (`crit a1`).\n\n## Gitgraph\n\n```\ngitGraph\n  commit\n  branch develop\n  checkout develop\n  commit\n  commit\n  checkout main\n  merge develop\n```\n\nCommands: `commit [id: \"x\"] [tag: \"v1\"]`, `branch name`, `checkout name`, `merge name`, `cherry-pick id: \"x\"`.\n\n## Mindmap\n\n```\nmindmap\n  root((Project))\n    Frontend\n      React\n      CSS\n    Backend\n      Node\n      DB\n```\n\n- Indentation (2-space increments) defines hierarchy.\n- Root shape: `((circle))`, `[rect]`, `(rounded)`, `))cloud((`, `)hexagon(`, `{{hexagon}}`.\n- No edges — they are implied by nesting.\n\n## Timeline\n\n```\ntimeline\n  title Company history\n  section 2020s\n    2021 : Founded\n    2022 : Series A\n         : Launched product\n  section 2030s\n    2030 : IPO\n```\n\nColon separates year/label; multiple `:` lines under one year add sub-events.\n\n## Quadrant chart\n\n```\nquadrantChart\n  title Reach vs Engagement\n  x-axis Low --> High\n  y-axis Low --> High\n  quadrant-1 Stars\n  quadrant-2 Question Marks\n  quadrant-3 Dogs\n  quadrant-4 Cash Cows\n  Campaign A: [0.3, 0.6]\n  Campaign B: [0.75, 0.85]\n```\n\nPoint coords are `[0..1, 0..1]`.\n\n## Requirement diagram\n\n```\nrequirementDiagram\n  requirement req1 {\n    id: \"1\"\n    text: \"The system shall...\"\n    risk: high\n    verifymethod: test\n  }\n  element user_story {\n    type: \"story\"\n  }\n  user_story - satisfies -> req1\n```\n\nRequirement types: `requirement`, `functionalRequirement`, `performanceRequirement`, `interfaceRequirement`, `physicalRequirement`, `designConstraint`. Relations: `contains`, `copies`, `derives`, `satisfies`, `verifies`, `refines`, `traces`.\n\n## Sankey\n\n```\nsankey-beta\nSource,Intermediate,10\nSource,Direct,5\nIntermediate,Sink,10\n```\n\nCSV-style: `source,target,value`. No header. No `title` (use frontmatter).\n\n## XY chart\n\n```\nxychart-beta\n  title \"Revenue\"\n  x-axis [jan, feb, mar, apr]\n  y-axis \"USD\" 0 --> 10000\n  bar [2500, 5000, 7500, 9000]\n  line [3000, 4500, 6500, 8500]\n```\n\n`bar [...]` and `line [...]` can stack; order matters (later overlays earlier).\n\n## Block\n\n```\nblock-beta\n  columns 3\n  A B C\n  D[\"Wide\"]:2 E\n  A --> D\n```\n\n`columns N` sets grid width. `Name:N` spans N columns. Edges use flowchart arrow syntax.\n\n## C4\n\n```\nC4Context\n  Person(user, \"User\")\n  System(app, \"App\", \"Does things\")\n  Rel(user, app, \"Uses\")\n```\n\n- Variants: `C4Context`, `C4Container`, `C4Component`, `C4Dynamic`, `C4Deployment`.\n- Element helpers: `Person`, `System`, `System_Ext`, `Container`, `ComponentDb`, `Boundary(id, \"label\", \"type\")`, etc. Arguments are positional: `(id, label, [type/tech], [description])`.\n- `UpdateElementStyle(tag, $bgColor=\"#…\")` and `AddElementTag` tweak appearance.\n\n## Architecture\n\n```\narchitecture-beta\n  group cloud(cloud)[Cloud]\n  service api(server)[API] in cloud\n  service db(database)[DB] in cloud\n  api:R --> L:db\n```\n\n- Built-in icons: `cloud`, `server`, `database`, `disk`, `internet`. Suffix edge ends with `:T`, `:B`, `:L`, `:R` to pick the side.\n- `group id(icon)[Label]` then `in groupId` on services places nodes.\n\n## Radar\n\n```\nradar-beta\n  title Skills\n  axis js[\"JS\"], py[\"Python\"], go[\"Go\"]\n  curve alice[\"Alice\"]{80, 60, 70}\n  curve bob[\"Bob\"]{50, 90, 65}\n```\n\nAxes and curves are positionally aligned — list values in axis order, 0–100.\n\n## Packet\n\n```\npacket-beta\n  0-15: \"Source Port\"\n  16-31: \"Dest Port\"\n  32-63: \"Seq Number\"\n```\n\n`start-end` (bit ranges) or single-bit `N`. Use a title frontmatter.\n\n## Venn\n\n```\nvenn-beta\n  set A [\"Set A\"]\n  set B [\"Set B\"]\n  union A,B\n  text A [\"only A\"]\n  text A,B [\"shared\"]\n```\n\nDefine every `union` combination whose region you plan to label. `text A,B [...]` places text in intersections.\n\n## Treemap\n\n```\ntreemap-beta\n\"Category\"\n    \"Leaf 1\": 40\n    \"Leaf 2\": 60\n```\n\nNumbers are values (area-weighted). Indent (2+ spaces) for hierarchy.\n\n## Tree view\n\n```\ntreeView-beta\n  \"Root\"\n    \"Child 1\"\n      \"Grandchild\"\n    \"Child 2\"\n```\n\nPure indentation hierarchy, no numbers.\n\n## Ishikawa (fishbone)\n\n```\nishikawa-beta\n  Main Problem\n    Category\n      Cause\n      Sub-cause\n    Another Category\n      Cause\n```\n\nFirst line after header is the problem; top-level indents are categories (Materials, Methods, Machinery, etc. — use whatever makes sense).\n\n## Kanban\n\n```\nkanban\n  todo[To Do]\n    task1[Write spec]@{ assigned: \"Alice\", priority: \"High\" }\n  doing[In progress]\n    task2[Build feature]\n  done[Done]\n```\n\nColumns are `id[Label]` at indent 0; cards are `id[Label]@{ metadata }` inside. Metadata keys: `assigned`, `priority` (`Very Low`/`Low`/`Medium`/`High`/`Very High`), `ticket`.\n\n## ZenUML\n\n```\nzenuml\n  @Actor User\n  @Boundary Web\n  @Control Service\n  User -> Web: request\n  Web -> Service: process()\n  Service -> Web: result\n```\n\nParticipant roles: `@Actor`, `@Boundary`, `@Control`, `@Entity`, `@Database`. Messages use `->` with a colon-separated label. Supports `if/else`, `while`, `par` blocks like sequence diagrams.\n\n## Wardley map\n\n```\nwardley-beta\n  title Tea Shop\n  anchor Business [0.95, 0.63]\n  component Cup of Tea [0.79, 0.61]\n  component Kettle [0.43, 0.35] (inertia)\n  Business -> Cup of Tea\n  Cup of Tea -> Kettle\n  evolve Kettle 0.62\n```\n\n- Header `wardley` or `wardley-beta`; `title` optional.\n- `anchor`/`component Name [visibility, evolution]` — coords are `[0..1, 0..1]` (y = value-chain visibility, x = evolution from Genesis to Commodity).\n- Component evolution markers in parens: `(inertia)`, `(build)`, `(buy)`, `(outsource)`, `(market)`.\n- Links: `A -> B` dependency, `A +> B` flow. `evolve Name <x>` adds an evolution target; `evolution Genesis -> Custom -> Product -> Commodity` relabels the x-axis stages.\n- Extras: `note \"text\" [x,y]`, `annotation N,[x,y] \"text\"`, `accelerator`/`deaccelerator \"text\" [x,y]`.\n\n## Event Modeling\n\n```\neventmodeling\n  tf 01 ui CartUI\n  tf 02 cmd AddItem\n  tf 03 evt ItemAdded\n  tf 04 rmo Cart\n```\n\n- Each `tf <id> <type> <Name>` is a time-frame (column). Types: `ui` / `pcr` (processor), `cmd` / `command`, `rmo` / `readmodel`, `evt` / `event` — placed on the UI/Automation, Command/Read-Model, and Events swimlanes.\n- Wire frames with `->>`: `tf 04 evt ItemChanged ->> 02 ->> 03` links frame 04 back to 02 and 03.\n- `Namespace.Name` groups frames into slices (e.g. `Order.ChangeOrder`).\n- `data <id> { ... }` blocks attach payloads, referenced inline with `[[id]]`: `tf 02 cmd AddItem [[AddItem01]]`.\n\n## When to prefer XML over Mermaid\n\n- Precise positions / custom coordinates.\n- draw.io-native shapes (AWS, Azure, GCP, P&ID, Cisco, electrical).\n- Mixed shape libraries or complex multi-layer diagrams.\n- Anything that needs exact colors per element with many variations — Mermaid's styling works but at scale XML is easier to reason about.\n\nDefault to Mermaid for the standard types above; reach for XML only when Mermaid's syntax clearly can't express what's needed.\n",
+   "description": "Opens the draw.io editor with a diagram generated from Mermaid.js syntax. Supports flowcharts, sequence diagrams, class diagrams, state diagrams, entity relationship diagrams, and more using Mermaid.js syntax.\n\n# Mermaid Reference\n\nShort hints for generating Mermaid diagrams that render correctly in draw.io. draw.io's Mermaid parser covers 28 diagram types — the header keyword on the first non-directive line selects the type.\n\n_Canonical list & dialog/ELK docs: <https://github.com/jgraph/drawio/discussions/5643>._\n\n## General rules\n\n- **Pick the type keyword carefully.** `graph`/`flowchart`, `classDiagram`, `stateDiagram-v2`, `erDiagram`, `sequenceDiagram`, `gitGraph`, `journey`, `pie`, `gantt`, `mindmap`, `timeline`, `quadrantChart`, `requirementDiagram`, `sankey-beta`, `xychart-beta`, `block-beta`, `c4Context`/`C4Container`/`C4Component`, `architecture-beta`, `radar-beta`, `packet-beta`, `venn-beta`, `treemap-beta`, `treeView-beta`, `ishikawa-beta`, `kanban`, `zenuml`, `wardley-beta`, `eventmodeling`. Misspelling the header yields a blank diagram.\n- **No trailing punctuation on node IDs.** IDs are identifiers (`myNode`, `node_1`, `A`) — spaces, hyphens (in some contexts), and reserved words (`end`, `class`, `subgraph`) break the parse. Put display text in brackets or quotes instead: `A[\"User's Account\"]`.\n- **One statement per line.** Separate statements with newlines; `;` works as a delimiter in flowchart but not everywhere.\n- **Quote labels with special characters** (`:`, `-`, parentheses, non-ASCII). Use `\"` not `'`.\n- **HTML in labels:** only `<br>`, `<b>`, `<i>`, `<u>` are reliable across types. Use `#` for hex colors in styles, never `rgb()`.\n- **Diagrams can take a title block** for some types:\n  ```\n  ---\n  title: My Diagram\n  ---\n  flowchart TD\n  ```\n- **Match the language of labels to the user's language** — if the user writes in German, French, etc., the diagram labels should be in that language too.\n\n## Flowchart (most common)\n\n```\nflowchart TD\n  A[Start] --> B{Decision?}\n  B -->|Yes| C[Do thing]\n  B -->|No| D[Skip]\n  C --> E((End))\n  D --> E\n```\n\n- **Direction:** `TD`/`TB` (top-down), `BT`, `LR`, `RL`.\n- **Node shapes by bracket:** `[rect]`, `(rounded)`, `([stadium])`, `[[subroutine]]`, `[(cylinder)]`, `((circle))`, `{rhombus}`, `{{hexagon}}`, `[/parallelogram/]`, `[\\parallelogram alt\\]`, `[/trapezoid\\]`, `>asymmetric]`.\n- **Edges:** `-->` arrow, `---` no arrow, `-.->` dotted, `==>` thick, `<-->` bidirectional. Inline label: `A -- text --> B` or `A -->|text| B`.\n- **Subgraphs:**\n  ```\n  subgraph Frontend\n    A --> B\n  end\n  ```\n\n### Layout for complex flowcharts\n\ndraw.io's Mermaid parser lays flowcharts out itself, but the result gets cramped or unbalanced once the diagram has any structural complexity. Switch that flowchart to the **ELK layered layout** (the same engine as draw.io's *Arrange ▸ Layout ▸ Vertical/Horizontal Flow*) when ANY of these holds:\n\n- ≥ ~20 nodes, OR\n- ≥ 3 decision diamonds (`{...}`), OR\n- any feedback/back-edge (an edge pointing back to an earlier node — an error path looping to a retry), OR\n- ≥ 3 distinct endpoints.\n\nTwo ways to ask for it, depending on the tool:\n\n- **A `postLayout: \"elk\"` field** on the call, if the tool offers one — use it.\n- **Otherwise select it in the source**, as a YAML frontmatter block at the very top. draw.io honors it wherever it converts Mermaid (editor, opened link, desktop CLI):\n  ```\n  ---\n  config:\n    layout: elk\n  ---\n  flowchart TD\n    A[Start] --> B{Retry?}\n  ```\n  Combines with a `title:` — both are keys of the same frontmatter block.\n\nThe flow direction always follows the flowchart code (`TD`/`TB` vs `LR`/`RL`). **Flowcharts only** — sequence, class, ER, gantt and the rest lay themselves out and ignore the setting. Simple flowcharts (linear chains, < 20 nodes, no branching or back-edges) don't need it either.\n\n### Styling & colors\n\nThree ways — pick one, don't mix for the same node:\n\n**1. Inline per-node (`style`):**\n```\nflowchart LR\n  A[Start] --> B[End]\n  style A fill:#f9f,stroke:#333,stroke-width:2px,color:#fff\n  style B fill:#bbf,stroke:#f66,stroke-dasharray:5 5\n```\n\n**2. Reusable classes (`classDef` + `:::`):**\n```\nflowchart LR\n  A:::happy --> B:::sad\n  classDef happy fill:#dfd,stroke:#0a0\n  classDef sad fill:#fdd,stroke:#a00\n```\nOr apply to many: `class A,B,C happy`.\n\n**3. Link styling (edges):**\n```\nlinkStyle 0 stroke:#f00,stroke-width:3px\nlinkStyle default stroke:#999\n```\n`0` = first edge in order defined; `default` targets unstyled edges.\n\nStyle properties that work: `fill`, `stroke`, `stroke-width`, `stroke-dasharray`, `color` (font color).\n\n## Sequence diagram\n\n```\nsequenceDiagram\n  participant U as User\n  participant S as Server\n  U->>S: Request\n  S-->>U: Response\n  Note right of S: Logged\n```\n\n- **Arrows:** `->` (no head), `->>` (arrow), `-->>` (dashed), `-x` (X end), `--x` (dashed X).\n- **Activate/deactivate:** `activate S` / `deactivate S` or `S->>+S2: call` / `S2-->>-S: return`.\n- **Blocks:** `alt/else/end`, `opt/end`, `loop/end`, `par/and/end`, `critical/option/end`.\n- **Notes:** `Note left of A`, `Note over A,B: text`.\n- Optional `autonumber` after header numbers the messages.\n\n## Class diagram\n\n```\nclassDiagram\n  class Animal {\n    +String name\n    +int age\n    +eat() void\n  }\n  class Dog\n  Animal <|-- Dog : inherits\n  Dog \"1\" --> \"*\" Bone : has\n```\n\n- **Relations:** `<|--` inherit, `*--` composition, `o--` aggregation, `-->` association, `..>` dependency, `..|>` realize, `<-->` bidirectional.\n- **Visibility:** `+` public, `-` private, `#` protected, `~` package.\n- **Annotations:** `<<interface>>`, `<<abstract>>`, `<<enumeration>>` inside the class block or via `Animal <<interface>>`.\n- **Cardinality:** quoted strings flanking the arrow (`\"1\"`, `\"0..*\"`, `\"*\"`).\n\n## State diagram\n\n```\nstateDiagram-v2\n  [*] --> Idle\n  Idle --> Running : start\n  Running --> Idle : stop\n  Running --> [*]\n  state Running {\n    [*] --> Working\n    Working --> Waiting : block\n    Waiting --> Working : unblock\n  }\n```\n\n- Use `stateDiagram-v2`, not `stateDiagram` (v1 is legacy).\n- `[*]` = start (source) or end (target) depending on direction.\n- `state X { ... }` nests a compound state; `state fork1 <<fork>>`, `<<join>>`, `<<choice>>` mark junction nodes.\n- Transition labels: `A --> B : event [guard] / action`.\n\n## ER diagram\n\n```\nerDiagram\n  CUSTOMER ||--o{ ORDER : places\n  ORDER ||--|{ LINE-ITEM : contains\n  CUSTOMER {\n    string name\n    string email PK\n  }\n```\n\n- **Cardinality symbols:** `|o` zero-or-one, `||` exactly-one, `}o` zero-or-many, `}|` one-or-many. Mirror on both sides (e.g., `||--o{`).\n- Attribute blocks list `type name [PK|FK|UK]` plus optional comment in quotes.\n- Entity names are typically UPPERCASE by convention.\n\n## Journey\n\n```\njourney\n  title Morning routine\n  section Wake up\n    Coffee: 5: Me\n    Read news: 3: Me\n  section Commute\n    Drive: 2: Me, Traffic\n```\n\nEach task: `Name: score(1-5): Actor[, Actor...]`. Section headers group tasks.\n\n## Pie\n\n```\npie showData title Browser share\n  \"Chrome\" : 60\n  \"Firefox\" : 20\n  \"Safari\" : 20\n```\n\n`showData` is optional (renders the numbers). Quotes on labels, colon, numeric value.\n\n## Gantt\n\n```\ngantt\n  title Project timeline\n  dateFormat YYYY-MM-DD\n  section Phase 1\n  Design : a1, 2025-01-01, 7d\n  Build  : after a1, 14d\n  section Phase 2\n  Test   : 2025-01-25, 5d\n```\n\n- `dateFormat` is mandatory.\n- Task line: `Name : [id,] [after id | YYYY-MM-DD], duration[d/w]`.\n- Status tags: `done`, `active`, `crit` before the id (`crit a1`).\n\n## Gitgraph\n\n```\ngitGraph\n  commit\n  branch develop\n  checkout develop\n  commit\n  commit\n  checkout main\n  merge develop\n```\n\nCommands: `commit [id: \"x\"] [tag: \"v1\"]`, `branch name`, `checkout name`, `merge name`, `cherry-pick id: \"x\"`.\n\n## Mindmap\n\n```\nmindmap\n  root((Project))\n    Frontend\n      React\n      CSS\n    Backend\n      Node\n      DB\n```\n\n- Indentation (2-space increments) defines hierarchy.\n- Root shape: `((circle))`, `[rect]`, `(rounded)`, `))cloud((`, `)hexagon(`, `{{hexagon}}`.\n- No edges — they are implied by nesting.\n\n## Timeline\n\n```\ntimeline\n  title Company history\n  section 2020s\n    2021 : Founded\n    2022 : Series A\n         : Launched product\n  section 2030s\n    2030 : IPO\n```\n\nColon separates year/label; multiple `:` lines under one year add sub-events.\n\n## Quadrant chart\n\n```\nquadrantChart\n  title Reach vs Engagement\n  x-axis Low --> High\n  y-axis Low --> High\n  quadrant-1 Stars\n  quadrant-2 Question Marks\n  quadrant-3 Dogs\n  quadrant-4 Cash Cows\n  Campaign A: [0.3, 0.6]\n  Campaign B: [0.75, 0.85]\n```\n\nPoint coords are `[0..1, 0..1]`.\n\n## Requirement diagram\n\n```\nrequirementDiagram\n  requirement req1 {\n    id: \"1\"\n    text: \"The system shall...\"\n    risk: high\n    verifymethod: test\n  }\n  element user_story {\n    type: \"story\"\n  }\n  user_story - satisfies -> req1\n```\n\nRequirement types: `requirement`, `functionalRequirement`, `performanceRequirement`, `interfaceRequirement`, `physicalRequirement`, `designConstraint`. Relations: `contains`, `copies`, `derives`, `satisfies`, `verifies`, `refines`, `traces`.\n\n## Sankey\n\n```\nsankey-beta\nSource,Intermediate,10\nSource,Direct,5\nIntermediate,Sink,10\n```\n\nCSV-style: `source,target,value`. No header. No `title` (use frontmatter).\n\n## XY chart\n\n```\nxychart-beta\n  title \"Revenue\"\n  x-axis [jan, feb, mar, apr]\n  y-axis \"USD\" 0 --> 10000\n  bar [2500, 5000, 7500, 9000]\n  line [3000, 4500, 6500, 8500]\n```\n\n`bar [...]` and `line [...]` can stack; order matters (later overlays earlier).\n\n## Block\n\n```\nblock-beta\n  columns 3\n  A B C\n  D[\"Wide\"]:2 E\n  A --> D\n```\n\n`columns N` sets grid width. `Name:N` spans N columns. Edges use flowchart arrow syntax.\n\n## C4\n\n```\nC4Context\n  Person(user, \"User\")\n  System(app, \"App\", \"Does things\")\n  Rel(user, app, \"Uses\")\n```\n\n- Variants: `C4Context`, `C4Container`, `C4Component`, `C4Dynamic`, `C4Deployment`.\n- Element helpers: `Person`, `System`, `System_Ext`, `Container`, `ComponentDb`, `Boundary(id, \"label\", \"type\")`, etc. Arguments are positional: `(id, label, [type/tech], [description])`.\n- `UpdateElementStyle(tag, $bgColor=\"#…\")` and `AddElementTag` tweak appearance.\n\n## Architecture\n\n```\narchitecture-beta\n  group cloud(cloud)[Cloud]\n  service api(server)[API] in cloud\n  service db(database)[DB] in cloud\n  api:R --> L:db\n```\n\n- Built-in icons: `cloud`, `server`, `database`, `disk`, `internet`. Suffix edge ends with `:T`, `:B`, `:L`, `:R` to pick the side.\n- `group id(icon)[Label]` then `in groupId` on services places nodes.\n\n## Radar\n\n```\nradar-beta\n  title Skills\n  axis js[\"JS\"], py[\"Python\"], go[\"Go\"]\n  curve alice[\"Alice\"]{80, 60, 70}\n  curve bob[\"Bob\"]{50, 90, 65}\n```\n\nAxes and curves are positionally aligned — list values in axis order, 0–100.\n\n## Packet\n\n```\npacket-beta\n  0-15: \"Source Port\"\n  16-31: \"Dest Port\"\n  32-63: \"Seq Number\"\n```\n\n`start-end` (bit ranges) or single-bit `N`. Use a title frontmatter.\n\n## Venn\n\n```\nvenn-beta\n  set A [\"Set A\"]\n  set B [\"Set B\"]\n  union A,B\n  text A [\"only A\"]\n  text A,B [\"shared\"]\n```\n\nDefine every `union` combination whose region you plan to label. `text A,B [...]` places text in intersections.\n\n## Treemap\n\n```\ntreemap-beta\n\"Category\"\n    \"Leaf 1\": 40\n    \"Leaf 2\": 60\n```\n\nNumbers are values (area-weighted). Indent (2+ spaces) for hierarchy.\n\n## Tree view\n\n```\ntreeView-beta\n  \"Root\"\n    \"Child 1\"\n      \"Grandchild\"\n    \"Child 2\"\n```\n\nPure indentation hierarchy, no numbers.\n\n## Ishikawa (fishbone)\n\n```\nishikawa-beta\n  Main Problem\n    Category\n      Cause\n      Sub-cause\n    Another Category\n      Cause\n```\n\nFirst line after header is the problem; top-level indents are categories (Materials, Methods, Machinery, etc. — use whatever makes sense).\n\n## Kanban\n\n```\nkanban\n  todo[To Do]\n    task1[Write spec]@{ assigned: \"Alice\", priority: \"High\" }\n  doing[In progress]\n    task2[Build feature]\n  done[Done]\n```\n\nColumns are `id[Label]` at indent 0; cards are `id[Label]@{ metadata }` inside. Metadata keys: `assigned`, `priority` (`Very Low`/`Low`/`Medium`/`High`/`Very High`), `ticket`.\n\n## ZenUML\n\n```\nzenuml\n  @Actor User\n  @Boundary Web\n  @Control Service\n  User -> Web: request\n  Web -> Service: process()\n  Service -> Web: result\n```\n\nParticipant roles: `@Actor`, `@Boundary`, `@Control`, `@Entity`, `@Database`. Messages use `->` with a colon-separated label. Supports `if/else`, `while`, `par` blocks like sequence diagrams.\n\n## Wardley map\n\n```\nwardley-beta\n  title Tea Shop\n  anchor Business [0.95, 0.63]\n  component Cup of Tea [0.79, 0.61]\n  component Kettle [0.43, 0.35] (inertia)\n  Business -> Cup of Tea\n  Cup of Tea -> Kettle\n  evolve Kettle 0.62\n```\n\n- Header `wardley` or `wardley-beta`; `title` optional.\n- `anchor`/`component Name [visibility, evolution]` — coords are `[0..1, 0..1]` (y = value-chain visibility, x = evolution from Genesis to Commodity).\n- Component evolution markers in parens: `(inertia)`, `(build)`, `(buy)`, `(outsource)`, `(market)`.\n- Links: `A -> B` dependency, `A +> B` flow. `evolve Name <x>` adds an evolution target; `evolution Genesis -> Custom -> Product -> Commodity` relabels the x-axis stages.\n- Extras: `note \"text\" [x,y]`, `annotation N,[x,y] \"text\"`, `accelerator`/`deaccelerator \"text\" [x,y]`.\n\n## Event Modeling\n\n```\neventmodeling\n  tf 01 ui CartUI\n  tf 02 cmd AddItem\n  tf 03 evt ItemAdded\n  tf 04 rmo Cart\n```\n\n- Each `tf <id> <type> <Name>` is a time-frame (column). Types: `ui` / `pcr` (processor), `cmd` / `command`, `rmo` / `readmodel`, `evt` / `event` — placed on the UI/Automation, Command/Read-Model, and Events swimlanes.\n- Wire frames with `->>`: `tf 04 evt ItemChanged ->> 02 ->> 03` links frame 04 back to 02 and 03.\n- `Namespace.Name` groups frames into slices (e.g. `Order.ChangeOrder`).\n- `data <id> { ... }` blocks attach payloads, referenced inline with `[[id]]`: `tf 02 cmd AddItem [[AddItem01]]`.\n\n## When to prefer XML over Mermaid\n\n- Precise positions / custom coordinates.\n- draw.io-native shapes (AWS, Azure, GCP, P&ID, Cisco, electrical).\n- Mixed shape libraries or complex multi-layer diagrams.\n- Anything that needs exact colors per element with many variations — Mermaid's styling works but at scale XML is easier to reason about.\n\nDefault to Mermaid for the standard types above; reach for XML only when Mermaid's syntax clearly can't express what's needed.\n",
    "inputSchema": {
      "properties": {
        "content": {
+       },
+       "postLayout": {
+         "description": "Optional 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.",
+         "enum": [
+           "elk"
+         ],
+         "type": "string"
        }
      },
      "required": [

--- pinned/open_drawio_xml
+++ observed/open_drawio_xml
  {
-   "description": "Opens the draw.io editor with a diagram from XML content. Use this to view, edit, or create diagrams in draw.io format. The XML should be valid draw.io/mxGraph XML format.\n\n# draw.io XML Reference\n\nDetailed reference for styles, edge routing, containers, layers, tags, metadata, and dark mode. Consult this when generating draw.io XML diagrams.\n\n## Reasoning budget (read this first)\n\nYour 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.\n\n**Do NOT** in your reasoning:\n\n- 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.\n- 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.\n- 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.\n- Do NOT re-derive drawio mechanics (`horizontal=0`, `startSize=110`, nested-lane coordinates). Use the templates below as-is.\n- Do NOT enumerate columns (\"customer lane columns 0-10, web app 1-7\"). Place a node, move on.\n- Do NOT add `<Array as=\"points\">` waypoints. Edges are routed automatically.\n- Do NOT set `exitX` / `exitY` / `entryX` / `entryY` connection-point overrides unless you have specific geometric intent.\n- Do NOT verify, re-check, or adjust coordinates after placing a node.\n- Do NOT narrate \"building the diagram / finalizing the XML / now let me…\". Just emit XML.\n- Do NOT write out lists of node positions as planning text. Emit them as `<mxCell>` elements directly.\n\n**Do** in your reasoning:\n\n- Identify the diagram type + actors/stages (1-2 short sentences).\n- Identify any grouping (swimlanes? containers? none?).\n- Go straight to XML.\n\n**Rigid grid — use for every XML diagram:**\n\n- Column x = `col_index * 180 + 40`  (col 0 = 40, col 1 = 220, col 2 = 400, …)\n- Row y = `row_index * 120 + 40`     (row 0 = 40, row 1 = 160, row 2 = 280, …)\n- Node size: rectangles `140×60`, diamonds `140×80`, circles `60×60`, documents `120×80`, cylinders `100×70`\n\nPick a `(col, row)` for each node. Don't think about centers, gaps, or overlap — ELK handles routing between rough positions. Slight misalignment is invisible in the result.\n\n## General principles\n\n- **Use proper draw.io shapes and connectors** — choose the semantically correct shape for each element (e.g., `shape=cylinder3` for databases and tanks, `rhombus` for decisions, `shape=mxgraph.pid2valves.*` for valves in P&IDs). draw.io has extensive shape libraries; prefer domain-appropriate shapes over generic rectangles.\n- **Decide whether to search for shapes** — before generating a diagram, decide if it needs domain-specific shapes from draw.io's extended libraries. **Skip `search_shapes`** for standard diagram types that use basic geometric shapes: flowcharts, UML (class, sequence, state, activity), ERD, org charts, mind maps, Venn diagrams, timelines, wireframes, and any diagram using only rectangles, diamonds, circles, cylinders, and arrows. Also skip if the user explicitly asks to use basic/simple shapes or says not to search. **Use `search_shapes`** when the diagram requires industry-specific or branded icons: cloud architecture (AWS, Azure, GCP), network topology (Cisco, rack equipment), P&ID (valves, instruments, vessels), electrical/circuit diagrams, Kubernetes, BPMN with specific task types, or any domain where the user expects realistic/standardized symbols rather than labeled boxes. It also finds brand/product logos and general-purpose pictorial icons (e.g. `react`, `slack`, `shopping cart`, `solar panel`) — returned as ready-to-use `shape=image` styles — so use it too when the user asks for logos or everyday concept icons.\n- **Match the language of labels to the user's language** — if the user writes in German, French, Japanese, etc., all diagram labels, titles, and annotations should be in that same language.\n- **Group related nodes, and surface a hub when edges converge** — put nodes that belong together inside a container or swimlane, and keep external actors (users, files, third-party systems) outside implementation containers. When many edges converge on one area or cross several groups, route them through a single hub/gateway node (a registry, broker, event log, …) instead of drawing every low-level dependency across the canvas — fewer crossings, clearer contract.\n- **Encode secondary detail in node text, not edges** — draw an edge only when the relationship itself carries meaning; push incidental detail into the node label so the connector layer stays readable.\n\n## Common styles\n\n**Rounded rectangle:**\n```xml\n<mxCell id=\"2\" value=\"Label\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"100\" y=\"100\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n```\n\n**Diamond (decision):**\n```xml\n<mxCell id=\"3\" value=\"Condition?\" style=\"rhombus;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"100\" y=\"200\" width=\"120\" height=\"80\" as=\"geometry\"/>\n</mxCell>\n```\n\n**Arrow (edge):**\n```xml\n<mxCell id=\"4\" value=\"\" style=\"edgeStyle=orthogonalEdgeStyle;html=1;\" edge=\"1\" source=\"2\" target=\"3\" parent=\"1\">\n  <mxGeometry relative=\"1\" as=\"geometry\"/>\n</mxCell>\n```\n\n**Labeled arrow:**\n```xml\n<mxCell id=\"5\" value=\"Yes\" style=\"edgeStyle=orthogonalEdgeStyle;html=1;\" edge=\"1\" source=\"3\" target=\"6\" parent=\"1\">\n  <mxGeometry relative=\"1\" as=\"geometry\"/>\n</mxCell>\n```\n\n## Style properties\n\n| Property | Values | Use for |\n|----------|--------|---------|\n| `rounded=1` | 0 or 1 | Rounded corners |\n| `whiteSpace=wrap` | wrap | Text wrapping |\n| `fillColor=#dae8fc` | Hex color | Background color |\n| `strokeColor=#6c8ebf` | Hex color | Border color |\n| `fontColor=#333333` | Hex color | Text color |\n| `shape=cylinder3` | shape name | Database cylinders |\n| `shape=mxgraph.flowchart.document` | shape name | Document shapes |\n| `ellipse` | style keyword | Circles/ovals |\n| `rhombus` | style keyword | Diamonds |\n| `edgeStyle=orthogonalEdgeStyle` | style keyword | Right-angle connectors |\n| `edgeStyle=elbowEdgeStyle` | style keyword | Elbow connectors |\n| `dashed=1` | 0 or 1 | Dashed lines |\n| `swimlane` | style keyword | Swimlane containers |\n| `group` | style keyword | Invisible container (pointerEvents=0) |\n| `container=1` | 0 or 1 | Enable container behavior on any shape |\n| `pointerEvents=0` | 0 or 1 | Prevent container from capturing child connections |\n| `html=1` | 0 or 1 | Enable HTML rendering in labels (required for `<b>`, `<br>`, `<font>`, etc.) |\n| `shape=umlLifeline;perimeter=lifelinePerimeter;size=16` | shape | UML sequence diagram lifeline (size = header height) |\n\n## HTML labels\n\n**Always include `html=1` in the style** when the `value` attribute contains any HTML tags (`<b>`, `<br>`, `<font>`, `<i>`, `<u>`, `<hr>`, `<p>`, `<table>`, etc.). Without `html=1`, HTML tags are displayed as literal text instead of being rendered.\n\nHTML in attribute values must be **XML-escaped**: `<` → `&lt;`, `>` → `&gt;`, `&` → `&amp;`, `\"` → `&quot;`\n\n```xml\n<mxCell value=\"&lt;b&gt;Title&lt;/b&gt;&lt;br&gt;Description\"\n        style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"100\" y=\"100\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n```\n\n**Line breaks:** Use `&#xa;` (works with both `html=1` and `html=0`) or `&lt;br&gt;` (requires `html=1`) for line breaks — never use `\\n`, which renders as literal backslash-n text instead of a newline.\n\n**Best practice:** Always include `html=1` in every cell style. This ensures labels render correctly whether they contain HTML or plain text — plain text is unaffected by the flag.\n\n**Bold/italic/underline:** Use `fontStyle` in the style string when the entire label should be bold (`fontStyle=1`), italic (`fontStyle=2`), or underline (`fontStyle=4`). Values can be combined via bitwise OR (e.g., `fontStyle=3` = bold+italic). Use HTML tags (`<b>`, `<i>`, `<u>`) only when formatting part of the label (e.g., bold title with normal description). Never combine `fontStyle` with HTML tags for the same effect — this is redundant and causes visible raw tags if `html=1` is missing.\n\n## Edges\n\n**CRITICAL: Every edge `mxCell` must contain a `<mxGeometry relative=\"1\" as=\"geometry\" />` child element.** Self-closing edge cells (e.g. `<mxCell ... edge=\"1\" ... />`) are invalid and will not render correctly. Always use the expanded form:\n```xml\n<mxCell id=\"e1\" edge=\"1\" parent=\"1\" source=\"a\" target=\"b\" style=\"...\">\n  <mxGeometry relative=\"1\" as=\"geometry\" />\n</mxCell>\n```\n\n**Don't hand-route edges.** Just declare `source` and `target`. You do **not** need to:\n- Add `<mxPoint>` waypoints\n- Set `exitX` / `exitY` / `entryX` / `entryY`\n- Route around obstacles\n- Worry about edge-vertex collisions or parallel edge spacing\n\ndraw.io's built-in router is **basic**: it draws each edge as a straight line or a simple right-angle path between `source` and `target`, with **no awareness of other shapes** — a wire will run straight across any box that sits between its endpoints. That's fine when connected nodes have open space between them. When edges would otherwise cross over shapes, or you want consistently clean orthogonal wires that route *around* the boxes, set **`routing: \"libavoid\"`** on `create_diagram`; for a full re-layout use **`postLayout: \"elk\"`** (see **Edge routing & layout passes** below). Both compute the waypoints for you — you never add them by hand either way.\n\n**What you still choose: the edge style.** The style determines the overall look (orthogonal angles, curves, straight lines) — the router honors the style family.\n\n| Style | Syntax | Best for |\n|-------|--------|---------|\n| **Orthogonal** | `edgeStyle=orthogonalEdgeStyle` | Flowcharts, architecture, network diagrams, BPMN — any diagram with right-angle connectors |\n| **Straight** | no `edgeStyle` | UML class/sequence diagrams, direct point-to-point connections. For sequence diagram messages use `endSize=6;startSize=6;` to keep arrowheads small |\n| **Entity Relation** | `edgeStyle=entityRelationEdgeStyle` | ER diagrams — creates perpendicular stubs at both ends |\n| **Curved** | `curved=1` | Mind maps, informal diagrams |\n| **Elbow** | `edgeStyle=elbowEdgeStyle;elbow=vertical;` | Rarely needed — `orthogonalEdgeStyle` handles almost all cases; use this only for simple 1-bend linear flows |\n\n**Use a consistent edge style within each diagram.** Pick one based on diagram type and apply it to all edges: ER → `entityRelationEdgeStyle`; UML class → straight; mind maps → curved; flowcharts/architecture/network → `orthogonalEdgeStyle`.\n\n**Useful edge style attributes** that apply regardless of routing:\n- `rounded=1` — rounded corners at bend points (recommended for orthogonal)\n- `endArrow=classic` / `endArrow=none` — arrow heads\n- `dashed=1` — dashed line\n- `strokeColor=#...`, `strokeWidth=2` — color/width\n- Edge labels: set `value` directly on the edge cell\n\n**Keep edge labels short and meaningful** — one to three words (`Yes`, `async`, `reads`). Drop labels that merely restate an obvious action (`call`, `register`); move longer explanations into node text or a small legend node.\n\n**Visual semantics — stay consistent, add a legend when mixing styles.** Within one diagram apply `dashed=1`, `strokeColor`, and `strokeWidth` consistently for one chosen meaning (e.g. dashed = optional / async / inferred relationship). Don't mix several dashed meanings without a small legend explaining them.\n\n## Containers and groups\n\nFor architecture diagrams or any diagram with nested elements, use draw.io's proper parent-child containment — do **not** just place shapes on top of larger shapes.\n\n### How containment works\n\nSet `parent=\"containerId\"` on child cells. Children use **relative coordinates** within the container.\n\n### Container types\n\n| Type | Style | When to use |\n|------|-------|-------------|\n| **Group** (invisible) | `group;` | No visual border needed, container has no connections. Includes `pointerEvents=0` so child connections are not captured |\n| **Swimlane** (titled) | `swimlane;startSize=30;` | Container needs a visible title bar/header, or the container itself has connections |\n| **Custom container** | Add `container=1;pointerEvents=0;` to any shape style | Any shape acting as a container without its own connections |\n\n### Key rules\n\n- **Edges to children inside containers naturally cross the container boundary** — this is correct and expected. Do not add extra waypoints or complex routing to avoid a parent container when connecting to shapes inside it.\n- **Always add `pointerEvents=0;`** to container styles that should not capture connections being rewired between children\n- Only omit `pointerEvents=0` when the container itself needs to be connectable — in that case, use `swimlane` style which handles this correctly (the client area is transparent for mouse events while the header remains connectable)\n- Children must set `parent=\"containerId\"` and use coordinates **relative to the container**\n\n### Example: Architecture container with swimlane\n\n```xml\n<mxCell id=\"svc1\" value=\"User Service\" style=\"swimlane;startSize=30;fillColor=#dae8fc;strokeColor=#6c8ebf;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"100\" y=\"100\" width=\"300\" height=\"200\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"api1\" value=\"REST API\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"svc1\">\n  <mxGeometry x=\"20\" y=\"40\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"db1\" value=\"Database\" style=\"shape=cylinder3;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"svc1\">\n  <mxGeometry x=\"160\" y=\"40\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n```\n\n### Example: Invisible group container\n\n```xml\n<mxCell id=\"grp1\" value=\"\" style=\"group;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"100\" y=\"100\" width=\"300\" height=\"200\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"c1\" value=\"Component A\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"grp1\">\n  <mxGeometry x=\"10\" y=\"10\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n```\n\n### Swimlanes for grouped actors (BPMN-style flowcharts)\n\nUse **flat swimlanes** at `parent=\"1\"`, stacked vertically. One row of nodes per lane.\n\n**Fixed values — do not compute or debate:**\n- Lane size: `x=0, y=lane_index*150, width=CANVAS_W, height=150`\n- Lane style: `swimlane;horizontal=0;startSize=110;fillColor=<pastel>;html=1;`\n- Child nodes inside a lane: `parent=\"<lane_id>\"`, `x = 120 + col*180`, `y = 45` (always 45), size 140×60 (or 140×80 for diamonds)\n- Cross-lane edges: `parent=\"1\"` (not inside a lane)\n\nPick `CANVAS_W = max_col * 180 + 300`. Choose lane colors from `#f5f5f5, #e8f4f8, #fff0e6, #e8f5e9, #fff9e6, #fce4ec` in that order.\n\n```xml\n<mxCell id=\"lane1\" value=\"Customer\" style=\"swimlane;horizontal=0;startSize=110;fillColor=#f5f5f5;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"0\" y=\"0\" width=\"1800\" height=\"150\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"n1\" value=\"Place Order\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"lane1\">\n  <mxGeometry x=\"120\" y=\"45\" width=\"140\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"lane2\" value=\"System\" style=\"swimlane;horizontal=0;startSize=110;fillColor=#e8f4f8;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"0\" y=\"150\" width=\"1800\" height=\"150\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"n2\" value=\"Validate\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"lane2\">\n  <mxGeometry x=\"300\" y=\"45\" width=\"140\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"e1\" edge=\"1\" parent=\"1\" source=\"n1\" target=\"n2\" style=\"edgeStyle=orthogonalEdgeStyle;rounded=1;html=1;\">\n  <mxGeometry relative=\"1\" as=\"geometry\"/>\n</mxCell>\n```\n\nDo NOT nest lanes inside a pool. Do NOT vary lane heights. Do NOT compute title-area offset — it is always 110, children start at x=120 to clear it.\n\n### Nested architecture containers (cloud, infra, network topologies)\n\nFor diagrams with **nested groupings** — VPC → Availability Zone → EC2 instance, Datacenter → Rack → Server, Region → Environment → Service — use nested swimlanes. This is where the AI most often flattens hierarchy that should be nested. Treat each level as a swimlane container.\n\n**Rules:**\n- Every container is a `swimlane` with `startSize=24` (title area at the top).\n- Child cells set `parent=\"<container_id>\"` and use coordinates **relative to their parent** (origin 0,0 is the parent's top-left, below the title).\n- Edges between cells in **different** containers must have `parent=\"1\"` (not a container) — otherwise they render inside the container and get clipped.\n- For industry-specific icons (AWS/Azure/GCP logos, Cisco equipment, etc.), call `search_shapes` to get the exact `style` string and substitute it into a regular vertex — the container structure stays the same.\n\n```xml\n<mxCell id=\"vpc\" value=\"VPC\" style=\"swimlane;startSize=24;fillColor=#dae8fc;strokeColor=#6c8ebf;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"0\" y=\"0\" width=\"720\" height=\"360\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"az1\" value=\"AZ us-east-1a\" style=\"swimlane;startSize=24;fillColor=#fff2cc;strokeColor=#d6b656;html=1;\" vertex=\"1\" parent=\"vpc\">\n  <mxGeometry x=\"20\" y=\"36\" width=\"320\" height=\"300\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"web1\" value=\"web-1\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"az1\">\n  <mxGeometry x=\"30\" y=\"40\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"db1\" value=\"db-1\" style=\"shape=cylinder3;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"az1\">\n  <mxGeometry x=\"180\" y=\"40\" width=\"100\" height=\"70\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"az2\" value=\"AZ us-east-1b\" style=\"swimlane;startSize=24;fillColor=#fff2cc;strokeColor=#d6b656;html=1;\" vertex=\"1\" parent=\"vpc\">\n  <mxGeometry x=\"360\" y=\"36\" width=\"340\" height=\"300\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"web2\" value=\"web-2\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"az2\">\n  <mxGeometry x=\"30\" y=\"40\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"e1\" edge=\"1\" parent=\"1\" source=\"web1\" target=\"web2\" style=\"edgeStyle=orthogonalEdgeStyle;rounded=1;html=1;\">\n  <mxGeometry relative=\"1\" as=\"geometry\"/>\n</mxCell>\n```\n\n### Cross-functional flowcharts (actor × phase grid, as a table)\n\nCross-functional flowcharts show a process across **two axes at once** — actors (rows) and phases (columns). Use drawio's `table` shape, which auto-arranges cells into a grid via `childLayout=tableLayout`. This is the canonical draw.io pattern and is distinct from plain swimlanes (which only group on one axis).\n\n**Structure:**\n- Outer container: `shape=table;childLayout=tableLayout;startSize=0;collapsible=0;fillColor=none;`\n- Rows are children of the table: `shape=tableRow;horizontal=0;startSize=0;collapsible=0;`\n- Cells are children of rows — regular vertices, one per (actor, phase) intersection\n- Row heights and cell widths are set via `mxGeometry`; they tile automatically\n- First row = phase headers; first cell of every other row = actor label\n- Process nodes go INSIDE the appropriate cell (parent = cell id) at coordinates relative to the cell\n- Cross-cell edges must use `parent=\"1\"` (same rule as containers)\n\n```xml\n<mxCell id=\"tbl\" style=\"shape=table;childLayout=tableLayout;startSize=0;collapsible=0;fillColor=none;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"0\" y=\"0\" width=\"900\" height=\"320\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"r0\" style=\"shape=tableRow;horizontal=0;startSize=0;collapsible=0;\" vertex=\"1\" parent=\"tbl\">\n  <mxGeometry width=\"900\" height=\"40\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"h0\" style=\"text;html=1;\" vertex=\"1\" parent=\"r0\">\n  <mxGeometry width=\"140\" height=\"40\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"h1\" value=\"Order\" style=\"text;align=center;fontStyle=1;fillColor=#e8e8e8;\" vertex=\"1\" parent=\"r0\">\n  <mxGeometry x=\"140\" width=\"380\" height=\"40\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"h2\" value=\"Fulfill\" style=\"text;align=center;fontStyle=1;fillColor=#e8e8e8;\" vertex=\"1\" parent=\"r0\">\n  <mxGeometry x=\"520\" width=\"380\" height=\"40\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"r1\" style=\"shape=tableRow;horizontal=0;startSize=0;collapsible=0;\" vertex=\"1\" parent=\"tbl\">\n  <mxGeometry y=\"40\" width=\"900\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"a1\" value=\"Customer\" style=\"fillColor=#dae8fc;fontStyle=1;\" vertex=\"1\" parent=\"r1\">\n  <mxGeometry width=\"140\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"c_cust_order\" style=\"fillColor=none;\" vertex=\"1\" parent=\"r1\">\n  <mxGeometry x=\"140\" width=\"380\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"t_place\" value=\"Place Order\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"c_cust_order\">\n  <mxGeometry x=\"120\" y=\"40\" width=\"140\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"c_cust_fulfill\" style=\"fillColor=none;\" vertex=\"1\" parent=\"r1\">\n  <mxGeometry x=\"520\" width=\"380\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"r2\" style=\"shape=tableRow;horizontal=0;startSize=0;collapsible=0;\" vertex=\"1\" parent=\"tbl\">\n  <mxGeometry y=\"180\" width=\"900\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"a2\" value=\"System\" style=\"fillColor=#d5e8d4;fontStyle=1;\" vertex=\"1\" parent=\"r2\">\n  <mxGeometry width=\"140\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"c_sys_order\" style=\"fillColor=none;\" vertex=\"1\" parent=\"r2\">\n  <mxGeometry x=\"140\" width=\"380\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"t_validate\" value=\"Validate\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"c_sys_order\">\n  <mxGeometry x=\"120\" y=\"40\" width=\"140\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"c_sys_fulfill\" style=\"fillColor=none;\" vertex=\"1\" parent=\"r2\">\n  <mxGeometry x=\"520\" width=\"380\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"t_ship\" value=\"Ship\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"c_sys_fulfill\">\n  <mxGeometry x=\"120\" y=\"40\" width=\"140\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"e1\" edge=\"1\" parent=\"1\" source=\"t_place\" target=\"t_validate\" style=\"edgeStyle=orthogonalEdgeStyle;rounded=1;html=1;\">\n  <mxGeometry relative=\"1\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"e2\" edge=\"1\" parent=\"1\" source=\"t_validate\" target=\"t_ship\" style=\"edgeStyle=orthogonalEdgeStyle;rounded=1;html=1;\">\n  <mxGeometry relative=\"1\" as=\"geometry\"/>\n</mxCell>\n```\n\n**When to use cross-functional tables vs flat swimlanes:**\n- Flat swimlanes — one-dimensional (actors only, or phases only). Simpler. Use this when you just need to show who does what in sequence.\n- Cross-functional table — two-dimensional (actors AND phases). Use this when **both** the actor and the process stage matter, and every step belongs to a specific (actor, phase) cell.\n\n**Do NOT** nest swimlanes inside a table row, do NOT set `startSize` on rows or cells (columns tile from `x=0`), and do NOT rely on the AI to produce exact widths that sum to the table width — close-enough totals are fine, the `tableLayout` normalizes them.\n\n## Layers\n\nLayers control visibility and z-order. Every cell belongs to exactly one layer. Use layers to manage diagram complexity — viewers can toggle layer visibility to show or hide groups of elements (e.g., \"Physical Infrastructure\" vs \"Logical Network\" vs \"Security Zones\").\n\nCell `id=\"0\"` is the root and cell `id=\"1\"` is the default layer — both always exist. Additional layers are `mxCell` elements with `parent=\"0\"`:\n\n```xml\n<mxGraphModel>\n  <root>\n    <mxCell id=\"0\"/>\n    <mxCell id=\"1\" parent=\"0\"/>\n    <mxCell id=\"2\" value=\"Annotations\" parent=\"0\"/>\n    <mxCell id=\"10\" value=\"Server\" style=\"rounded=1;html=1;\" vertex=\"1\" parent=\"1\">\n      <mxGeometry x=\"100\" y=\"100\" width=\"120\" height=\"60\" as=\"geometry\"/>\n    </mxCell>\n    <mxCell id=\"20\" value=\"Note: deprecated\" style=\"text;\" vertex=\"1\" parent=\"2\">\n      <mxGeometry x=\"100\" y=\"170\" width=\"120\" height=\"30\" as=\"geometry\"/>\n    </mxCell>\n  </root>\n</mxGraphModel>\n```\n\n- A layer is an `mxCell` with `parent=\"0\"` and no `vertex` or `edge` attribute\n- Assign shapes to a layer by setting `parent` to the layer's id\n- Later layers render on top of earlier layers (higher z-order)\n- Add `visible=\"0\"` as an attribute on the layer cell to hide it by default\n- Use layers when the diagram has distinct conceptual groupings that viewers may want to toggle independently\n\n## Tags\n\nTags are visual filters that let viewers show or hide elements by category. Unlike layers, a single element can have multiple tags, making tags ideal for cross-cutting concerns (e.g., tagging shapes as \"critical\", \"v2\", or \"backend\").\n\nTags require wrapping `mxCell` in an `<object>` element. Tags are assigned via the `tags` attribute as a space-separated string:\n\n```xml\n<mxGraphModel>\n  <root>\n    <mxCell id=\"0\"/>\n    <mxCell id=\"1\" parent=\"0\"/>\n    <object id=\"2\" label=\"Auth Service\" tags=\"critical v2\">\n      <mxCell style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"1\">\n        <mxGeometry x=\"100\" y=\"100\" width=\"120\" height=\"60\" as=\"geometry\"/>\n      </mxCell>\n    </object>\n    <object id=\"3\" label=\"Legacy API\" tags=\"critical deprecated\">\n      <mxCell style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"1\">\n        <mxGeometry x=\"300\" y=\"100\" width=\"120\" height=\"60\" as=\"geometry\"/>\n      </mxCell>\n    </object>\n  </root>\n</mxGraphModel>\n```\n\n- Tags require the `<object>` wrapper — a plain `mxCell` cannot have tags\n- The `label` attribute on `<object>` replaces `value` on `mxCell`\n- Tags are space-separated in the `tags` attribute\n- Viewers filter the diagram by selecting tags in the draw.io UI (Edit > Tags)\n- Tags do not affect z-order or structural grouping — they are purely a visibility filter\n\n## Metadata and placeholders\n\nMetadata stores custom key-value properties on shapes as additional attributes on the `<object>` wrapper element. Combined with placeholders, metadata values can be displayed in labels — useful for data-driven diagrams showing status, owner, IP addresses, or versions on each shape.\n\nSet `placeholders=\"1\"` on the `<object>` to enable `%propertyName%` substitution in the `label`:\n\n```xml\n<mxGraphModel>\n  <root>\n    <mxCell id=\"0\"/>\n    <mxCell id=\"1\" parent=\"0\"/>\n    <object id=\"2\" label=\"&lt;b&gt;%component%&lt;/b&gt;&lt;br&gt;Owner: %owner%&lt;br&gt;Status: %status%\"\n            placeholders=\"1\" component=\"Auth Service\" owner=\"Team Backend\" status=\"Active\">\n      <mxCell style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"1\">\n        <mxGeometry x=\"100\" y=\"100\" width=\"160\" height=\"80\" as=\"geometry\"/>\n      </mxCell>\n    </object>\n  </root>\n</mxGraphModel>\n```\n\n- Custom properties are plain XML attributes on `<object>` (e.g., `component=\"Auth Service\"`)\n- Set `placeholders=\"1\"` to enable `%key%` substitution in the label and tooltip\n- The label must use `html=1` style when using HTML formatting with placeholders\n- Placeholders resolve by walking up the containment hierarchy: shape attributes first, then parent container, then layer, then root — first match wins\n- Predefined placeholders work without custom properties: `%id%`, `%width%`, `%height%`, `%date%`, `%time%`, `%timestamp%`, `%page%`, `%pagenumber%`, `%pagecount%`, `%filename%`\n- Use `%%` for a literal percent sign in labels\n- Tags, metadata, and placeholders can all be combined on the same `<object>` element\n- Use metadata when shapes represent data records (servers, services, components) and you want to attach structured information beyond the visible label\n\n## Dark mode colors\n\ndraw.io supports automatic dark mode rendering. How colors behave depends on the property:\n\n- **`strokeColor`, `fillColor`, `fontColor`** default to `\"default\"`, which renders as black in light theme and white in dark theme. When no explicit color is set, colors adapt automatically.\n- **Explicit colors** (e.g. `fillColor=#DAE8FC`) specify the light-mode color. The dark-mode color is computed automatically by inverting the RGB values (blending toward the inverse at 93%) and rotating the hue by 180° (via `mxUtils.getInverseColor`).\n- **`light-dark()` function** — To specify both colors explicitly, use `light-dark(lightColor,darkColor)` in the style string, e.g. `fontColor=light-dark(#7EA6E0,#FF0000)`. The first argument is used in light mode, the second in dark mode.\n\nTo enable dark mode color adaptation, the `mxGraphModel` element must include `adaptiveColors=\"auto\"`.\n\nWhen generating diagrams, you generally do not need to specify dark-mode colors — the automatic inversion handles most cases. Use `light-dark()` only when the automatic inverse color is unsatisfactory.\n\n## Edge routing & layout passes\n\nBy default, edges are drawn by draw.io's **built-in router**, which is intentionally basic: each edge is a straight line or a simple right-angle path between its endpoints, with **no obstacle avoidance** — a connector runs straight through any shape lying between its `source` and `target`. There is no server-side post-processing. Two **opt-in** passes on `create_diagram` upgrade this; they are independent and combine freely, run client-side after the diagram renders, and the exported XML (copy/clipboard, \"Open in draw.io\") reflects the final routed result.\n\n- **`routing: \"libavoid\"`** (XML only) — obstacle-avoiding orthogonal **edge routing**. Vertices stay exactly where you placed them; only the connectors are recomputed, so they run in clean right-angle segments that route *around* the boxes (and spread apart when parallel) instead of cutting across them. Use it for diagrams you laid out deliberately — architecture, network topology, deployment, swimlanes, UML, floor plans — where you want tidy wires without disturbing your layout.\n- **`postLayout: \"elk\"`** — a **full re-layout** (ELK `layered` flow). Vertices animate (morph) from your positions to canonical hierarchical positions, and the edges are routed as part of that. Best for flowcharts, process/state diagrams, decision flows, pipelines, and other directional/hierarchical diagrams. (You should rarely hand-write these as XML — prefer Mermaid.) Flow **direction**: on XML set the optional `direction` field (`\"vertical\"` (default) / `\"horizontal\"`); on Mermaid it is read from the flowchart code (`flowchart TD/TB` vs `LR/RL`) and `direction` is ignored.\n\nThe four combinations:\n\n| `postLayout` | `routing` | Result |\n|---|---|---|\n| — | — | basic built-in router (straight / simple right-angle, no obstacle avoidance); your positions kept |\n| — | `libavoid` | your positions kept; wires re-routed orthogonally *around* the shapes |\n| `elk` | — | ELK places the vertices **and** routes the edges (decent routing built in) |\n| `elk` | `libavoid` | rarely worth it — ELK already routes; only add `libavoid` if ELK's routing specifically comes out poor |\n\n**Pick ONE — they are essentially alternatives, not a stack:**\n- **Neither** — fine when connected nodes sit in clear rows/columns with open space between them, so the basic router's straight/right-angle lines won't cross another shape. Simplest and lightest; do this by default for sparse layouts.\n- **`routing: \"libavoid\"`** — keep your hand-placed layout but clean up the wires: use whenever an edge would otherwise cut across a box, or you want consistently clean orthogonal wires routed around shapes (architecture, network topology, deployment, UML, floor plans — anything densely connected).\n- **`postLayout: \"elk\"`** — when you want a canonical re-layout (vertices moved). ELK routes the edges itself as part of the layout, so **do not also set `routing`** — the combination is redundant in almost all cases. Add `direction: \"horizontal\"` for left-to-right flow.\n\n**For Mermaid diagrams: see the `postLayout` parameter description for when to set it.** Complex Mermaid flowcharts (≥ ~20 nodes, ≥ 3 decision diamonds, feedback edges, or ≥ 3 endpoints) need `postLayout: \"elk\"` because the native parser's layout goes cramped or unbalanced past that threshold — the direction follows the flowchart code, so no `direction` is needed. Simple flowcharts and all non-flowchart Mermaid types (sequence, class, ER, sankey, …) need no `postLayout`.\n\n**When NOT to use (XML):**\n- The user has asked for specific positions (swim lanes with exact lanes, architecture diagrams with meaningful spatial arrangement).\n- The diagram relies on containers/grouping where spatial layout encodes information.\n\n## Style reference\n\nComplete style reference (all shape types, style properties, color palettes, HTML labels, and more): https://github.com/jgraph/drawio-mcp/blob/main/shared/style-reference.md\n\nXML Schema (XSD): https://github.com/jgraph/drawio-mcp/blob/main/shared/mxfile.xsd\n\n## CRITICAL: XML well-formedness\n\nWhen generating draw.io XML, the output **must** be well-formed XML:\n- **NEVER include ANY XML comments (`<!-- -->`) in the output.** XML comments are strictly forbidden — they waste tokens, can cause parse errors, and serve no purpose in diagram XML.\n- Escape special characters in attribute values: `&amp;`, `&lt;`, `&gt;`, `&quot;`\n- Always use unique `id` values for each `mxCell`\n",
+   "description": "Opens the draw.io editor with a diagram from XML content. Use this to view, edit, or create diagrams in draw.io format. The XML should be valid draw.io/mxGraph XML format.\n\n# draw.io XML Reference\n\nDetailed reference for styles, edge routing, containers, layers, tags, metadata, and dark mode. Consult this when generating draw.io XML diagrams.\n\n## Reasoning budget (read this first)\n\nYour 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. The edge router and the optional layout pass (`postLayout: \"elk\"`, see **Edge routing & layout passes**) handle routing and placement; you do **not** need to do layout math.\n\n**Do NOT** in your reasoning:\n\n- 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.\n- 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.\n- 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.\n- Do NOT re-derive drawio mechanics (`horizontal=0`, `startSize=110`, nested-lane coordinates). Use the templates below as-is.\n- Do NOT enumerate columns (\"customer lane columns 0-10, web app 1-7\"). Place a node, move on.\n- Do NOT add `<Array as=\"points\">` waypoints. Edges are routed automatically.\n- Do NOT set `exitX` / `exitY` / `entryX` / `entryY` connection-point overrides unless you have specific geometric intent.\n- Do NOT verify, re-check, or adjust coordinates after placing a node.\n- Do NOT narrate \"building the diagram / finalizing the XML / now let me…\". Just emit XML.\n- Do NOT write out lists of node positions as planning text. Emit them as `<mxCell>` elements directly.\n\n**Do** in your reasoning:\n\n- Identify the diagram type + actors/stages (1-2 short sentences).\n- Identify any grouping (swimlanes? containers? none?).\n- Go straight to XML.\n\n**Rigid grid — use for every XML diagram:**\n\n- Column x = `col_index * 180 + 40`  (col 0 = 40, col 1 = 220, col 2 = 400, …)\n- Row y = `row_index * 120 + 40`     (row 0 = 40, row 1 = 160, row 2 = 280, …)\n- Node size: rectangles `140×60`, diamonds `140×80`, circles `60×60`, documents `120×80`, cylinders `100×70`\n\nPick a `(col, row)` for each node. Don't think about centers or exact gaps — the grid already spaces nodes apart, and slight misalignment is invisible in the result.\n\n**Give every node its own `(col, row)` cell.** Two nodes in the same cell land on top of each other. With `postLayout: \"elk\"` the positions are only a rough starting direction (ELK re-places everything); without it they are the final positions, so the cell you pick is what the user sees.\n\n## General principles\n\n- **Use proper draw.io shapes and connectors** — choose the semantically correct shape for each element (e.g., `shape=cylinder3` for databases and tanks, `rhombus` for decisions, `shape=mxgraph.pid2valves.*` for valves in P&IDs). draw.io has extensive shape libraries; prefer domain-appropriate shapes over generic rectangles.\n- **Decide whether to search for shapes** — before generating a diagram, decide if it needs domain-specific shapes from draw.io's extended libraries. **Skip `search_shapes`** for standard diagram types that use basic geometric shapes: flowcharts, UML (class, sequence, state, activity), ERD, org charts, mind maps, Venn diagrams, timelines, wireframes, and any diagram using only rectangles, diamonds, circles, cylinders, and arrows. Also skip if the user explicitly asks to use basic/simple shapes or says not to search. **Use `search_shapes`** when the diagram requires industry-specific or branded icons: cloud architecture (AWS, Azure, GCP), network topology (Cisco, rack equipment), P&ID (valves, instruments, vessels), electrical/circuit diagrams, Kubernetes, BPMN with specific task types, or any domain where the user expects realistic/standardized symbols rather than labeled boxes. It also finds brand/product logos and general-purpose pictorial icons (e.g. `react`, `slack`, `shopping cart`, `solar panel`) — returned as ready-to-use `shape=image` styles — so use it too when the user asks for logos or everyday concept icons.\n- **Match the language of labels to the user's language** — if the user writes in German, French, Japanese, etc., all diagram labels, titles, and annotations should be in that same language.\n- **Group related nodes, and surface a hub when edges converge** — put nodes that belong together inside a container or swimlane, and keep external actors (users, files, third-party systems) outside implementation containers. When many edges converge on one area or cross several groups, route them through a single hub/gateway node (a registry, broker, event log, …) instead of drawing every low-level dependency across the canvas — fewer crossings, clearer contract.\n- **Encode secondary detail in node text, not edges** — draw an edge only when the relationship itself carries meaning; push incidental detail into the node label so the connector layer stays readable.\n- **File each edge at the innermost container holding BOTH endpoints** — `parent=\"<container_id>\"` when both ends sit in the same container (at any nesting depth), `parent=\"1\"` when one end is outside all containers. Auto-layout reads an edge's coordinates in its parent's frame, so an edge parked further out than its endpoints is laid out in the wrong place. Details under [Nested architecture containers](#nested-architecture-containers-cloud-infra-network-topologies).\n\n## Common styles\n\n**Rounded rectangle:**\n```xml\n<mxCell id=\"2\" value=\"Label\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"100\" y=\"100\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n```\n\n**Diamond (decision):**\n```xml\n<mxCell id=\"3\" value=\"Condition?\" style=\"rhombus;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"100\" y=\"200\" width=\"120\" height=\"80\" as=\"geometry\"/>\n</mxCell>\n```\n\n**Arrow (edge):**\n```xml\n<mxCell id=\"4\" value=\"\" style=\"edgeStyle=orthogonalEdgeStyle;html=1;\" edge=\"1\" source=\"2\" target=\"3\" parent=\"1\">\n  <mxGeometry relative=\"1\" as=\"geometry\"/>\n</mxCell>\n```\n\n**Labeled arrow:**\n```xml\n<mxCell id=\"5\" value=\"Yes\" style=\"edgeStyle=orthogonalEdgeStyle;html=1;\" edge=\"1\" source=\"3\" target=\"6\" parent=\"1\">\n  <mxGeometry relative=\"1\" as=\"geometry\"/>\n</mxCell>\n```\n\n## Style properties\n\n| Property | Values | Use for |\n|----------|--------|---------|\n| `rounded=1` | 0 or 1 | Rounded corners |\n| `whiteSpace=wrap` | wrap | Text wrapping |\n| `fillColor=#dae8fc` | Hex color | Background color |\n| `strokeColor=#6c8ebf` | Hex color | Border color |\n| `fontColor=#333333` | Hex color | Text color |\n| `shape=cylinder3` | shape name | Database cylinders |\n| `shape=mxgraph.flowchart.document` | shape name | Document shapes |\n| `ellipse` | style keyword | Circles/ovals |\n| `rhombus` | style keyword | Diamonds |\n| `edgeStyle=orthogonalEdgeStyle` | style keyword | Right-angle connectors |\n| `edgeStyle=elbowEdgeStyle` | style keyword | Elbow connectors |\n| `dashed=1` | 0 or 1 | Dashed lines |\n| `swimlane` | style keyword | Swimlane containers |\n| `group` | style keyword | Invisible container (pointerEvents=0) |\n| `container=1` | 0 or 1 | Enable container behavior on any shape |\n| `pointerEvents=0` | 0 or 1 | Prevent container from capturing child connections |\n| `html=1` | 0 or 1 | Enable HTML rendering in labels (required for `<b>`, `<br>`, `<font>`, etc.) |\n| `shape=umlLifeline;perimeter=lifelinePerimeter;size=16` | shape | UML sequence diagram lifeline (size = header height) |\n\n## HTML labels\n\n**Always include `html=1` in the style** when the `value` attribute contains any HTML tags (`<b>`, `<br>`, `<font>`, `<i>`, `<u>`, `<hr>`, `<p>`, `<table>`, etc.). Without `html=1`, HTML tags are displayed as literal text instead of being rendered.\n\nHTML in attribute values must be **XML-escaped**: `<` → `&lt;`, `>` → `&gt;`, `&` → `&amp;`, `\"` → `&quot;`\n\n```xml\n<mxCell value=\"&lt;b&gt;Title&lt;/b&gt;&lt;br&gt;Description\"\n        style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"100\" y=\"100\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n```\n\n**Line breaks:** Use `&#xa;` (works with both `html=1` and `html=0`) or `&lt;br&gt;` (requires `html=1`) for line breaks — never use `\\n`, which renders as literal backslash-n text instead of a newline.\n\n**Best practice:** Always include `html=1` in every cell style. This ensures labels render correctly whether they contain HTML or plain text — plain text is unaffected by the flag.\n\n**Bold/italic/underline:** Use `fontStyle` in the style string when the entire label should be bold (`fontStyle=1`), italic (`fontStyle=2`), or underline (`fontStyle=4`). Values can be combined via bitwise OR (e.g., `fontStyle=3` = bold+italic). Use HTML tags (`<b>`, `<i>`, `<u>`) only when formatting part of the label (e.g., bold title with normal description). Never combine `fontStyle` with HTML tags for the same effect — this is redundant and causes visible raw tags if `html=1` is missing.\n\n## Edges\n\n**CRITICAL: Every edge `mxCell` must contain a `<mxGeometry relative=\"1\" as=\"geometry\" />` child element.** Self-closing edge cells (e.g. `<mxCell ... edge=\"1\" ... />`) are invalid and will not render correctly. Always use the expanded form:\n```xml\n<mxCell id=\"e1\" edge=\"1\" parent=\"1\" source=\"a\" target=\"b\" style=\"...\">\n  <mxGeometry relative=\"1\" as=\"geometry\" />\n</mxCell>\n```\n\n**Don't hand-route edges.** Just declare `source` and `target`. You do **not** need to:\n- Add `<mxPoint>` waypoints\n- Set `exitX` / `exitY` / `entryX` / `entryY`\n- Route around obstacles\n- Worry about edge-vertex collisions or parallel edge spacing\n\ndraw.io's built-in router is **basic**: it draws each edge as a straight line or a simple right-angle path between `source` and `target`, with **no awareness of other shapes** — a wire will run straight across any box that sits between its endpoints. That's fine when connected nodes have open space between them. When edges would otherwise cross over shapes, or you want consistently clean orthogonal wires that route *around* the boxes, set **`routing: \"libavoid\"`**; for a full re-layout use **`postLayout: \"elk\"`** (see **Edge routing & layout passes** below). Both compute the waypoints for you — you never add them by hand either way.\n\n**What you still choose: the edge style.** The style determines the overall look (orthogonal angles, curves, straight lines) — the router honors the style family.\n\n| Style | Syntax | Best for |\n|-------|--------|---------|\n| **Orthogonal** | `edgeStyle=orthogonalEdgeStyle` | Flowcharts, architecture, network diagrams, BPMN — any diagram with right-angle connectors |\n| **Straight** | no `edgeStyle` | UML class/sequence diagrams, direct point-to-point connections. For sequence diagram messages use `endSize=6;startSize=6;` to keep arrowheads small |\n| **Entity Relation** | `edgeStyle=entityRelationEdgeStyle` | ER diagrams — creates perpendicular stubs at both ends |\n| **Curved** | `curved=1` | Mind maps, informal diagrams |\n| **Elbow** | `edgeStyle=elbowEdgeStyle;elbow=vertical;` | Rarely needed — `orthogonalEdgeStyle` handles almost all cases; use this only for simple 1-bend linear flows |\n\n**Use a consistent edge style within each diagram.** Pick one based on diagram type and apply it to all edges: ER → `entityRelationEdgeStyle`; UML class → straight; mind maps → curved; flowcharts/architecture/network → `orthogonalEdgeStyle`.\n\n**Useful edge style attributes** that apply regardless of routing:\n- `rounded=1` — rounded corners at bend points (recommended for orthogonal)\n- `endArrow=classic` / `endArrow=none` — arrow heads\n- `dashed=1` — dashed line\n- `strokeColor=#...`, `strokeWidth=2` — color/width\n- Edge labels: set `value` directly on the edge cell\n\n**Keep edge labels short and meaningful** — one to three words (`Yes`, `async`, `reads`). Drop labels that merely restate an obvious action (`call`, `register`); move longer explanations into node text or a small legend node.\n\n**Visual semantics — stay consistent, add a legend when mixing styles.** Within one diagram apply `dashed=1`, `strokeColor`, and `strokeWidth` consistently for one chosen meaning (e.g. dashed = optional / async / inferred relationship). Don't mix several dashed meanings without a small legend explaining them.\n\n## Containers and groups\n\nFor architecture diagrams or any diagram with nested elements, use draw.io's proper parent-child containment — do **not** just place shapes on top of larger shapes.\n\n### How containment works\n\nSet `parent=\"containerId\"` on child cells. Children use **relative coordinates** within the container.\n\n### Container types\n\n| Type | Style | When to use |\n|------|-------|-------------|\n| **Group** (invisible) | `group;` | No visual border needed, container has no connections. Includes `pointerEvents=0` so child connections are not captured |\n| **Swimlane** (titled) | `swimlane;startSize=30;` | Container needs a visible title bar/header, or the container itself has connections |\n| **Custom container** | Add `container=1;pointerEvents=0;` to any shape style | Any shape acting as a container without its own connections |\n\n### Key rules\n\n- **Edges to children inside containers naturally cross the container boundary** — this is correct and expected. Do not add extra waypoints or complex routing to avoid a parent container when connecting to shapes inside it.\n- **Always add `pointerEvents=0;`** to container styles that should not capture connections being rewired between children\n- Only omit `pointerEvents=0` when the container itself needs to be connectable — in that case, use `swimlane` style which handles this correctly (the client area is transparent for mouse events while the header remains connectable)\n- Children must set `parent=\"containerId\"` and use coordinates **relative to the container**\n\n### Example: Architecture container with swimlane\n\n```xml\n<mxCell id=\"svc1\" value=\"User Service\" style=\"swimlane;startSize=30;fillColor=#dae8fc;strokeColor=#6c8ebf;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"100\" y=\"100\" width=\"300\" height=\"200\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"api1\" value=\"REST API\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"svc1\">\n  <mxGeometry x=\"20\" y=\"40\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"db1\" value=\"Database\" style=\"shape=cylinder3;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"svc1\">\n  <mxGeometry x=\"160\" y=\"40\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n```\n\n### Example: Invisible group container\n\n```xml\n<mxCell id=\"grp1\" value=\"\" style=\"group;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"100\" y=\"100\" width=\"300\" height=\"200\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"c1\" value=\"Component A\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"grp1\">\n  <mxGeometry x=\"10\" y=\"10\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n```\n\n### Swimlanes for grouped actors (BPMN-style flowcharts)\n\nUse **flat swimlanes** at `parent=\"1\"`, stacked vertically. One row of nodes per lane.\n\n**Fixed values — do not compute or debate:**\n- Lane size: `x=0, y=lane_index*150, width=CANVAS_W, height=150`\n- Lane style: `swimlane;horizontal=0;startSize=110;fillColor=<pastel>;html=1;`\n- Child nodes inside a lane: `parent=\"<lane_id>\"`, `x = 120 + col*180`, `y = 45` (always 45), size 140×60 (or 140×80 for diamonds)\n- Cross-lane edges: `parent=\"1\"` (not inside a lane)\n\nPick `CANVAS_W = max_col * 180 + 300`. Choose lane colors from `#f5f5f5, #e8f4f8, #fff0e6, #e8f5e9, #fff9e6, #fce4ec` in that order.\n\n```xml\n<mxCell id=\"lane1\" value=\"Customer\" style=\"swimlane;horizontal=0;startSize=110;fillColor=#f5f5f5;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"0\" y=\"0\" width=\"1800\" height=\"150\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"n1\" value=\"Place Order\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"lane1\">\n  <mxGeometry x=\"120\" y=\"45\" width=\"140\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"lane2\" value=\"System\" style=\"swimlane;horizontal=0;startSize=110;fillColor=#e8f4f8;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"0\" y=\"150\" width=\"1800\" height=\"150\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"n2\" value=\"Validate\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"lane2\">\n  <mxGeometry x=\"300\" y=\"45\" width=\"140\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"e1\" edge=\"1\" parent=\"1\" source=\"n1\" target=\"n2\" style=\"edgeStyle=orthogonalEdgeStyle;rounded=1;html=1;\">\n  <mxGeometry relative=\"1\" as=\"geometry\"/>\n</mxCell>\n```\n\nDo NOT nest lanes inside a pool. Do NOT vary lane heights. Do NOT compute title-area offset — it is always 110, children start at x=120 to clear it.\n\n### Nested architecture containers (cloud, infra, network topologies)\n\nFor diagrams with **nested groupings** — VPC → Availability Zone → EC2 instance, Datacenter → Rack → Server, Region → Environment → Service — use nested swimlanes. This is where the AI most often flattens hierarchy that should be nested. Treat each level as a swimlane container.\n\n**Rules:**\n- Every container is a `swimlane` with `startSize=24` (title area at the top).\n- Child cells set `parent=\"<container_id>\"` and use coordinates **relative to their parent** (origin 0,0 is the parent's top-left, below the title).\n- **An edge belongs to the innermost container that holds BOTH of its endpoints.** Walk up from both ends until you reach a container that contains both: two cells in the same subnet → that subnet; a web tier and a database tier inside one region → that region; anything with one endpoint outside all containers → `parent=\"1\"`, the layer. This is the rule the draw.io editor's own model maintains, and auto-layout reads an edge's coordinates in its parent's frame, so an edge filed too far out lands in the wrong place.\n- For industry-specific icons (AWS/Azure/GCP logos, Cisco equipment, etc.), call `search_shapes` to get the exact `style` string and substitute it into a regular vertex — the container structure stays the same.\n\n```xml\n<mxCell id=\"vpc\" value=\"VPC\" style=\"swimlane;startSize=24;fillColor=#dae8fc;strokeColor=#6c8ebf;html=1;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"0\" y=\"0\" width=\"720\" height=\"360\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"az1\" value=\"AZ us-east-1a\" style=\"swimlane;startSize=24;fillColor=#fff2cc;strokeColor=#d6b656;html=1;\" vertex=\"1\" parent=\"vpc\">\n  <mxGeometry x=\"20\" y=\"36\" width=\"320\" height=\"300\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"web1\" value=\"web-1\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"az1\">\n  <mxGeometry x=\"30\" y=\"40\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"db1\" value=\"db-1\" style=\"shape=cylinder3;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"az1\">\n  <mxGeometry x=\"180\" y=\"40\" width=\"100\" height=\"70\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"az2\" value=\"AZ us-east-1b\" style=\"swimlane;startSize=24;fillColor=#fff2cc;strokeColor=#d6b656;html=1;\" vertex=\"1\" parent=\"vpc\">\n  <mxGeometry x=\"360\" y=\"36\" width=\"340\" height=\"300\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"web2\" value=\"web-2\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"az2\">\n  <mxGeometry x=\"30\" y=\"40\" width=\"120\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"e1\" edge=\"1\" parent=\"1\" source=\"web1\" target=\"web2\" style=\"edgeStyle=orthogonalEdgeStyle;rounded=1;html=1;\">\n  <mxGeometry relative=\"1\" as=\"geometry\"/>\n</mxCell>\n```\n\n### Cross-functional flowcharts (actor × phase grid, as a table)\n\nCross-functional flowcharts show a process across **two axes at once** — actors (rows) and phases (columns). Use drawio's `table` shape, which auto-arranges cells into a grid via `childLayout=tableLayout`. This is the canonical draw.io pattern and is distinct from plain swimlanes (which only group on one axis).\n\n**Structure:**\n- Outer container: `shape=table;childLayout=tableLayout;startSize=0;collapsible=0;fillColor=none;`\n- Rows are children of the table: `shape=tableRow;horizontal=0;startSize=0;collapsible=0;`\n- Cells are children of rows — regular vertices, one per (actor, phase) intersection\n- Row heights and cell widths are set via `mxGeometry`; they tile automatically\n- First row = phase headers; first cell of every other row = actor label\n- Process nodes go INSIDE the appropriate cell (parent = cell id) at coordinates relative to the cell\n- Cross-cell edges must use `parent=\"1\"` (same rule as containers)\n\n```xml\n<mxCell id=\"tbl\" style=\"shape=table;childLayout=tableLayout;startSize=0;collapsible=0;fillColor=none;\" vertex=\"1\" parent=\"1\">\n  <mxGeometry x=\"0\" y=\"0\" width=\"900\" height=\"320\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"r0\" style=\"shape=tableRow;horizontal=0;startSize=0;collapsible=0;\" vertex=\"1\" parent=\"tbl\">\n  <mxGeometry width=\"900\" height=\"40\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"h0\" style=\"text;html=1;\" vertex=\"1\" parent=\"r0\">\n  <mxGeometry width=\"140\" height=\"40\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"h1\" value=\"Order\" style=\"text;align=center;fontStyle=1;fillColor=#e8e8e8;\" vertex=\"1\" parent=\"r0\">\n  <mxGeometry x=\"140\" width=\"380\" height=\"40\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"h2\" value=\"Fulfill\" style=\"text;align=center;fontStyle=1;fillColor=#e8e8e8;\" vertex=\"1\" parent=\"r0\">\n  <mxGeometry x=\"520\" width=\"380\" height=\"40\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"r1\" style=\"shape=tableRow;horizontal=0;startSize=0;collapsible=0;\" vertex=\"1\" parent=\"tbl\">\n  <mxGeometry y=\"40\" width=\"900\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"a1\" value=\"Customer\" style=\"fillColor=#dae8fc;fontStyle=1;\" vertex=\"1\" parent=\"r1\">\n  <mxGeometry width=\"140\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"c_cust_order\" style=\"fillColor=none;\" vertex=\"1\" parent=\"r1\">\n  <mxGeometry x=\"140\" width=\"380\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"t_place\" value=\"Place Order\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"c_cust_order\">\n  <mxGeometry x=\"120\" y=\"40\" width=\"140\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"c_cust_fulfill\" style=\"fillColor=none;\" vertex=\"1\" parent=\"r1\">\n  <mxGeometry x=\"520\" width=\"380\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"r2\" style=\"shape=tableRow;horizontal=0;startSize=0;collapsible=0;\" vertex=\"1\" parent=\"tbl\">\n  <mxGeometry y=\"180\" width=\"900\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"a2\" value=\"System\" style=\"fillColor=#d5e8d4;fontStyle=1;\" vertex=\"1\" parent=\"r2\">\n  <mxGeometry width=\"140\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"c_sys_order\" style=\"fillColor=none;\" vertex=\"1\" parent=\"r2\">\n  <mxGeometry x=\"140\" width=\"380\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"t_validate\" value=\"Validate\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"c_sys_order\">\n  <mxGeometry x=\"120\" y=\"40\" width=\"140\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"c_sys_fulfill\" style=\"fillColor=none;\" vertex=\"1\" parent=\"r2\">\n  <mxGeometry x=\"520\" width=\"380\" height=\"140\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"t_ship\" value=\"Ship\" style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"c_sys_fulfill\">\n  <mxGeometry x=\"120\" y=\"40\" width=\"140\" height=\"60\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"e1\" edge=\"1\" parent=\"1\" source=\"t_place\" target=\"t_validate\" style=\"edgeStyle=orthogonalEdgeStyle;rounded=1;html=1;\">\n  <mxGeometry relative=\"1\" as=\"geometry\"/>\n</mxCell>\n<mxCell id=\"e2\" edge=\"1\" parent=\"1\" source=\"t_validate\" target=\"t_ship\" style=\"edgeStyle=orthogonalEdgeStyle;rounded=1;html=1;\">\n  <mxGeometry relative=\"1\" as=\"geometry\"/>\n</mxCell>\n```\n\n**When to use cross-functional tables vs flat swimlanes:**\n- Flat swimlanes — one-dimensional (actors only, or phases only). Simpler. Use this when you just need to show who does what in sequence.\n- Cross-functional table — two-dimensional (actors AND phases). Use this when **both** the actor and the process stage matter, and every step belongs to a specific (actor, phase) cell.\n\n**Do NOT** nest swimlanes inside a table row, do NOT set `startSize` on rows or cells (columns tile from `x=0`), and do NOT rely on the AI to produce exact widths that sum to the table width — close-enough totals are fine, the `tableLayout` normalizes them.\n\n## Layers\n\nLayers control visibility and z-order. Every cell belongs to exactly one layer. Use layers to manage diagram complexity — viewers can toggle layer visibility to show or hide groups of elements (e.g., \"Physical Infrastructure\" vs \"Logical Network\" vs \"Security Zones\").\n\nCell `id=\"0\"` is the root and cell `id=\"1\"` is the default layer — both always exist. Additional layers are `mxCell` elements with `parent=\"0\"`:\n\n```xml\n<mxGraphModel>\n  <root>\n    <mxCell id=\"0\"/>\n    <mxCell id=\"1\" parent=\"0\"/>\n    <mxCell id=\"2\" value=\"Annotations\" parent=\"0\"/>\n    <mxCell id=\"10\" value=\"Server\" style=\"rounded=1;html=1;\" vertex=\"1\" parent=\"1\">\n      <mxGeometry x=\"100\" y=\"100\" width=\"120\" height=\"60\" as=\"geometry\"/>\n    </mxCell>\n    <mxCell id=\"20\" value=\"Note: deprecated\" style=\"text;\" vertex=\"1\" parent=\"2\">\n      <mxGeometry x=\"100\" y=\"170\" width=\"120\" height=\"30\" as=\"geometry\"/>\n    </mxCell>\n  </root>\n</mxGraphModel>\n```\n\n- A layer is an `mxCell` with `parent=\"0\"` and no `vertex` or `edge` attribute\n- Assign shapes to a layer by setting `parent` to the layer's id\n- Later layers render on top of earlier layers (higher z-order)\n- Add `visible=\"0\"` as an attribute on the layer cell to hide it by default\n- Use layers when the diagram has distinct conceptual groupings that viewers may want to toggle independently\n\n## Tags\n\nTags are visual filters that let viewers show or hide elements by category. Unlike layers, a single element can have multiple tags, making tags ideal for cross-cutting concerns (e.g., tagging shapes as \"critical\", \"v2\", or \"backend\").\n\nTags require wrapping `mxCell` in an `<object>` element. Tags are assigned via the `tags` attribute as a space-separated string:\n\n```xml\n<mxGraphModel>\n  <root>\n    <mxCell id=\"0\"/>\n    <mxCell id=\"1\" parent=\"0\"/>\n    <object id=\"2\" label=\"Auth Service\" tags=\"critical v2\">\n      <mxCell style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"1\">\n        <mxGeometry x=\"100\" y=\"100\" width=\"120\" height=\"60\" as=\"geometry\"/>\n      </mxCell>\n    </object>\n    <object id=\"3\" label=\"Legacy API\" tags=\"critical deprecated\">\n      <mxCell style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"1\">\n        <mxGeometry x=\"300\" y=\"100\" width=\"120\" height=\"60\" as=\"geometry\"/>\n      </mxCell>\n    </object>\n  </root>\n</mxGraphModel>\n```\n\n- Tags require the `<object>` wrapper — a plain `mxCell` cannot have tags\n- The `label` attribute on `<object>` replaces `value` on `mxCell`\n- Tags are space-separated in the `tags` attribute\n- Viewers filter the diagram by selecting tags in the draw.io UI (Edit > Tags)\n- Tags do not affect z-order or structural grouping — they are purely a visibility filter\n\n## Metadata and placeholders\n\nMetadata stores custom key-value properties on shapes as additional attributes on the `<object>` wrapper element. Combined with placeholders, metadata values can be displayed in labels — useful for data-driven diagrams showing status, owner, IP addresses, or versions on each shape.\n\nSet `placeholders=\"1\"` on the `<object>` to enable `%propertyName%` substitution in the `label`:\n\n```xml\n<mxGraphModel>\n  <root>\n    <mxCell id=\"0\"/>\n    <mxCell id=\"1\" parent=\"0\"/>\n    <object id=\"2\" label=\"&lt;b&gt;%component%&lt;/b&gt;&lt;br&gt;Owner: %owner%&lt;br&gt;Status: %status%\"\n            placeholders=\"1\" component=\"Auth Service\" owner=\"Team Backend\" status=\"Active\">\n      <mxCell style=\"rounded=1;whiteSpace=wrap;html=1;\" vertex=\"1\" parent=\"1\">\n        <mxGeometry x=\"100\" y=\"100\" width=\"160\" height=\"80\" as=\"geometry\"/>\n      </mxCell>\n    </object>\n  </root>\n</mxGraphModel>\n```\n\n- Custom properties are plain XML attributes on `<object>` (e.g., `component=\"Auth Service\"`)\n- Set `placeholders=\"1\"` to enable `%key%` substitution in the label and tooltip\n- The label must use `html=1` style when using HTML formatting with placeholders\n- Placeholders resolve by walking up the containment hierarchy: shape attributes first, then parent container, then layer, then root — first match wins\n- Predefined placeholders work without custom properties: `%id%`, `%width%`, `%height%`, `%date%`, `%time%`, `%timestamp%`, `%page%`, `%pagenumber%`, `%pagecount%`, `%filename%`\n- Use `%%` for a literal percent sign in labels\n- Tags, metadata, and placeholders can all be combined on the same `<object>` element\n- Use metadata when shapes represent data records (servers, services, components) and you want to attach structured information beyond the visible label\n\n## Dark mode colors\n\ndraw.io supports automatic dark mode rendering. How colors behave depends on the property:\n\n- **`strokeColor`, `fillColor`, `fontColor`** default to `\"default\"`, which renders as black in light theme and white in dark theme. When no explicit color is set, colors adapt automatically.\n- **Explicit colors** (e.g. `fillColor=#DAE8FC`) specify the light-mode color. The dark-mode color is computed automatically by inverting the RGB values (blending toward the inverse at 93%) and rotating the hue by 180° (via `mxUtils.getInverseColor`).\n- **`light-dark()` function** — To specify both colors explicitly, use `light-dark(lightColor,darkColor)` in the style string, e.g. `fontColor=light-dark(#7EA6E0,#FF0000)`. The first argument is used in light mode, the second in dark mode.\n\nTo enable dark mode color adaptation, the `mxGraphModel` element must include `adaptiveColors=\"auto\"`.\n\nWhen generating diagrams, you generally do not need to specify dark-mode colors — the automatic inversion handles most cases. Use `light-dark()` only when the automatic inverse color is unsatisfactory.\n\n## Edge routing & layout passes\n\nBy default, edges are drawn by draw.io's **built-in router**, which is intentionally basic: each edge is a straight line or a simple right-angle path between its endpoints, with **no obstacle avoidance** — a connector runs straight through any shape lying between its `source` and `target`. Two **opt-in** passes upgrade this. Set them as fields on the same call that carries the diagram; the result you open, export or copy always reflects the finished pass.\n\n- **`routing: \"libavoid\"`** (XML only) — obstacle-avoiding orthogonal **edge routing**. Vertices stay exactly where you placed them; only the connectors are recomputed, so they run in clean right-angle segments that route *around* the boxes (and spread apart when parallel) instead of cutting across them. Use it for diagrams you laid out deliberately — architecture, network topology, deployment, swimlanes, UML, floor plans — where you want tidy wires without disturbing your layout.\n- **`postLayout: \"elk\"`** — a **full re-layout** (ELK `layered` flow). Vertices move from your positions to canonical hierarchical ones, and the edges are routed as part of that. Node sizes are kept exactly as you declare them, so a label still has to fit the box you gave it. Best for flowcharts, process/state diagrams, decision flows, pipelines, and other directional/hierarchical diagrams. (You should rarely hand-write these as XML — prefer Mermaid.) Flow **direction**: on XML set the optional `direction` field (`\"vertical\"` (default) / `\"horizontal\"`); on Mermaid it is read from the flowchart code (`flowchart TD/TB` vs `LR/RL`) and `direction` is ignored.\n\nThe four combinations:\n\n| `postLayout` | `routing` | Result |\n|---|---|---|\n| — | — | basic built-in router (straight / simple right-angle, no obstacle avoidance); your positions kept |\n| — | `libavoid` | your positions kept; wires re-routed orthogonally *around* the shapes |\n| `elk` | — | ELK places the vertices **and** routes the edges (decent routing built in) |\n| `elk` | `libavoid` | rarely worth it — ELK already routes; only add `libavoid` if ELK's routing specifically comes out poor |\n\n**Pick ONE — they are essentially alternatives, not a stack:**\n- **Neither** — fine when connected nodes sit in clear rows/columns with open space between them, so the basic router's straight/right-angle lines won't cross another shape. Simplest and lightest; do this by default for sparse layouts.\n- **`routing: \"libavoid\"`** — keep your hand-placed layout but clean up the wires: use whenever an edge would otherwise cut across a box, or you want consistently clean orthogonal wires routed around shapes (architecture, network topology, deployment, UML, floor plans — anything densely connected).\n- **`postLayout: \"elk\"`** — when you want a canonical re-layout (vertices moved). ELK routes the edges itself as part of the layout, so **do not also set `routing`** — the combination is redundant in almost all cases. Add `direction: \"horizontal\"` for left-to-right flow.\n\n**When you are passing Mermaid instead of XML: see the `postLayout` parameter description for when to set it.** Complex Mermaid flowcharts (≥ ~20 nodes, ≥ 3 decision diamonds, feedback edges, or ≥ 3 endpoints) need `postLayout: \"elk\"` because the native parser's layout goes cramped or unbalanced past that threshold — the direction follows the flowchart code, so no `direction` is needed. Simple flowcharts and all non-flowchart Mermaid types (sequence, class, ER, sankey, …) need no `postLayout`.\n\n**When NOT to use (XML):**\n- The user has asked for specific positions (swim lanes with exact lanes, architecture diagrams with meaningful spatial arrangement).\n- The diagram relies on containers/grouping where spatial layout encodes information.\n\n## Style reference\n\nComplete style reference (all shape types, style properties, color palettes, HTML labels, and more): https://github.com/jgraph/drawio-mcp/blob/main/shared/style-reference.md\n\nXML Schema (XSD): https://github.com/jgraph/drawio-mcp/blob/main/shared/mxfile.xsd\n\n## CRITICAL: XML well-formedness\n\nWhen generating draw.io XML, the output **must** be well-formed XML:\n- **NEVER include ANY XML comments (`<!-- -->`) in the output.** XML comments are strictly forbidden — they waste tokens, can cause parse errors, and serve no purpose in diagram XML.\n- Escape special characters in attribute values: `&amp;`, `&lt;`, `&gt;`, `&quot;`\n- Always use unique `id` values for each `mxCell`\n",
    "inputSchema": {
      "properties": {
        "content": {
+       "direction": {
+         "description": "Flow direction for `postLayout: \"elk\"`: \"vertical\" (top-down, the default) or \"horizontal\" (left-to-right). Only meaningful together with `postLayout`.",
+         "enum": [
+           "vertical",
+           "horizontal"
+         ],
+         "type": "string"
+       },
        "lightbox": {
          "description": "Open in lightbox mode (read-only view). Default: false",
          "type": "boolean"
+       "postLayout": {
+         "description": "Optional full re-layout (ELK layered flow), applied server-side before the diagram opens. The only value is \"elk\". It PLACES the vertices — your x/y coordinates then only need to express rough direction — and routes the edges as part of the layout. Set it for every directional/hierarchical diagram: flowcharts, process and state diagrams, decision trees, pipelines. Omit it when the layout carries hand-crafted meaning (swimlanes, containers, architecture, UML), which is the usual reason to place cells by hand. Node sizes are kept exactly as you declare them; only positions change (and containers resize around their laid-out children).",
+         "enum": [
+           "elk"
+         ],
+         "type": "string"
+       },
        "routing": {
-         "description": "Optional obstacle-avoiding orthogonal edge-routing pass (libavoid), applied server-side before the diagram opens. The only value is \"libavoid\". It keeps your vertex positions and only recomputes the connectors so they run in clean right-angle segments that route AROUND the boxes instead of cutting through them (draw.io's default router draws a straight/simple line with no obstacle avoidance). Set it for hand-placed diagrams where edges would otherwise cross shapes — architecture, network, deployment, UML, floor plans. Omit it for sparse layouts where connectors won't overlap anything.",
+         "description": "Optional obstacle-avoiding orthogonal edge-routing pass (libavoid), applied server-side before the diagram opens. The only value is \"libavoid\". It keeps your vertex positions and only recomputes the connectors so they run in clean right-angle segments that route AROUND the boxes instead of cutting through them (draw.io's default router draws a straight/simple line with no obstacle avoidance). Set it for hand-placed diagrams where edges would otherwise cross shapes — architecture, network, deployment, UML, floor plans. Omit it for sparse layouts where connectors won't overlap anything. Treat `postLayout` and `routing` as alternatives: ELK already routes its own edges, so don't set both.",
          "enum": [
            "libavoid"
          ],

Current tools

Watch this server yourself

If you run this server, put the proxy in front of it. It pins these exact fingerprints on first connect and stops the session if they move.

npx -y mcp-pin@0.2.3 -- <your @drawio/mcp command>

Or subscribe to this page's RSS feed to be told when it changes.

Badge

The badge states one fact about time and nothing else. It never claims a server is safe.

[![mcp-pin](https://mcp-pin.gautamkhosla.com/badge/864aa04ddbac24ed.svg)](https://mcp-pin.gautamkhosla.com/servers/864aa04ddbac24ed.html)