A2UI Atomic Catalog

drawio_open

Idempotent

Open a diagram you wrote in draw.io (diagrams.net). YOU write the diagram as mxGraph XML, the format draw.io reads; this tool checks it, and returns a link that opens it in the draw.io editor for the person, plus a .drawio file to download (kept for one hour). Nothing is drawn or laid out for you, so give every shape its x, y, width and height. The XML must be uncompressed and shaped like this (ids unique, every shape parent="1", edges name source and target ids): If the check finds problems it lists each one with the cell id and the fix; correct the XML and call again. Limits: 200 KB of XML and 500 cells. For AWS and Google Cloud diagrams the check also looks at missing labels, overlaps, text that does not fit, contrast and placement (for example an instance outside a subnet); each finding names the cell. These are vendor-style conventions drawn from draw.io's own libraries, not an official checker from AWS or Google. Labels may use simple HTML (set html=1 in the style); scripts, iframes, event handlers and javascript: links are refused. The diagram travels in the link's fragment, which is never sent to a server.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "xml": "<xml>"
    },
    "name": "drawio_open"
  }
}

Input Schema

Name	Required	Description
`xml`	Yes	The mxGraph XML: an <mxGraphModel> (or an uncompressed <mxfile> holding one).
`host`	No	diagrams (default): open in app.diagrams.net. self: open in the editor hosted on a2uicatalog.ai, so the diagram never leaves this domain.
`style`	No	Style pack. auto (default): if the diagram names AWS or Google Cloud services, check it against that vendor's conventions and report findings. aws or gcp: force a pack. none: no style checks. Name a service in the label ("Lambda", "Cloud Run") or set a service="..." attribute on an <object> wrapper.
`title`	No	Optional name for the downloaded file, for example "checkout-flow".
`polish`	No	Visual finish using draw.io's own effects, layered on your styles without overriding any key you set: clean (default, nothing added), soft (rounded corners, gentle shadow, subtle gradient), glass (soft plus a glass shine), sketch (hand-drawn outlines). Text, images, icons, containers and shapes restyled by a vendor pack are left alone.
`animate`	No	Add moving dashes along the connectors (draw.io flow animation). Shows in the draw.io editor; default false.
`restyle`	No	Rewrite recognised services to draw.io's own icon styles and recognised groups (AWS: VPC, subnets, Region; Google Cloud: zones) to their group styles. AWS has icons for 350 services; for Google Cloud draw.io has 19 core products as stencils, and other Google services keep your style. Default false: the diagram is passed through as you wrote it and only reported on.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations it discloses the outputs (editor link plus a downloadable .drawio file kept only one hour), the validation feedback format, the two size limits, the security refusals (scripts, iframes, event handlers, javascript: links) and the privacy property that the diagram lives in the URL fragment and is never sent to a server. It also scopes the AWS/GCP findings as vendor-style conventions rather than an official checker, which prevents over-trusting the warnings.

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?

Purpose and the behaviour contract are front-loaded, then the workflow, limits and safety notes follow in a sensible order. The inline mxGraphModel sample is bulky but functions as a template that removes ambiguity, so it earns its space; a slightly tighter separation of the example from the prose would help.

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?

With no output schema, the description carries the burden of describing return values and does so precisely: a link, a downloadable file with a one-hour lifetime, and per-cell findings. For a seven-parameter tool with enums, the optional parameters (host, style, polish, animate, restyle) are each explained well enough to choose correctly.

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 real meaning beyond it for the dominant parameter by specifying the required XML structure ('ids unique, every shape parent="1", edges name source and target ids') and by noting that labels may use simple HTML with html=1. It also flags the trigger condition for style checks (a named service or a service attribute on an object wrapper).

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 first two sentences give a specific verb and resource (open a draw.io diagram) and immediately disambiguate the division of labour: 'YOU write the diagram as mxGraph XML... this tool checks it, and returns a link.' An agent knows it is a validate-and-open tool, not a drawing or layout tool, which separates it from render/build siblings.

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

Usage Guidelines4/5

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

Usage context is clear and the iterate-on-failure loop is spelled out ('If the check finds problems it lists each one with the cell id and the fix; correct the XML and call again'), along with hard limits of 200 KB and 500 cells. It stops short of naming an alternative tool or explicitly stating when not to use it.

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

All A2UI Atomic Catalog tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.