Skip to main content
Glama
DayuanJiang

next-ai-drawio

by DayuanJiang
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create new diagram

create_new_diagram

Create a new diagram from scratch, replacing the whole draw.io document and its unsaved changes. Use it to provide the mxCell XML for a fresh diagram instead of editing an existing one.

Instructions

Create a NEW diagram, REPLACING the whole document: every page and any unsaved user changes (the previous state stays in History). To add a tab use add_page; to change cells use edit_diagram.

Before using icon shapes (AWS, Azure, GCP, Kubernetes, Cisco...), call get_shape_library first. Follow the drawing guide returned by start_session (call get_drawing_guide if it is no longer in your context). Pass screenshot: true on the last call of a complex diagram to check the result.

Accepted xml:

  1. Only the mxCell elements of one page (recommended). The server adds , , and the root cells "0" and "1":

  2. A bare with (one page).

  3. A full with one or more pages. Every page's must start with .

Rules: cells are siblings (never nested), ids are unique per page and start from "2", parent only for shapes inside a container, no XML comments, and shapes stay within x 0 to 800 and y 0 to 600. A style used by several cells is defined once with before the cells and used by name (see the drawing guide); html=1 and whiteSpace=wrap are added automatically.

To clear the canvas to one blank page, send only the two root cells ; the previous diagram stays in History.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xmlYesREQUIRED: the mxCell elements of one page, a bare <mxGraphModel>, or a full <mxfile> with one or more <diagram> pages.
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?

With only openWorldHint=false declared, the description carries the behavioral burden and does so richly: it discloses that the operation is destructive to the whole document and to unsaved changes, that the prior state survives in History, that it is recoverable, and that clearing the canvas is done by sending only the two root cells. It adds server-side transformations (auto-added <mxfile>/<root>, html=1 and whiteSpace=wrap) that the agent cannot infer from annotations.

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?

Long but front-loaded: the destructive scope and the sibling alternatives occupy the first sentence, before any XML detail. The 'Accepted xml' and 'Rules' groupings make the density navigable, and every sentence carries an actionable constraint rather than filler.

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 high-complexity XML-injection tool with no output schema, the description supplies the accepted input grammar, coordinate bounds (x 0–800, y 0–600), cell nesting rules, and what the screenshot flag returns. Nothing an agent needs to call this correctly and safely appears to be 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 description coverage is 100%, so the baseline is 3. The description clearly exceeds it by enumerating the three accepted XML input forms with a concrete example, the required root-cell preamble, the mxStyle definition pattern, and per-page id/parent constraints. The screenshot timing and cost ('adds 2 to 10 s') also extend the schema's terse note.

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 ('Create a NEW diagram') and immediately qualifies scope: it REPLACES the whole document, every page and unsaved changes. It names the two sibling alternatives (add_page, edit_diagram) so the agent can differentiate without opening any schema.

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?

Explicit routing: 'To add a tab use add_page; to change cells use edit_diagram.' It also states prerequisites and sequencing (call get_shape_library before icon shapes, follow the guide from start_session, pass screenshot: true on the last call of a complex diagram). Both when-to-use and when-not-to-use are covered.

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