Skip to main content
Glama

Edit diagram

edit_diagram

Apply ID-based add, update, and delete operations to a specific diagram page, targeting pages by ID, name, or index; failed operations apply nothing and report every error.

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 (inside its wrapper when it has custom data, see the drawing guide) 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

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?

The description discloses all-or-nothing transaction behavior, optimistic-concurrency freshness checks, retry semantics, and cascading deletes of children and connected edges. These are substantive behavioral details beyond the single openWorldHint annotation.

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?

The description is front-loaded with purpose and critical behavioral rules, then uses clear sections for multi-page targeting, operations, and examples. Despite its length, every section earns its place for a complex mutation tool.

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?

For a complex edit tool with no output schema, it covers safety, failure modes, retry behavior, page targeting, operation semantics, and XML formatting. Nothing essential for correct invocation is missing.

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 baseline is 3, but the description adds meaningful semantics: page targeting precedence when multiple selectors are omitted, per-operation requirements for cell_id/new_xml, unique cell IDs, and XML escaping. It does not explain the screenshot parameter, but the schema already does.

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?

The description states a specific verb and resource: editing a page in the current diagram via ID-based operations. It clearly distinguishes itself from read-only siblings like get_diagram and page-management siblings like add_page/list_pages.

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?

It gives explicit guidance on when not to call get_diagram first, when to call it, and how to discover pages via list_pages. The freshness/retry paragraph tells the agent exactly what to do after a rejected call.

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