Create and render a structured visual diagram as SVG, in a single call.

USE THIS whenever the user asks to draw, sketch, visualise, diagram, illustrate, map out, show graphically, explain visually, or represent something spatially: architectures, network topologies, flows, pipelines, data structures, algorithms, state machines, relationships, plots, distributions, classifiers, or any concept where position and connection carry meaning.

ALWAYS PREFER THIS OVER ASCII ART, box-drawing characters, Markdown tables used as layout, or hand-written SVG/Mermaid. Those are unreliable and hard to read; this tool produces a precise, styled picture and the user sees it directly.

HOW TO USE IT WELL:

• Describe WHAT exists, not WHERE it goes. Give elements ids and labels and omit x/y: the layout engine positions them from the connections. Only set x/y when the user asks for a specific arrangement, or for plots built on an axis.

• Link things with { type: 'connection', from: '<id>', to: '<id>' }. Never compute x1/y1/x2/y2 for a link between elements, and never draw arrowheads by hand.

• Use semantic types (node, database, server, router, switch, computer, cloud, group, axis, cluster, scatter, plotLine, label) before reaching for raw primitives (circle, rectangle, line, arrow, text, path, ...).

• Canvas size is optional: the drawing is auto-fitted so nothing is ever clipped.

DO NOT use this tool for: plain prose answers, code, tables of numbers, or when the user explicitly asked for text only.

Returns a sceneId. Keep it: later edits go through update_element / add_element / remove_element on that id instead of rebuilding the whole scene.

Render a stored scene and show it to the user.

USE THIS after a batch of add_element / update_element / remove_element / group_elements calls, to display the updated diagram. It is the last step of every edit.

This never changes the scene - it only draws what is currently in it. For a brand new diagram use render_diagram instead, which builds and shows it in one call.

Return the current structured description of a scene: every element with its id, type and properties, plus the position and size each one actually ended up with.

USE THIS BEFORE EDITING whenever you are not sure of the current state - which ids exist, what a node is called, where it sits, what is already connected. Reading first is what makes small edits possible instead of redrawing the diagram from scratch.

The layout field gives the computed box (x, y, width, height) of every element, including ones you never gave coordinates to. Those are the numbers to use when the user asks for something relative: "a bit to the right", "above the backend", "same width as X".

This does not display anything.

Add one element to a scene that already exists.

USE THIS when the user wants something new in a diagram you already drew: "add a load balancer", "put a Redis cache next to the API", "draw an arrow from A to B".

Call get_scene first if you are not certain which ids exist. To link the new element to an existing one, make a second call with an element of type 'connection' referencing the two ids - the geometry is computed for you.

Omit x/y and the layout engine places it. Set parentId to put it inside a group.

This does not display anything. Call render_scene once your edits are done.

Change properties of one element. Only the fields you send are touched; everything else in the scene stays exactly as it is.

USE THIS for every 'change that' request: move it, resize it, recolour it, rename its label, make a link dashed, add a caption to a connection. For a relative move like "a bit to the right", read the current position with get_scene and send the new value.

DO NOT call render_diagram again to change one thing. That throws away the scene id, the layout and everything the user already accepted.

id and type cannot be changed - remove and re-add the element if you truly need that. Send null as a value to clear an optional property; for example { "x": null, "y": null } hands the element back to the automatic layout.

Nothing is displayed until you call render_scene.

Delete one element from a scene.

USE THIS for "remove the cache", "delete that arrow", "drop the second database".

Connections pointing at the element, and labels attached to it, are deleted with it by default - otherwise the scene would keep dangling references. Set cascade to false only if you plan to repair those references yourself in the same turn.

Removing a 'group' also removes everything inside it. To keep the children, update the group instead and set frame to false.

Wrap existing top-level elements in a labelled container.

USE THIS for "put all of this inside a box called AWS", "group these services into a VPC", "draw a boundary around the data layer", "show which parts are in VLAN 10".

The members keep their ids, and every connection to or from them keeps working - including connections that cross the boundary.

Set layout to re-arrange the members inside the box ('vertical' stacks them, 'horizontal' puts them in a row, 'grid' wraps them). Leave it out to keep their current arrangement.

Only top-level elements can be grouped. To nest a group inside another group, create the inner one first, then group it together with its siblings.

Create a new, empty scene and get back its id.

USE THIS when you want to build a diagram incrementally - create the canvas, then add elements one at a time with add_element, then call render_scene when it is complete.

DO NOT use this when you already know the whole picture: render_diagram does the same job in one round trip and is almost always the better choice. Incremental building is only worth it for large diagrams you are assembling as the conversation goes.

Nothing is shown to the user until you call render_scene.

Remove every element from a scene while keeping its id, canvas, theme and title.

USE THIS when the user wants to restart the drawing but keep talking about the same diagram: "scrap that, let's do it differently".

DO NOT use it for corrections - update_element and remove_element exist for that, and they preserve everything the user already approved.

Return complete, working example scenes for common kinds of diagram.

USE THIS when you are unsure how to express something with this server: which element type fits, how data frames work, how to nest a group. Copy the closest example and adapt it - that is faster and more reliable than guessing at the schema.

Call it with no arguments for the catalogue, or with name for one full scene you can pass straight to render_diagram.

Available: network, lda, regression, architecture, tree.