Skip to main content
Glama
DayuanJiang

next-ai-drawio

by DayuanJiang
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Edit diagram

edit_diagram

Edit a specific page in the current draw.io diagram using ID-based add, update, or delete cell operations, applying changes only when every operation succeeds.

Instructions

Edit a specific page in the current diagram by ID-based operations (update/add/delete cells).

All-or-nothing: if any operation fails, nothing is applied and every failure is listed.

Freshness: the server remembers the last diagram state you have seen, and rejects this call only if the user edited the diagram in the browser since then. You do NOT need to call get_diagram before every edit: a rejected call changes nothing and includes the current XML of the page, so you can rebuild your operations and retry.

Call get_diagram first only when you don't know the current diagram content (cell IDs, structure) — e.g. the diagram wasn't created in this conversation, or you're unsure your memory of it is accurate.

Multi-page targeting:

  • page_id / page_name / page_index are optional; when all omitted, the FIRST page is targeted

  • Use list_pages to discover what pages exist

Operations:

  • add: Add a new cell. Provide cell_id (new unique id within the page) and new_xml. One cell per operation.

  • update: Replace an existing cell by its id. Provide cell_id and complete new_xml.

  • delete: Remove a cell by its id. Only cell_id is needed. Its children and connected edges are deleted too, so give only a container's id.

For add/update, new_xml is the complete mxCell in the compact form (a shape with x, y, w, h; an edge with source and target). No XML comments. Every " inside new_xml must be escaped as " in the JSON.

Example - Add a rectangle on the default (first) page: {"operations": [{"operation": "add", "cell_id": "rect-1", "new_xml": "<mxCell id="rect-1" value="Hello" style="rounded=1;" x="100" y="100" w="120" h="60"/>"}]}

Example - Delete a cell on the default page: {"operations": [{"operation": "delete", "cell_id": "rect-1"}]}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
page_idNoTarget a page by its id (as returned by list_pages or add_page). Wins over page_name and page_index when multiple are set.
page_nameNoTarget a page by its display name (e.g. "CNN"). Used only when page_id is not set.
operationsYesArray of operations to apply
page_indexNoTarget a page by its 0-based tab index. Used only when page_id and page_name are not set.
screenshotNoAlso return a PNG of the result so you can check it for overlaps and edges crossing shapes. Needs the preview tab open and in front; adds 2 to 10 s. Default: the DRAWIO_AUTO_SCREENSHOT environment variable.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations provide only openWorldHint=false, so the description carries the burden and does so well: all-or-nothing transaction semantics, freshness detection against browser edits, the fact that a rejected call returns the current page XML, and the 2-10s latency plus preview-tab requirement for screenshots.

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

Conciseness5/5

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

Front-loaded with the one-line purpose, then organized into short labeled blocks (all-or-nothing, freshness, multi-page, operations, examples). The length is justified by the semantic complexity of batch cell editing, and the JSON examples remove ambiguity without padding.

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?

No output schema exists, and the description compensates by explaining the failure return (current XML for retry) and the optional screenshot output. For a mutation tool with openWorldHint=false, an agent has everything needed to call and recover from failures.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents all five parameters including page precedence. The description still adds value beyond it: add requires one cell per operation, delete cascades to children and edges, and new_xml requires escaped quotes and compact mxCell form.

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+resource ('Edit a specific page in the current diagram') and names the exact operations (update/add/delete cells). It is clearly separable from read-side siblings like get_diagram, list_pages, and screenshot_diagram.

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 get_diagram is needed ('only when you don't know the current diagram content') and when it is NOT needed ('You do NOT need to call get_diagram before every edit'), with the reasoning (rejected calls change nothing). It also routes multi-page discovery to list_pages.

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

Deploy Server

Other Tools