A2UI Atomic Catalog

diagram_studio

Read-onlyIdempotent

Draw a diagram in-chat with the full Diagram Studio interface (MCP Apps hosts only; it opens fullscreen where the host allows it). YOU write the diagram; nothing is generated server-side and nothing is stored. PREFER graph: give vertices (id, label, type start|process|decision|database|cloud|end) and edges (source, target, optional label). The person then gets the whole studio: they can switch the same graph between Mermaid, D2, PlantUML and draw.io, flip its direction, zoom, copy the code, open it in the real draw.io editor with one click, and edit nodes and connections themselves (their edits come back to you). Use syntax with source instead only for diagrams a flow graph cannot express, drawn exactly as written: "mermaid" for sequence, class, state, ER, gantt and mind maps; "d2" for architecture diagrams with containers and nested boxes. Give exactly one of graph or syntax with source. Keep diagrams compact (the input schema states the limits). If the tool or the view reports a problem, fix it and call this tool again. On a host without MCP Apps support the diagram comes back as text.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "diagram_studio"
  }
}

Input Schema

Name	Required	Description
`graph`	No	The diagram as a graph (preferred).
`theme`	No	Colours for the draw.io output. Default modern_indigo.
`title`	No	Optional heading shown above the diagram.
`format`	No	Which format the view opens on. Default mermaid; mermaid and d2 draw a picture.
`source`	No	Only with `syntax`: a complete diagram, drawn as written.
`syntax`	No	Only with `source`: the language of that source.
`direction`	No	Graph layout direction: TB (top to bottom, default) or LR.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnlyHint/idempotentHint, but the description adds substantial context beyond them: no server-side generation, no storage, fullscreen/MCP-Apps host dependency, text fallback on unsupported hosts, the user's manual edits flowing back to the agent, and guidance to re-call on error.

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?

Front-loaded with purpose, then the graph-vs-syntax preference, then user-facing outcomes. Dense and mostly waste-free, though the enumeration of vertex and edge fields duplicates the schema and the 'give exactly one of graph or syntax' rule is stated twice in spirit (preference paragraph and constraint sentence).

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 7-parameter tool with nested objects and no output schema, the description covers the input contract (mutual exclusivity, defaults, compactness limits by reference), the host-dependent output behavior, and the interactive session lifecycle including edits returning to the agent. Nothing an agent needs in order to call it correctly 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, and the description goes somewhat further by mapping `syntax` values to diagram families that a flow graph cannot express and noting that 'mermaid and d2 draw a picture' in `format`. It partly restates the vertex/edge fields already documented in the schema, so it is additive rather than fully compensatory.

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 ('Draw a diagram in-chat with the full Diagram Studio interface') and immediately scopes the agent's role: 'YOU write the diagram; nothing is generated server-side and nothing is stored.' It also distinguishes itself behaviorally from a plain render tool by describing the interactive studio the user receives.

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 routes between the two input modes: 'PREFER `graph`' with an enumeration of what graph accepts, versus 'Use `syntax` with `source` instead only for diagrams a flow graph cannot express', plus per-language picking advice (mermaid for sequence/class/state/ER/gantt/mind maps; d2 for nested-container architecture). It also states the mutual-exclusion rule and the retry loop on failure.

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

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.