Skip to main content
Glama

open_drawio_xml

Open the draw.io editor with a diagram from draw.io XML for custom styling, precise positioning, and stencil-based visuals such as cloud, network, P&ID, UI mockups, or floor plans.

Instructions

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.

XML rules:

  • Skeleton: …. Unique ids. No XML comments.

  • Vertex:

  • Edge: . Never self-closing. No waypoints or exitX/entryX.

  • Labels: html=1 in every style; escape HTML in values (<b>Name</b><br>detail); line break <br>, never \n.

  • Shapes: rhombus (decision), ellipse, shape=cylinder3 (database), text.

  • Grid, no layout math: x=col180+40, y=row120+40, one node per cell; 140×60 boxes, 140×80 diamonds.

  • Containers: swimlane;startSize=24; (titled) or group; (invisible); children set parent="" with coordinates relative to it. An edge's parent is the innermost container holding both its ends, else "1".

  • Lanes: swimlane;horizontal=0;startSize=110; at x=0, y=lane150, height 150; nodes inside at x=120+col180, y=45.

  • Edges: orthogonal; entityRelationEdgeStyle for ER; labels 1-3 words; dashed=1 for one meaning, with a legend.

  • Cloud/network/P&ID icons or logos: call search_shapes, use its style.

  • 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.

Only 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
darkNoDark mode setting. Default: auto
contentYesThe draw.io XML content in mxGraphModel format.
routingNoOptional 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.
lightboxNoOpen in lightbox mode (read-only view). Default: false
directionNoFlow direction for `postLayout: "elk"`: "vertical" (top-down, the default) or "horizontal" (left-to-right). Only meaningful together with `postLayout`.
postLayoutNoOptional 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).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

No annotations provided, so the description carries the full burden. It discloses that postLayout and routing are applied server-side before the diagram opens, describes their effects in detail (ELK places vertices and routes edges; libavoid keeps vertex positions and recomputes connectors), and warns never to set both. It does not mention authentication or persistence side effects, but given the tool opens an editor with provided content, the behavioral disclosure is strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but organized with clear headings and bullet points. Every rule appears necessary for correct XML construction, and purpose/usage are front-loaded. However, some detail might be overwhelming for a tool description and borders on reference material.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complex XML content parameter and six parameters with enums, the description provides comprehensive XML rules, usage routing to siblings (open_drawio_mermaid, search_shapes, get_drawio_reference), and behavioral notes. No output schema is needed since it opens an editor. Complete for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions for parameters like `content` are minimal ('draw.io XML content in mxGraphModel format'), while the description provides extensive XML syntax rules (skeleton, vertex, edge, labels, shapes, containers, lanes, etc.) that define what valid content looks like. It also gives usage context for `postLayout` and `routing` beyond the schema's technical descriptions, adding substantial meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Opens the draw.io editor with a diagram from draw.io XML.' It clearly distinguishes from siblings by saying 'prefer open_drawio_mermaid for flowcharts, sequence, class, ER and the other types Mermaid covers.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use this tool ('custom styling, precise positioning and stencil-based diagrams') and when to use the alternative ('prefer open_drawio_mermaid for...'). Also says when to call search_shapes and get_drawio_reference, and when to use postLayout vs routing (never both).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.