Skip to main content
Glama

Edit a diagram

apply_ops
Destructive

Applies ops to a diagram as one atomic change (revert_change can revert it). Ids starting with "$" are temporary: the server assigns real ids and returns idMap. New records with caller-chosen ids make a retry after a lost response safe: a repeated batch then fails with id_taken and writes nothing (get_canvas shows what was written). References to temporary ids (parentId, source/target, props.assetId and "asset:$id" strings) are resolved at the end of the list, but ops that change or remove a record need it to exist at that point (added earlier in the list). A *.set or *.remove whose target is not there is dropped (effects.dropped, warning missing_target). If nothing changes (every op dropped, or the values were already there) nothing is written: applied false, noop true, reason (unchanged, dropped or skipped), seq unchanged. dryRun checks the batch, including embedded images, custom shapes and infographic data, against the current state without writing (isError true when it would be rejected; wouldCreate counts the new records); with dryRun, preview "light" or "dark" also returns a PNG of the custom shapes, drawings and infographic blocks (or the whole poster, as export_diagram draws it) the batch touches. People may edit at the same time; each field keeps the last write. baseSeq (the seq read with get_canvas or returned by the last write) reports which fields others changed since then (effects.conflicts, also for records a node.remove deletes with it; warning concurrent_edit); onConflict "skip" keeps their values. Warning node_being_edited means a person is typing in that node right now. A core.vector node takes one source in props: svg, elements, fromIcon, libraryRef or fromImage (read_me topic "shapes"). A palette key from search_node_types (such as infographic.chart::donut) works as the node type; chart data can be sent as data.rows, data.csv or Chart.js labels and datasets (read_me topic "infographics"). Returns applied, seq, batchId, idMap, effects (dropped / cascaded / pruned…, lists cut to the first 20 with a Count), bounds of the touched nodes, images (embedded images the server re-encoded, if any), vectors (converted shapes), infographics (converted variants and data, applied themes) and warnings: layout lint plus props that have no effect (unknown_prop with a suggestion, invalid_prop_value with the allowed values, unknown_type, icon_not_found with close icon names); the change is applied anyway. Edge style and animation keys are in read_me topic "style". status (≤ 80 characters) is shown to people next to your cursor.

Input Schema

NameRequiredDescriptionDefault
opsYes
dryRunNo
statusNo
baseSeqNoThe seq you last read (get_canvas or your previous write). Fields others changed after it are reported in effects.conflicts.
previewNoWith dryRun: also render a PNG of the custom shapes, drawings and infographic blocks this batch touches (a whole poster when the batch changes one).
diagramIdYesDiagram id (from list_diagrams or create_diagram).
onConflictNoWith baseSeq: "overwrite" (default) writes your values anyway; "skip" leaves fields others changed since baseSeq as they are.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes far beyond the annotations (destructiveHint true, idempotentHint false): it discloses atomicity, revertibility via revert_change, temporary-id resolution order, dropped-op behavior with warning codes (missing_target), no-op short-circuit semantics (applied false, noop true), concurrency conflict reporting, and a detailed warning taxonomy. This is exactly the destructive-write context an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentence is front-loaded and strong, but the rest is one very long unbroken paragraph of dense parentheticals, making it hard to scan or retrieve a specific rule. Every clause is substantive, but the lack of structure costs readability.

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?

No output schema exists, yet the description enumerates the return shape (applied, seq, batchId, idMap, effects, bounds, images, vectors, infographics, warnings). Combined with the operation semantics and edge cases, an agent has everything needed to call and interpret it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 57%, and the description compensates fully: baseSeq means 'the seq read with get_canvas', onConflict 'skip' keeps other people's values, dryRun validates including embedded images, preview returns a PNG of touched blocks, and status is shown next to the cursor. Each parameter gains meaning the schema alone does not supply.

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?

Opens with a specific verb and resource: 'Applies ops to a diagram as one atomic change'. The atomic-batch framing plus the revert_change cross-reference clearly separates it from sibling editors like compose_diagram and single-purpose tools like add_image.

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?

Gives concrete usage conditions: dryRun to validate against current state, baseSeq plus onConflict to handle concurrent edits, and caller-chosen ids for safe retries after a lost response. It does not explicitly say when to prefer this batch tool over alternatives such as compose_diagram, which keeps it short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.