Skip to main content
Glama

Server Details

Whiteboard where any shape opens into another canvas. Claude Code and Codex plugins render plans on it.

Ownership verified
Status
Healthy
Uptime
44.3% over 42 days
OAuth
Works in Glama
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.5/5.0

Scored across 42 tools

Disambiguation3/5

Most tools have clear resource+action boundaries and extensive descriptions help. However, there is notable overlap between element_create and batch_create_elements, the three node_create variants, document_create/folder_create/document_update folder behavior, and element_update vs table_update_cell. These overlaps make some selections ambiguous even with guidance.

Naming Consistency4/5

Almost all tools use snake_case and a predictable resource_action pattern (document_list, element_create, folder_delete, template_get). Minor deviations appear in batch_create_elements, table_append_row, and the singular/plural mix in comment_create vs comments_list_unresolved, but the set remains readable.

Tool Count2/5

With 42 tools, the surface is very large for a whiteboard/canvas server and exceeds the usual well-scoped range. Many operations are granular variants or could be consolidated (single vs batch element/node creation, separate listener-key tools, table helpers), making the set feel heavy.

Completeness4/5

Coverage is broad: documents, nodes, elements, batches, tables, checklists, comments, folders, templates, sharing, account, pictures, and agent listener keys are all represented. Minor gaps remain, such as no unshare/revoke access tool and no resolved-comment listing, but core lifecycle workflows are supported.

Available Tools

42 tools
account_getWhich accountA
Read-onlyIdempotent
Inspect

Which Unpaged account this connection is signed in to: its email, user id, plan and whether it is an admin. Call it when a whiteboard the user expects is missing from document_list, or before creating something, to be sure it lands in the account they are looking at — two connections to Unpaged can be signed in to different accounts.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and not open-world. The description adds a non-obvious behavioral fact the annotations cannot convey: two connections can be signed in to different accounts, so identity is per-connection, not global. It also lists the returned fields despite having no output schema. Minor gap: no mention of any auth or failure behavior.

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?

Roughly two sentences, front-loaded with what the tool returns, followed by when to call it. Every clause carries information — no restatement of the title or name.

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 parameters, no output schema and full annotation coverage, the description covers the only remaining unknowns: what identity information comes back and why an agent would need it mid-task. 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the schema is trivially complete at 100% coverage. Baseline 4 for a parameterless tool.

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 description states a specific resource and what it resolves: which Unpaged account this connection is signed in to, plus the returned fields (email, user id, plan, admin status). It is unambiguous and distinguishes itself from the rest of the sibling list, which operates on documents, nodes, elements and folders rather than the connection's identity.

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?

It gives two explicit triggers (when an expected whiteboard is missing from document_list, and before creating something) and the reason behind each. The alternative — assuming a single global account — is implicitly ruled out by the two-connections note.

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

agent_listener_key_createArm @agent push for a whiteboardInspect

Receive @agent notifications for ONE whiteboard. Mint a receive-only listener key bound to its documentId after proving you can open the whiteboard and read its comments. Installed plugins use pollUrl with Authorization: Bearer and short HTTP polls every 30 seconds, or every 60 seconds after an idle hour (a successful response's Unpaged-Poll-Interval and Unpaged-Idle-Poll-Interval headers replace both, in seconds); return to the shorter interval after a new event. Responses contain {events:[...],nextCursor} and must be deduplicated by id. Continue the bounded scan with the returned cursor query parameter; null restarts it. The key is shown ONCE: store it locally, never in a URL. HTTP 401 means invalid, revoked or expired (unused for 7 days), 409 means a newer key took over this whiteboard (STOP), and 429/503/network failures retry the same key. One key hears one whiteboard; different whiteboards work independently. At 20 live keys, a new key replaces the one unused the longest if nobody used it in the last 10 minutes, and is refused otherwise. Revoke with agent_listener_key_revoke.

ParametersJSON Schema
NameRequiredDescriptionDefault
labelNoWhere this key lives, for the key list — e.g. 'claude-code on my-laptop' (optional)
documentIdYesThe whiteboard this key listens to — the documentId you just created or were asked to watch
agent_listener_key_revokeRevoke listener keyA
DestructiveIdempotent
Inspect

Revoke one of your listener keys. Polls authenticated after revocation are refused with HTTP 401, so the listener stops on its next poll without reminting automatically.

ParametersJSON Schema
NameRequiredDescriptionDefault
keyIdYeskeyId from agent_listener_keys_list

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already mark this as destructive and idempotent. The description adds meaningful behavioral context beyond annotations: revoked keys cause HTTP 401 on subsequent polls, and the listener stops without auto-reminting. This is useful and does not contradict any annotation.

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?

The description is two concise sentences with no filler. The primary action is front-loaded, and the second sentence explains the runtime effect that matters for an agent deciding whether to invoke the tool.

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 one-parameter tool with no output schema, the description is complete: it states what is revoked, where the key ID comes from indirectly via the schema, and what happens after revocation. An agent has enough information to call it correctly.

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

Parameters3/5

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

There is one parameter with 100% schema description coverage, specifying that keyId comes from agent_listener_keys_list. The description adds little beyond the schema, which is acceptable since the schema already carries the semantic meaning.

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 description states a specific verb ('Revoke') and resource ('listener keys'), and the title reinforces the same. It is clearly distinguishable from siblings like agent_listener_key_create and agent_listener_keys_list without needing to inspect them.

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?

The description gives clear context for use: revoking a listener key stops the listener on its next poll and prevents automatic reminting. It does not explicitly name alternative tools or list when not to use it, but the action and consequence are clear enough for an agent to select it appropriately.

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

agent_listener_keys_listList listener keysA
Read-onlyIdempotent
Inspect

List your live listener keys (id, label, whiteboard, created, last seen) — never the key material. A key with documentId null predates per-whiteboard keys: the polling endpoint refuses it, revoke it. Keys unused for 7 days have expired and are not listed.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior5/5

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

Adds substantial behavior beyond the readOnly/idempotent annotations: keys with documentId null are refused by the polling endpoint and should be revoked, and keys unused 7 days have expired and are excluded from results. These are non-obvious filtering and lifecycle behaviors an agent cannot infer from annotations alone.

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?

Two dense sentences front-load the core purpose and the returned fields, then add lifecycle rules. Slightly information-dense but every clause earns its place; no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-param read tool with no output schema, the description supplies the essential context: what fields are returned, what's excluded (key material, expired keys), and how to handle legacy keys. It does not cover pagination or sorting behavior, a minor gap.

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?

The tool takes no parameters, so there is nothing to document, and the description correctly focuses on output semantics (the listed fields) instead. No penalty applies since zero-param tools have a baseline of 4.

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 (List) and resource (listener keys), and enumerates the returned fields (id, label, whiteboard, created, last seen). It also explicitly distinguishes itself from key-material exposure and from the create/revoke 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?

Gives implicit usage context (viewing live listener keys) and a routing hint about expired/legacy keys, but does not explicitly name or defer to sibling tools like agent_listener_key_create or agent_listener_key_revoke for management actions.

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

batch_create_elementsCreate elements (batch)Inspect

Draw many shapes on a canvas at once — rectangles and other shapes, connectors, tables, checklists, notes, text — the fast, atomic way to lay out a diagram or a plan. All elements are validated before any are created. The reply lists each new element's id, type and revision token in input order. Supported types: rectangle, text, connector, triangle, diamond, hexagon, ellipse, line, bezier-curve, block-arrow, freehand, table, checklist, chart, uml-class, uml-interface, uml-component, uml-package, uml-artifact, uml-note.

ParametersJSON Schema
NameRequiredDescriptionDefault
nodeIdYesParent node ID
elementsYesArray of element objects, each with 'type' and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow; a circle is an ellipse with equal width and height): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex, both REQUIRED then): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). A text element sizes itself: leave width and height out, and the width is measured from the text, or is maxWidth when you set one. The wrap width is stored and read back as frameWidth; an update takes it by either name, maxWidth or frameWidth, and the element's width follows it. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor (optional, default #1a1a1a), strokeWidth (optional, default 3), opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A fill field on a stroke that is not closed is refused. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot), opacity (0 to 1: the line and its markers together). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle, opacity (0 to 1). Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20, default 3), cols (1..10, default 3), cells (optional string[][] matching rows×cols; without it the table is empty), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). width and height size the whole table. A read returns each row of cells as { values: [...] }. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; a long item or title wraps onto more lines and its row grows taller, so give the checklist enough height for every row: rows past the bottom are hidden), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. "$", "%"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID).
documentIdYesParent document ID
returnElementsNoSet true to get every created element back in full (stored form). By default the reply is short: each element's id, type (the same value reads return as elementType) and revision token, in input order.
batch_delete_elementsDelete elements (batch)A
DestructiveIdempotent
Inspect

Delete multiple elements atomically

ParametersJSON Schema
NameRequiredDescriptionDefault
nodeIdYesParent node ID
documentIdYesParent document ID
elementIdsYesElement IDs to delete
expectedRevisionsNoOptional map of elementId to its `revision` token from your read. Any provided token that is stale aborts the whole batch with CONFLICT.

TDQS

A3.8/5.0
Behavior3/5

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

The annotations already carry destructiveHint=true, readOnlyHint=false, and idempotentHint=true, so the description's incremental behavioral contribution is mainly the atomicity guarantee. It does not disclose permanence/irreversibility or return behavior, but 'atomically' is a useful addition and does not contradict any annotation.

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?

The description is a single five-word sentence with no filler, repetition, or irrelevant detail. It front-loads the verb, object, and key behavioral qualifier effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich schema (100% coverage), the annotations (destructive, idempotent, read-only), and the atomicity qualifier, an agent has enough to select and invoke the tool correctly. The only notable omission is explicit sibling-contrast guidance, but that is more of a usage-guideline concern than a completeness gap for a straightforward batch delete.

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

Parameters3/5

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

Schema description coverage is 100%, with documentId, nodeId, elementIds, and expectedRevisions all documented, including the CONFLICT abort behavior for stale revision tokens. The description itself adds no parameter-level detail, but the schema fully carries that burden, so the baseline 3 applies.

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 description states a specific verb ('delete'), a resource ('multiple elements'), and a defining qualifier ('atomically'), making the tool's scope immediately clear. It distinguishes itself from single-delete siblings like element_delete and from batch_create_elements/batch_update_elements.

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

Usage Guidelines3/5

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

The phrase 'multiple elements atomically' implies the intended use case: deleting several elements in one all-or-nothing operation. However, the description never explicitly names alternatives or states when not to use this tool, leaving routing among the many sibling tools partly to inference.

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

batch_reorder_elementsChange layer orderA
DestructiveIdempotent
Inspect

Change which shapes are drawn in front of which: move one or more shapes to the front, to the back, or directly above or below another shape — slide a shadow under a figure, or uncover a label, without deleting and redrawing anything. Atomic. The moved shapes keep their own order among themselves, whatever order their ids are given in. Only the order changes, so no revision token is needed and no element's revision changes. A locked shape cannot be moved. The reply lists each moved element's id and its new zOrder (0 is the back) as of this call; a later move shifts the numbers, and element_list shows the current order.

ParametersJSON Schema
NameRequiredDescriptionDefault
nodeIdYesParent node ID
positionYesfront: in front of every other element. back: behind every other element. above: directly in front of the element named in relativeTo. below: directly behind it.
documentIdYesParent document ID
elementIdsYesIDs of the elements to move
relativeToNoID of the element the moved ones are placed next to. REQUIRED for above and below; leave it out for front and back.

TDQS

A4.6/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: atomic execution, relative order preserved among moved shapes regardless of id order, no revision token required and no revision bump, locked shapes cannot be moved, and the reply format (id + new zOrder, 0 = back). This is consistent with idempotentHint=true and destructiveHint=true.

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 the core action and scoping, then behaviors. The illustrative em-dash clause is slightly decorative, but nearly every sentence carries actionable information (atomicity, ordering, revision, locked shapes, return format).

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 still documents the return payload (moved ids and new zOrder) and warns the numbers shift on later moves. Combined with the locked-shape constraint and atomicity, an agent has everything needed to call it 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: elementIds are order-independent ('keep their own order among themselves, whatever order their ids are given in') and zOrder semantics (0 is the back) are clarified beyond the schema's position enum text.

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 (change) and resource (layer/z-order of shapes) with the exact operations available: front, back, above, below. It is clearly distinct from batch_update_elements or element_update, which mutate content rather than stacking order.

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 clear usage context ('slide a shadow under a figure, or uncover a label, without deleting and redrawing anything') and points to element_list for inspecting current order. It does not explicitly name a sibling alternative or state when not to use it, so it falls 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.

batch_update_elementsUpdate elements (batch)A
DestructiveIdempotent
Inspect

Move, restyle or rewrite many shapes at once, atomically — for restructuring a canvas after feedback.

ParametersJSON Schema
NameRequiredDescriptionDefault
nodeIdYesParent node ID
updatesYesArray of update objects, each with 'elementId' and fields to update. Geometry and link fields sit at the top level: x, y, width, height, rotation, isLink, linkTarget, locked. Everything else is a shape property and goes inside `properties` (e.g., {properties: {fillColor: "#00FF00", text: "Done"}}). A shape property outside `properties`, or a property the element's type does not have, is refused and nothing is written. Setting fillStyle 'linear' or 'radial' needs a hex fillColor and a fillColor2, sent in the same update or already stored on the shape; fillStyle 'solid' turns a gradient back into a plain fill. A read can show properties whose names start with two underscores: they are internal, leave them as they are. Per entry: expectedRevision is the element's `revision` token from the read this change is based on (every read tool returns it per element). It is REQUIRED when properties replaces a composite value (cells, items, points, text, uml attributes/methods, startEndpoint/endEndpoint, chart data/seriesColors) and optional otherwise. If the element changed since that read the write fails with a CONFLICT asking you to re-read; a composite write without the token fails with a MissingRevisionError. To change one cell, row, or item of a whiteboard a human may also be editing, prefer table_update_cell / table_append_row / checklist_toggle_item — they work on current state and need no token. Any stale or token-less composite entry aborts the WHOLE batch. Updates merge per key: omitted properties are preserved, provided ones are replaced whole. For checklists, properties.items replaces the entire item list (ids are backfilled) — omit items to keep it; table cells are likewise replaced whole and reshaped to the table's rows×cols, sent as string[][] or as the { values: [...] } rows a read returns; chart data and seriesColors are replaced whole too. For freehand strokes, properties.points replaces the local point array, and the element's width/height follow the new points on their own. A fill field needs the stroke to be closed, by the same update or already. Connector startAnchor/endAnchor may only be set to a corner/edge (corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; corner-top is the triangle apex, triangle-only); 'center' is rejected. Omit the anchor keys to leave a legacy connector's anchors untouched.
documentIdYesParent document ID

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description contributes one genuinely non-obvious trait beyond them: the operation is 'atomic', telling the agent the whole batch fails or succeeds together rather than partially applying.

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?

A single front-loaded sentence with the action first and the trigger context second; every word earns its place and nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a high-complexity batch mutation tool, but its heavy operational detail (revision requirements, conflict behavior, composite semantics) lives in the schema rather than the description. For a one-line summary paired with an extremely detailed schema that may be adequate, yet the description itself never flags the conflict/atomic-failure behavior an agent most needs at selection time.

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

Parameters3/5

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

Schema description coverage is 100% and the embedded updates description is unusually rich (revision tokens, conflicts, composite replacement, anchors). The one-line DESCRIPTION adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific set of verbs (move, restyle, rewrite) and a clear scope (many shapes at once), which implicitly separates it from the single-element element_update sibling. It does not explicitly name the alternative siblings, so the differentiation is inferred from 'batch'/'many' rather than stated.

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

Usage Guidelines3/5

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

The phrase 'for restructuring a canvas after feedback' provides an implied use context, which is more than nothing. However, the description never states when not to use this tool or names alternatives (e.g., element_update for one shape, or the table/checklist single-item tools), so an agent must infer the boundary.

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

checklist_toggle_itemToggle checklist itemA
Destructive
Inspect

Set one checklist item's checked state by its stable item id (ids ship in every element read). Omit checked to toggle. Touches nothing but that item's checked flag — safe under concurrent edits, no revision token.

ParametersJSON Schema
NameRequiredDescriptionDefault
itemIdYesStable id of the item
nodeIdYesParent node ID
checkedNoTarget state; omit to toggle the current value
elementIdYesChecklist element ID
documentIdYesParent document ID

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, it discloses that only the checked flag is touched, that it is safe under concurrent edits, and that no revision token is required. This adds meaningful behavioral context and does not contradict the destructiveHint.

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?

Three compact sentences with no filler. The primary action is front-loaded, and each clause adds useful information about usage, scope, or safety.

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 simple mutation tool with five parameters and no output schema, the description fully covers how to invoke it, what it affects, and the concurrency guarantees. Nothing essential is missing for correct selection and use.

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. The description adds value by explaining the toggle behavior when 'checked' is omitted and emphasizing that itemId is stable, which enriches the schema definitions.

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 description uses a specific verb ('Set') and resource ('one checklist item's checked state'), and clarifies that the operation is scoped by a stable item id. This clearly distinguishes it from broader element/document update tools.

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?

It gives clear operational context: use the stable item id and omit 'checked' to toggle. It doesn't explicitly name alternatives or exclusions, but the narrow scope makes the intended usage obvious.

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

comment_createCreate commentAInspect

Leave feedback on a whiteboard — a question, a review remark, a note for collaborators — as a comment thread. Pin it to an element by elementId (the pin follows the element), or to a point by giving BOTH x and y, or leave it unanchored.

ParametersJSON Schema
NameRequiredDescriptionDefault
xNoPin x (canvas coords; requires y too; used when no elementId)
yNoPin y (canvas coords; requires x too; used when no elementId)
textYesMessage text (CommonMark not rendered — plain text)
nodeIdYesNode (canvas) the thread lives on
elementIdNoPin the thread to this element
documentIdYesDocument ID

TDQS

A4.2/5.0
Behavior4/5

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

Annotations lack any safety hints (all false) and no readOnly/destructive info, so the description must carry the burden. The description adds valuable behavioral context: specifying that anchoring modes are mutually exclusive (elementId vs x/y), and that text is plain text (CommonMark not rendered). This goes beyond the schema and annotations, and importantly, the description's 'Leave feedback' implies a write operation, which aligns with the annotations' lack of readOnlyHint. No contradiction.

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?

The description is a single, well-structured sentence. It front-loads the core purpose ('Leave feedback on a whiteboard') and then clearly lays out the three anchoring options in a compact, enumerable way. No fluff or repetition; every phrase earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (6 params) and no output schema, the description covers the key usage aspects: anchoring modes and text rendering. It does not mention any prerequisites (e.g., required documentId or nodeId), but those are in the schema. For a comment-creation tool, this is sufficiently complete; the only minor gap is not explaining what a comment thread is, but that's intuitive.

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

Parameters3/5

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

The schema description coverage is 100%, so the schema already explains all parameters. The description adds a bit of extra semantic value by clarifying the anchoring logic (e.g., x and y must both be provided, and are used when no elementId), which is partially in the schema but reinforced. However, it doesn't add much beyond that, so baseline 3 is appropriate.

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 description clearly states the tool's purpose: 'Leave feedback on a whiteboard' as a comment thread. It specifies the resource (comment thread on a whiteboard), the action (create), and the possible anchoring modes (element, point, unanchored), which distinguishes it from sibling tools like comment_reply, comment_resolve, and comment_reopen.

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?

The description provides clear context on how to use the tool: when to pin to an element via elementId, when to pin to a point (provide both x and y), and when to leave unanchored. It does not explicitly mention when not to use it versus alternatives like comment_reply, but the context implies that this is for new threads, not replies. Slight gap on explicit exclusions.

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

comment_reopenReopen commentA
Destructive
Inspect

Reopen a resolved comment thread when the feedback was not actually addressed.

ParametersJSON Schema
NameRequiredDescriptionDefault
threadIdYesThread (root comment) ID
documentIdYesDocument ID

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the agent knows this is a mutating, non-idempotent operation. The description adds the semantic context that it reopens a resolved thread, which is useful. However, it doesn't disclose what happens to replies or whether the thread's resolved state is simply toggled. With annotations covering the safety profile, a 3 is appropriate.

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?

A single, focused sentence that states the action and the condition for use. No wasted words, and the key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter mutation tool with full schema coverage and annotations declaring destructive behavior, the description is nearly complete. It could mention that the thread must already be resolved, but the word 'reopen' implies this. The lack of an output schema is not a gap since the description needn't explain return values.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters (threadId and documentId) are already documented in the schema. The description doesn't add any parameter-specific meaning beyond what the schema provides. Baseline 3 is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Reopen a resolved comment thread') and the specific condition for use ('when the feedback was not actually addressed'). It distinguishes itself from comment_resolve and comment_reply by targeting resolved threads, though it doesn't explicitly name those 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?

The description implies when to use this tool: when a resolved thread's feedback was not addressed. It provides a clear context signal, but it doesn't explicitly state when not to use it or name alternatives like comment_resolve or comment_reply. The condition is specific enough to guide an agent.

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

comment_replyReply to commentAInspect

Answer someone's comment on a whiteboard — 'tell Maria I moved the step' — or report what you changed on the whiteboard. Needs the whiteboard's id and the thread's id: document_list, then comments_list_unresolved, then this. Replying is the end of a sweep: leave the thread open for the human to resolve.

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesReply text
threadIdYesThread (root comment) ID
documentIdYesDocument ID

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already indicate readOnlyHint=false, so a write operation is expected; the description confirms this with 'Answer' and 'report what you changed.' It adds the key behavioral outcome that the thread remains open, which is not captured by annotations. It does not mention authorization or rate limits, but given the simple write nature and existing annotation coverage, this is acceptable.

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?

The description is two concise sentences. The first front-loads the core purpose and an example, the second provides workflow and a caution. Every phrase earns its place; there is no filler or duplication of schema content.

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 tool with three required parameters fully documented in the schema, no output schema, and a simple write operation, the description covers purpose, parameter sourcing, and the end-of-sweep behavior. It tells the agent exactly what to do and what not to do, making it complete for correct invocation.

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?

With 100% schema description coverage, the baseline is 3. The description adds value by mapping documentId to "whiteboard's id" and threadId to "thread's id," and by giving an example of what goes in text ('tell Maria I moved the step'). It also explains how these parameters are obtained via prior calls, which helps the agent understand the data flow beyond the raw schema.

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 description opens with a specific verb and resource: "Answer someone's comment on a whiteboard," with a concrete example ('tell Maria I moved the step'). It differentiates from siblings like comment_create (which starts a thread) by focusing on replying to an existing thread, and distinguishes from comment_resolve by explicitly stating the thread is left open for the human to resolve.

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?

The description gives an explicit call sequence: "document_list, then comments_list_unresolved, then this." It also states when to use it ('end of a sweep') and what not to do ('leave the thread open for the human to resolve'), effectively telling the agent not to call comment_resolve afterward. This is unambiguous workflow guidance with alternatives implied.

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

comment_resolveResolve commentA
Destructive
Inspect

Mark a comment thread resolved. Resolving is normally the human's call (resolved threads disappear from the canvas) — call this only when the user explicitly asked you to resolve the thread; after acting on feedback, reply and leave the thread open instead.

ParametersJSON Schema
NameRequiredDescriptionDefault
threadIdYesThread (root comment) ID
documentIdYesDocument ID

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, and the description adds meaningful behavioral context: resolved threads disappear from the canvas, and resolving is 'normally the human's call.' This goes beyond the annotation by explaining the practical consequence and the need for explicit user consent.

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?

The description is a single compact sentence with the core action front-loaded, followed by essential usage guardrails. Every clause earns its place—no filler or redundant restatement of the tool name.

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 simple two-parameter tool with full schema coverage and clear annotations, the description covers the critical context: when to act, when not to act, and the consequence of acting. No output schema exists, but the description adequately explains the behavior an agent needs to know before calling.

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

Parameters3/5

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

Schema description coverage is 100%, so the parameters are fully documented in the schema. The description does not add parameter-level detail, which is acceptable given the complete schema coverage; it earns the baseline 3.

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 description states a specific verb and resource: 'Mark a comment thread resolved.' It also differentiates from related operations by noting resolved threads 'disappear from the canvas,' which distinguishes it from comment_reply and comment_reopen.

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?

The description gives explicit when-to-use guidance: 'call this only when the user explicitly asked you to resolve the thread.' It also provides the alternative behavior—'after acting on feedback, reply and leave the thread open instead'—which clearly routes the agent away from this tool in the common feedback-response case.

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

comments_list_unresolvedList open commentsA
Read-onlyIdempotent
Inspect

Did anyone leave feedback? List every open comment thread on a whiteboard (by its id — document_list first when the user names the whiteboard), with the element each one concerns, so you can act without re-reading the whiteboard. Threads where someone wrote @agent are addressed to you (mentionsAgent: true) — the usual sweep is: read these, act on the whiteboard, comment_reply with what you changed, and leave the thread open (resolving is the human's call). A thread whose last message has actor: 'agent' has already been swept — skip it unless a human replied after, or the thread carries reopened: true (a human reopened it after that reply) or editedAfterLastReply: true (a human revised a message after that reply): either flag means the feedback is NOT addressed. Agent messages carry the delegating human's authorName, so actor is the only reliable authorship signal.

ParametersJSON Schema
NameRequiredDescriptionDefault
documentIdYesDocument ID

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description goes far beyond that by explaining how to interpret the output: thread addressed to @agent (mentionsAgent: true), the standard sweep workflow, and the precise skip conditions (actor: 'agent' unless a human replied after, reopened: true, or editedAfterLastReply: true). It even warns that authorName is not a reliable signal because agent messages carry the delegating human's authorName. This is rich behavioral context that annotations don't provide.

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?

The description is long, but every sentence carries operational value: purpose, output contents, @agent guidance, skip logic, and an authorship caveat. The core purpose is front-loaded in the first sentence. It could be slightly improved by using bullet points for the conditional skip rules, but the current prose is an efficient packing of necessary decision criteria, not padding.

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 bears full responsibility for explaining the return semantics. It names the key fields an agent needs (mentionsAgent, actor, reopened, editedAfterLastReply), explains how to distinguish addressed vs. unaddressed threads, and provides the expected follow-up action. For a comment-list tool whose complexity lies in interpretation rather than wiring, this is complete. Nothing necessary for correct invocation or response handling 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% and the only parameter, documentId, has a basic 'Document ID' description. The tool description adds meaning by clarifying it is the whiteboard ID and instructing to call document_list first when the user names the whiteboard. This turns a bare ID field into a resolvable input and prevents the agent from misinterpreting the parameter as an arbitrary document type.

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 description opens with a direct question and then states the exact verb-resource pair: 'List every open comment thread on a whiteboard (by its id...)'. It specifies the resource (whiteboard), the scope (every open thread), and what each entry includes (the element it concerns). This distinguishes it from the comment_* siblings, which create, reply to, resolve, or reopen threads rather than list them.

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?

The description gives clear context for when to call this tool: when the user asks if anyone left feedback, or when you need to see open threads to act without re-reading the whiteboard. It also provides a sequencing hint (document_list first when the user names the whiteboard) and follow-up guidance (comment_reply after acting). It does not explicitly name an alternative or state when not to use it, but no competing list-comments sibling exists, so the implicit context is sufficient.

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

document_createCreate whiteboardAInspect

Start a new whiteboard — for a plan the team should review, an architecture to show in a design review, research to map, decisions to keep. Returns the document with rootNodeId (the first canvas to draw on, e.g. with batch_create_elements), url — the link to hand back (the /document//edit page on this server's web app) — and account, the email it was created under. Optionally file it in a library folder: folder (a name, created if missing) or folderId (an existing id, or the reserved visual-plans created on demand — race-free, the way to file plans). Filing is best-effort: if the folder cannot be resolved the document is still created unfiled and the result carries folderWarning.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleYesDocument title
folderNoFolder NAME to file the document in (created if missing). Mutually exclusive with folderId
folderIdNoFolder ID to file the document in: an existing folder, or the reserved 'visual-plans' (created on demand). Mutually exclusive with folder
canvasWidthNoRoot node canvas width (default: 1920)
canvasHeightNoRoot node canvas height (default: 1080)

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only cover the safety profile (non-read-only, non-destructive, non-idempotent, closed-world). The description adds substantially more: the exact return fields (rootNodeId, url, account), the URL form (/document/<id>/edit), and the critical failure semantics — filing is best-effort, the document is still created unfiled, and folderWarning is surfaced. That is real behavioral disclosure beyond the structured data.

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?

The purpose is front-loaded in the first clause, then returns, then optional filing — a logical order. The parenthetical use-case list is slightly indulgent, but each sentence carries operational information (return fields, filing behavior, warning flag), so little is wasted.

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?

There is no output schema, and the description compensates fully by enumerating the return fields and the folderWarning edge case. For a create tool with annotations covering safety, an agent has everything needed to invoke it and interpret the result.

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 schema already documents folder/folderId mutual exclusivity and the reserved 'visual-plans' folder. The description still adds value by explaining that folderId resolution is race-free and that this is 'the way to file plans', plus tying folderWarning to unresolved folders — meaning beyond the schema, though it does not cover canvasWidth/canvasHeight semantics.

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 description opens with a specific verb+resource ('Start a new whiteboard') and immediately names the concrete use cases (plan for review, architecture, research, decisions), which distinguishes it from siblings like document_get, document_update, or batch_create_elements. It also previews the return payload, so an agent knows exactly what it gets back.

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?

It gives clear triggering contexts (plans, design reviews, research maps, decision logs) and points to the sibling batch_create_elements as the follow-up for drawing on the returned rootNodeId. It does not state when NOT to use this tool (e.g. template_clone or document_update for existing docs), so it stops short of full routing guidance.

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

document_deleteDelete whiteboardA
DestructiveIdempotent
Inspect

Delete a document permanently

ParametersJSON Schema
NameRequiredDescriptionDefault
documentIdYesDocument ID

TDQS

A3.8/5.0
Behavior3/5

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

The description adds 'permanently,' going slightly beyond the destructiveHint=true annotation by indicating irreversibility. However, most of the destructive behavior is already declared in the annotations, so the incremental disclosure is modest. No information is given about permissions, error behavior, or cascading effects.

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?

The entire description is one short, front-loaded sentence with no filler. Every word contributes to the core meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter destructive operation with annotations covering safety, the description is largely sufficient to select and invoke the tool. It does not explain prerequisites or return values, but no output schema exists and the destructiveHint already alerts the agent. The main gap is the absence of routing guidance among the many delete siblings.

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

Parameters3/5

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

Schema description coverage is 100%: the documentId parameter is fully described in the schema. The description adds no extra parameter semantics, so it stays at the baseline for fully documented schemas.

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 description states a specific verb ('Delete'), an object ('a document'), and a qualifier ('permanently'), making the operation unambiguous. It is distinct from sibling delete tools like element_delete, folder_delete, and template_delete by targeting documents.

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

Usage Guidelines3/5

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

No alternatives or when-not-to-use guidance is provided; the description only restates the core action. With many sibling delete tools, the agent must infer that document_delete is correct based solely on the resource type. Usage is implied, not explicitly contrasted with alternatives.

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

document_getRead whiteboardA
Read-onlyIdempotent
Inspect

Read a whole whiteboard — every canvas (node) and every element on it — to understand or extend it before editing, or to answer questions about what is on it.

ParametersJSON Schema
NameRequiredDescriptionDefault
documentIdYesDocument ID

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context beyond those hints by specifying that the tool returns the entire whiteboard contents, not just metadata or a summary. This helps the agent anticipate a comprehensive read and use it as a pre-edit understanding step.

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?

One sentence packs the action, the exact scope, and the two main use cases. The core 'Read a whole whiteboard' is front-loaded, and every phrase contributes purpose; there is no filler or repetition of structured data.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, read-only, single-parameter tool, the description is largely complete: an agent knows what it retrieves, when to use it, and that it is safe. There is no output schema, so the description could have gone further by outlining the returned structure, but the phrase 'every canvas (node) and every element' covers the key expected content.

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

Parameters3/5

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

Schema coverage is 100% for the single parameter, documentId, so the schema already documents the required input. The description adds the context that the document is a whiteboard, but does not add new parameter-level semantics such as ID format or scope restrictions.

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 description starts with the verbs 'Read' and resource 'whole whiteboard', and explicitly enumerates scope: 'every canvas (node) and every element on it'. This clearly differentiates it from sibling element_get, node_get, and element_list, which are scoped to individual pieces instead of the complete document.

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?

The description gives clear contexts for use: 'to understand or extend it before editing, or to answer questions about what is on it.' It does not explicitly name alternative tools or exclusion criteria, but the scope language makes it clear when a full-document read is intended.

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

document_listList whiteboardsA
Read-onlyIdempotent
Inspect

Find the user's whiteboards by title — the first call when they mention 'the roadmap', 'the architecture diagram' or 'that plan we made': lists documents you own or that were shared with you, with ids, titles, folders and each one's url. Owned documents carry folderId and the folder's display name as folder (null when unfiled).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. Beyond that, the description discloses what comes back, that owned documents carry folderId plus the folder's display name, and that `folder` is null when unfiled — genuinely useful context the annotations do not carry.

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?

It front-loads the trigger phrase and the core action, then appends return-shape detail in a single dense sentence with an em-dash aside. Every clause earns its place, though the sentence is long enough that a reader must parse it twice.

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 present, the description carries the burden of describing results, and it does so fully — identity fields, folder metadata, and the null-unfiled case. For a zero-parameter list tool with complete annotation coverage, nothing an agent needs 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The field-level detail it gives (url, folderId, folder-as-display-name, null sentinel) describes output rather than input semantics.

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 description states a specific verb (find/list) and resource (the user's whiteboards/documents), and scopes it precisely: documents owned or shared with the caller. It is clearly distinguishable from document_get, node_list, and folder_list because it enumerates the returned fields (ids, titles, folders, url, folderId).

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?

It gives explicit intent-based triggers — 'the first call when they mention "the roadmap", "the architecture diagram" or "that plan we made"' — which tells the agent when to reach for it over a get-by-id call. It does not name a sibling alternative or state when not to use it, so it stops 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.

document_shareShare whiteboard
Idempotent
Inspect

Invite people to a whiteboard you OWN, by email — 'let Maria edit it', 'Sam can comment', 'share it with the team'. Put everyone in emails; also list in commenterEmails those who may comment and ask @agent for changes, and in editorEmails those who may edit (live coediting) and comment — someone in both gets edit. Anyone else gets view access (look only, no comments) if new, and keeps their level if already shared. Naming someone already shared in a role list sets the level of their invitation; access they also hold through a team link or an older share stays at the stronger level, and only the owner can remove it, in the Share dialog. You can only share documents you own. For a link that needs no account, use document_update with isPublic instead.

ParametersJSON Schema
NameRequiredDescriptionDefault
emailsYesEmail addresses to share with; new people listed only here get view access (look only, no comments)
documentIdYesDocument ID (must be owned by you)
editorEmailsNoSubset of `emails` who can edit (live coediting) and comment
commenterEmailsNoSubset of `emails` who can comment and ask @agent for changes, without editing
document_updateUpdate whiteboardA
DestructiveIdempotent
Inspect

Rename a whiteboard, make it PUBLIC (isPublic: true — anyone with its /share/ link on this server's web app can view it without an account: the answer to 'give me a link I can send'; find the whiteboard with document_list first), or move it to a folder: folder (a name, created if missing) or folderId (existing or reserved); pass null in either to unfile.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleNoNew title
folderNoMove to the folder with this NAME (created if missing); null unfiles. Mutually exclusive with folderId
folderIdNoMove to the folder with this ID (existing or reserved); null unfiles. Mutually exclusive with folder
isPublicNoSet document as publicly accessible via share links
documentIdYesDocument ID

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond the annotations: it discloses that isPublic:true grants anyone with the /share/<id> link access without an account, that the folder parameter creates the folder if missing, that folderId may target existing or reserved folders, and that null unfiles. These side effects are not inferable from the schema or annotations, and nothing in the description contradicts the provided hints.

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?

The description is dense but efficient, with every clause contributing to an actionable decision. The long parenthetical about public-link access and the nested folder/folderId alternatives make it a bit heavy in a single sentence, but there is no filler or redundant restatement of the title.

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?

The description covers all mutation modes, the public-sharing consequence, folder creation/reservation behavior, the unfiling mechanism, and the prerequisite lookup step. Given that the tool has no output schema and the annotations already carry safety and idempotence information, there is no meaningful operational gap for an agent to resolve.

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?

Although schema coverage is 100%, the description adds meaningful semantics: folder is a name that can be created, folderId can reference an existing or reserved folder, null unfiles, and isPublic has a concrete access-control consequence. This materially enhances the terse schema descriptions and helps an agent choose and encode parameters correctly.

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 description names a specific mutation verb and resource — updating a whiteboard — and enumerates three concrete operations: rename, make public, and move/unfile to a folder. It differentiates the tool from document_create, document_delete, and document_share by covering exactly what this update endpoint does. The reference to document_list for finding the document adds operational context without blurring the tool's identity.

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?

The description gives clear usage context: an agent should find the document with document_list first, and the public-link semantics tell it when this tool answers 'give me a link I can send.' It does not explicitly name alternative tools like document_share or state when not to use them, but the prerequisite and use-case framing make the intended selection reasonably clear.

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

element_createCreate elementInspect

Draw one shape on a canvas — a rectangle or other shape, connector, table, checklist, note or text. Supported types: rectangle, text, connector, triangle, diamond, hexagon, ellipse, line, bezier-curve, block-arrow, freehand, table, checklist, chart, uml-class, uml-interface, uml-component, uml-package, uml-artifact, uml-note.. Pass the full element object matching the type's schema (e.g., {type: "rectangle", x: 100, y: 100, width: 200, height: 100, fillColor: "#E0F2FE", strokeColor: "#0369A1"}).

ParametersJSON Schema
NameRequiredDescriptionDefault
nodeIdYesParent node ID
elementYesElement object with required 'type' field and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow; a circle is an ellipse with equal width and height): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex, both REQUIRED then): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). A text element sizes itself: leave width and height out, and the width is measured from the text, or is maxWidth when you set one. The wrap width is stored and read back as frameWidth; an update takes it by either name, maxWidth or frameWidth, and the element's width follows it. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor (optional, default #1a1a1a), strokeWidth (optional, default 3), opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A fill field on a stroke that is not closed is refused. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot), opacity (0 to 1: the line and its markers together). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle, opacity (0 to 1). Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20, default 3), cols (1..10, default 3), cells (optional string[][] matching rows×cols; without it the table is empty), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). width and height size the whole table. A read returns each row of cells as { values: [...] }. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; a long item or title wraps onto more lines and its row grows taller, so give the checklist enough height for every row: rows past the bottom are hidden), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. "$", "%"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID).
documentIdYesParent document ID
element_deleteDelete elementB
DestructiveIdempotent
Inspect

Delete an element permanently

ParametersJSON Schema
NameRequiredDescriptionDefault
nodeIdYesParent node ID
elementIdYesElement ID
documentIdYesParent document ID
expectedRevisionNoOptional: the element's `revision` token from your read. When provided, the delete fails with CONFLICT if the element changed since — re-read before deleting.

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true, so the safety profile is covered. The description adds only the word 'permanently,' which adds slight context about non-recoverability, but it does not explain the expectedRevision conflict behavior or the effect of repeated deletes.

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?

The description is a single front-loaded sentence with no filler; every word earns its place. It is appropriately sized for a simple delete operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple destructive operation, the schema and annotations cover the required parameters and safety profile, and 'permanently' communicates irreversibility. However, the missing usage context and lack of any mention of return behavior or concurrency handling leave some gaps for an agent deciding whether this is the right tool.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents all four parameters. The description itself adds no parameter-level meaning beyond what the schema already provides, which matches the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear action and resource ('Delete an element permanently'), and the word 'permanently' signals irreversibility. However, it does not distinguish this tool from sibling batch_delete_elements, so an agent must infer the single-element scope.

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

Usage Guidelines2/5

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

There is no guidance on when to use element_delete versus batch_delete_elements or element_update, and no mention of the expectedRevision concurrency option. The description provides no context for choosing this tool over alternatives.

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

element_getRead elementB
Read-onlyIdempotent
Inspect

Get an element by ID

ParametersJSON Schema
NameRequiredDescriptionDefault
nodeIdYesParent node ID
elementIdYesElement ID
documentIdYesParent document ID

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond 'get'—such as not-found behavior, auth requirements, or parent-child constraints—but it does not contradict the 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?

At six words, every word is functional and the action/object are front-loaded. There is no filler, redundancy, or unnecessary repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool, the schema plus annotations supply the required parameters and safety profile, making the tool invocable as-is. It could be more complete by explicitly noting that elementId is subordinate to nodeId/documentId or by naming sibling tools, but nothing essential is missing.

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

Parameters3/5

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

Schema description coverage is 100%, and each parameter already has a clear description ('Element ID', 'Parent node ID', 'Parent document ID'). The tool description adds nothing beyond 'by ID', so the structured schema carries the semantic load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description names a specific operation and resource ('Get ... element') and implies single-object retrieval by ID. It does not explicitly differentiate itself from siblings like element_list or node_get, so it falls just short of a 5.

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

Usage Guidelines2/5

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

No guidance is given on when to use this tool versus alternatives. With siblings such as element_list, node_get, and batch_create_elements, an agent would need to infer the appropriate choice from the name alone; no exclusions, preconditions, or alternative routing are provided.

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

element_listList elementsA
Read-onlyIdempotent
Inspect

List every shape on a canvas, each with its revision token for safe edits. The list is in layer order, back to front, and each shape carries its place in it as zOrder (0 is the back). On a canvas with many shapes, pass summary: true to get where each shape is and its token without its content.

ParametersJSON Schema
NameRequiredDescriptionDefault
nodeIdYesParent node ID
summaryNoSet true for a short listing: each element's id, type, position, size, rotation, link fields and revision token, without its properties (text, points, cells, colors). Use element_get for one element's content.
documentIdYesParent document ID

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real behavioral context beyond them: results are returned in layer order back-to-front, each element exposes zOrder (0 = back), and the revision token exists to enable safe/optimistic edits.

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?

Two tightly written sentences with zero filler. Ordering semantics come first, the summary mode second, which is the right front-loading for a listing call.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 must convey return shape, and it does: a layer-ordered list with zOrder and revision tokens. It does not describe the default per-element payload beyond those, but the summary parameter documentation fills that gap.

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%, making 3 the baseline. The description goes slightly beyond by explaining the intent behind summary: true ('where each shape is and its token without its content') and the condition that motivates it, though the detailed field list lives in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource with scope: 'List every shape on a canvas', and adds that each item carries a revision token. It never names the single-element sibling element_get, so differentiation from that tool is left implicit rather than explicit.

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

Usage Guidelines3/5

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

Usage is implied by the summary:true recommendation on canvases with many shapes, which tells the agent when to use the compact mode. However, there is no guidance on when to use this listing tool versus element_get or the batch_* siblings, and no exclusions.

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

element_updateUpdate elementB
DestructiveIdempotent
Inspect

Move, resize, restyle or rewrite one shape — its text, colours, geometry, table cells or checklist items.

ParametersJSON Schema
NameRequiredDescriptionDefault
nodeIdYesParent node ID
changesYesFields to update. Geometry and link fields sit at the top level: x, y, width, height, rotation, isLink, linkTarget, locked. Everything else is a shape property and goes inside `properties` (e.g., {properties: {fillColor: "#00FF00", text: "Done"}}). A shape property outside `properties`, or a property the element's type does not have, is refused and nothing is written. Setting fillStyle 'linear' or 'radial' needs a hex fillColor and a fillColor2, sent in the same update or already stored on the shape; fillStyle 'solid' turns a gradient back into a plain fill. A read can show properties whose names start with two underscores: they are internal, leave them as they are. Updates merge per key: omitted properties are preserved, provided ones are replaced whole. For checklists, properties.items replaces the entire item list (ids are backfilled) — omit items to keep it; table cells are likewise replaced whole and reshaped to the table's rows×cols, sent as string[][] or as the { values: [...] } rows a read returns; chart data and seriesColors are replaced whole too. For freehand strokes, properties.points replaces the local point array, and the element's width/height follow the new points on their own. A fill field needs the stroke to be closed, by the same update or already. Connector startAnchor/endAnchor may only be set to a corner/edge (corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; corner-top is the triangle apex, triangle-only); 'center' is rejected. Omit the anchor keys to leave a legacy connector's anchors untouched.
elementIdYesElement ID
documentIdYesParent document ID
expectedRevisionNoexpectedRevision is the element's `revision` token from the read this change is based on (every read tool returns it per element). It is REQUIRED when properties replaces a composite value (cells, items, points, text, uml attributes/methods, startEndpoint/endEndpoint, chart data/seriesColors) and optional otherwise. If the element changed since that read the write fails with a CONFLICT asking you to re-read; a composite write without the token fails with a MissingRevisionError. To change one cell, row, or item of a whiteboard a human may also be editing, prefer table_update_cell / table_append_row / checklist_toggle_item — they work on current state and need no token.

TDQS

B3.4/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the mutation safety profile is covered. The one-line description adds nothing beyond that — no mention of merge semantics, conflict failure, or required revision tokens (those live in the schema, not the description). For a destructive tool, the description contributes no extra behavioral context.

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?

A single front-loaded sentence with zero filler that leads with the action verbs and ends with the affected sub-objects. Nothing is redundant or padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 5-parameter, nested-object mutation tool with no output schema, the definition as a whole is complete because the schema documents merge behavior, error modes and anchor constraints in depth, and annotations cover safety. The description is thin, but the structured fields leave no critical gap for correct invocation.

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

Parameters3/5

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

Schema description coverage is 100%, and the `changes`/`expectedRevision` descriptions are exceptionally detailed (merge-per-key, composite replacement, anchor enum values, MissingRevisionError). With the schema doing all the heavy lifting, the baseline of 3 applies; the description adds no parameter meaning of its own.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives specific verbs (move, resize, restyle, rewrite) and a precise resource scope (one shape) that enumerates what is mutable: text, colours, geometry, table cells, checklist items. It implicitly separates itself from batch_update_elements via 'one shape', but never names the sibling, so differentiation is left partly to inference.

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

Usage Guidelines3/5

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

The description itself offers no when-to-use or when-not-to-use guidance. The routing that does exist (prefer table_update_cell / table_append_row / checklist_toggle_item for concurrently-edited whiteboards) is buried inside the expectedRevision parameter description rather than stated up front, so guidance is present but weakly surfaced.

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

folder_createCreate folderA
Idempotent
Inspect

Create a folder by name, or return the existing one when you already have a folder with that name (names are unique per user, case-insensitive). Prefer document_create's folder / folderId when the goal is to file a document.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesFolder display name (1–60 characters)

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare idempotentHint=true, and the description explains what that means concretely: it returns the existing folder if the name already exists. It adds uniqueness and case-insensitivity context beyond the annotation. It does not describe error handling or return format, but those are minor for a simple create/return tool.

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?

Two sentences, zero waste. The first sentence front-loads the core purpose and idempotent behavior; the second gives usage guidance. No redundant phrasing.

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 single-parameter tool with comprehensive schema and annotations, the description covers purpose, behavior, and alternative routing. The absence of an output schema is acceptable for a create/return tool; the agent knows what to expect. Nothing critical 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 name parameter is fully documented. The description adds the semantic detail that names are unique per user and case-insensitive, which is not in the schema. This enriches the meaning of the parameter beyond the basic type and length constraints.

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 description states the exact action (create a folder by name) and the idempotent behavior (return existing one). It differentiates from document_create by explicitly saying to prefer its folder parameters when filing documents. It also clarifies uniqueness per user and case-insensitivity, making the purpose unambiguous.

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?

It explicitly names document_create as the alternative and states the condition for preferring it ('when the goal is to file a document'). This gives clear routing guidance. It also implies when to use this tool: when you want a folder by name, including reusing existing ones.

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

folder_deleteDelete folderA
DestructiveIdempotent
Inspect

Delete a folder. Its documents are NOT deleted — they move to Unfiled first, then the folder record is removed. A reserved folder is recreated the next time something files into it.

ParametersJSON Schema
NameRequiredDescriptionDefault
folderIdYesFolder ID

TDQS

A4.3/5.0
Behavior5/5

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

The annotations already indicate destructive and non-read-only behavior, and the description adds substantial detail beyond them: documents are not deleted but moved to Unfiled, the folder record is removed, and reserved folders are recreated when files are filed into them. This fully discloses the real-world side effects of the operation.

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?

Three short sentences, all information-dense and necessary. The core action is front-loaded, followed by critical exceptions and edge-case behavior. No filler or redundancy.

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 one-parameter destructive operation with annotations and no output schema, the description provides all essential context: what is deleted, what is preserved, and what happens to special folders. An agent has enough information to decide whether calling this tool is appropriate.

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

Parameters3/5

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

The schema description coverage is 100%, so the folderId parameter is already documented. The description adds no parameter-specific meaning beyond saying a folder record is removed, which is reasonable given the schema already covers the sole parameter.

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 description clearly states the verb (delete) and resource (folder), and immediately distinguishes this operation from content deletion by specifying that documents are preserved and moved to Unfiled. This makes the tool's purpose unambiguous relative to sibling tools like document_delete and folder_rename.

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

Usage Guidelines3/5

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

The description implies usage for deleting a folder and clarifies an important side effect, but it does not explicitly state when to prefer this tool over alternatives or when not to use it. The caveat about documents moving to Unfiled hints at document_delete as an alternative, but that guidance is not made explicit.

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

folder_listList foldersA
Read-onlyIdempotent
Inspect

List your document-library folders with the number of documents in each. Folders are yours alone; membership is the document's folderId (see document_list). The reserved folder id 'visual-plans' is created on demand by document_create({ folderId: 'visual-plans' }).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond that: folders are user-scoped ('yours alone'), membership is based on the document's folderId, and the special 'visual-plans' folder may appear on demand. This helps an agent predict results without contradicting 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?

Three sentences, each earning its place: the core behavior, an ownership/membership clarification with a pointer to document_list, and a note about a reserved folder id. The main action is front-loaded and there is no 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 no-argument, read-only list tool with rich annotations, the description covers what the tool returns (folders and document counts), the scope (user's own folders), and an edge case (visual-plans). Nothing an agent needs to invoke 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?

The input schema has zero properties, so there are no parameters to document. Baseline for 0 params is 4; the description does not need to add parameter-level semantics.

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 action, 'List your document-library folders', with a concrete output feature, 'with the number of documents in each'. This clearly distinguishes it from document_list, folder_create, and other folder-related 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?

Provides clear context for when to use: listing the caller's own document-library folders, with a cross-reference to document_list for how membership works. It does not explicitly exclude alternatives, but the scoping and sibling context make the intended use clear.

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

folder_renameRename folderA
Destructive
Inspect

Rename one of your folders. The reserved 'visual-plans' folder can be renamed too — its id, not its name, is what the plan plugin files into.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesNew display name (1–60 characters)
folderIdYesFolder ID

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already convey destructiveHint=true, and the description adds the non-obvious behavioral detail that renaming visual-plans is safe because plugins reference it by id, not by name. This goes beyond what annotations or schema express and helps prevent an incorrect refusal.

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?

Two sentences with no filler. The core action comes first and the caveat follows immediately, so an agent gets the essential information with minimal token cost.

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 two-parameter mutation with schema descriptions, a destructive annotation, and no output schema, the description covers the key operation and the one notable edge case. Nothing essential to invoking the tool 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% with basic property descriptions. The description reinforces that folderId, not name, is the stable key, adding meaningful context to the folderId parameter and clarifying why renaming the reserved folder is safe.

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 clear action ('Rename one of your folders') and immediately adds the important special case of the reserved 'visual-plans' folder. This distinguishes the tool's purpose from sibling operations like folder_create, folder_delete, and folder_list.

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?

The description makes the intended use obvious and explicitly addresses the edge case where an agent might hesitate: the 'visual-plans' folder can be renamed too. It does not name alternative tools, but no genuine rename alternative exists among the siblings, so the missing exclusion is minor.

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

node_createCreate canvasAInspect

Add an empty canvas (a node) inside a whiteboard — one canvas per phase, subsystem or topic. Prefer node_create_with_elements to draw it in one call.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleYesNode title
contentNoNode description
documentIdYesParent document ID
canvasWidthNoCanvas width (default: 1920)
canvasHeightNoCanvas height (default: 1080)
parentNodeIdNoParent node ID for hierarchy
backgroundColorNoCanvas background color hex (e.g., #0d1117)

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already communicate that this is a mutating, non-idempotent operation, and the description adds that it produces an empty canvas rather than one with elements. It does not disclose side effects such as whether further calls are needed to populate the canvas or what happens to existing canvases.

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?

The description is only two sentences with no filler. The core action is front-loaded, and the alternative tool guidance is placed second without redundantly restating schema information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a straightforward create operation and schema coverage is complete, but no output schema exists and the description does not indicate what is returned. It also leaves the node_create_with_id sibling undifferentiated, which is a notable gap for a tool family with several node creation variants.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all seven parameters. The description adds only a light domain context (canvas inside a whiteboard) rather than parameter-specific guidance.

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 description opens with a specific verb-object pair ('Add an empty canvas') and clearly places it inside a whiteboard, going beyond the generic title 'Create canvas.' It also distinguishes the tool from node_create_with_elements by stating that this version creates an empty canvas.

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?

The description gives explicit context ('one canvas per phase, subsystem or topic') and explicitly recommends node_create_with_elements when the goal is to draw elements in one call. However, it does not mention node_create_with_id or provide exclusions for other sibling tools.

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

node_create_with_elementsCreate canvas with elementsInspect

Add a canvas inside a whiteboard with its whole diagram drawn in one atomic call — one canvas per phase, subsystem or topic. Whiteboards nest: put a shape on the parent canvas with isLink and linkTarget = this node's id so people click through. More efficient than creating a node then adding elements separately. All elements are validated before anything is created (all or nothing). The reply carries the new node and each element's id, type and revision token in input order. Supported types: rectangle, text, connector, triangle, diamond, hexagon, ellipse, line, bezier-curve, block-arrow, freehand, table, checklist, chart, uml-class, uml-interface, uml-component, uml-package, uml-artifact, uml-note.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleYesNode title
contentNoNode description
elementsYesArray of element objects, each with 'type' and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow; a circle is an ellipse with equal width and height): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex, both REQUIRED then): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). A text element sizes itself: leave width and height out, and the width is measured from the text, or is maxWidth when you set one. The wrap width is stored and read back as frameWidth; an update takes it by either name, maxWidth or frameWidth, and the element's width follows it. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor (optional, default #1a1a1a), strokeWidth (optional, default 3), opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A fill field on a stroke that is not closed is refused. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot), opacity (0 to 1: the line and its markers together). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle, opacity (0 to 1). Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20, default 3), cols (1..10, default 3), cells (optional string[][] matching rows×cols; without it the table is empty), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). width and height size the whole table. A read returns each row of cells as { values: [...] }. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; a long item or title wraps onto more lines and its row grows taller, so give the checklist enough height for every row: rows past the bottom are hidden), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. "$", "%"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID).
documentIdYesParent document ID
canvasWidthNoCanvas width (default: 1920)
canvasHeightNoCanvas height (default: 1080)
parentNodeIdNoParent node ID for hierarchy
returnElementsNoSet true to get every created element back in full (stored form). By default the reply is short: each element's id, type (the same value reads return as elementType) and revision token, in input order.
backgroundColorNoCanvas background color hex (e.g., #0d1117)
node_create_with_idCreate canvas with idA
Idempotent
Inspect

Create a node with a specific ID (useful for pre-linking)

ParametersJSON Schema
NameRequiredDescriptionDefault
titleYesNode title
nodeIdYesSpecific node ID to use
contentNoNode description
documentIdYesParent document ID
canvasWidthNoCanvas width (default: 1920)
canvasHeightNoCanvas height (default: 1080)
parentNodeIdNoParent node ID for hierarchy
backgroundColorNoCanvas background color hex (e.g., #0d1117)

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already mark readOnlyHint=false and idempotentHint=true, so the mutation nature is clear. The description adds the 'pre-linking' context but does not disclose behaviors like error handling on duplicate IDs or whether it overwrites. It is consistent with annotations and provides minor extra context, but not rich behavioral detail.

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?

A single, efficient sentence that front-loads the core purpose and adds a usage hint. Every word earns its place, with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 8 parameters and no output schema, the description is minimal. The schema covers parameters, but the description does not help an agent distinguish this from node_create or node_create_with_elements, nor does it explain return behavior. It is functional but leaves important selection context to inference.

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

Parameters3/5

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

Schema description coverage is 100%, so all 8 parameters have descriptions. The tool description adds no parameter-specific semantics beyond restating the ID concept, which is already covered by the nodeId property. It meets the baseline for high coverage without adding extra value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb ('Create') and resource ('a node'), and specifies the distinguishing feature ('with a specific ID'). It also hints at a use case ('useful for pre-linking'), which adds purpose. However, it does not explicitly contrast with sibling tools like node_create or node_create_with_elements, so it's not fully differentiated.

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

Usage Guidelines3/5

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

The phrase 'useful for pre-linking' implies a scenario where a known ID is needed, but it does not state when to choose this tool over node_create or when not to use it. No exclusions or alternatives are named, leaving the agent to infer the context.

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

node_deleteDelete canvasC
DestructiveIdempotent
Inspect

Delete a node permanently

ParametersJSON Schema
NameRequiredDescriptionDefault
nodeIdYesNode ID
documentIdYesParent document ID

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered; the word "permanently" merely echoes destructiveHint without adding context. It does not disclose whether deletion cascades to child elements, whether a second call errors or no-ops (relevant given idempotentHint=true), or any permission requirements. There is no contradiction with annotations.

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?

One tight sentence, front-loaded with the action verb 'delete' and zero filler words. Efficient and scannable, though sparse enough that it leans heavily on the title and annotations to carry meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive operation with no output schema, the description leaves critical questions unanswered: what a node is relative to a canvas, whether the delete cascades to contained elements, and what happens on repeated calls. Without this, an agent may select the wrong sibling tool (e.g., element_delete) or underestimate the blast radius of the operation.

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

Parameters3/5

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

Schema description coverage is 100% — both nodeId ("Node ID") and documentId ("Parent document ID") are already documented in the schema. The description adds no parameter-level meaning, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (delete), resource (node), and scope ("permanently"), which separates it from sibling delete tools by resource noun (element_delete, folder_delete, document_delete, template_delete). However, it does not explicitly contrast with any sibling, and the title's 'canvas' terminology leaves a minor semantic ambiguity about what a 'node' is.

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

Usage Guidelines2/5

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

Provides no guidance on when to use node_delete versus element_delete, batch_delete_elements, or other delete siblings. No prerequisites, no exclusions, and no indication of which tool handles elements within a canvas — the agent must infer the context from the tool name alone.

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

node_getRead canvasB
Read-onlyIdempotent
Inspect

Get a node with its elements

ParametersJSON Schema
NameRequiredDescriptionDefault
nodeIdYesNode ID
documentIdYesParent document ID

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description's job is lighter. It adds that the result includes the node's elements, which is useful since there is no output schema, but says nothing about errors or the shape of the returned elements.

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?

A single, front-loaded sentence that contains only the necessary information: the action and the scope of the result. There is no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read operation with rich annotations, the description plus schema is nearly sufficient. The remaining gap is the lack of any detail about the returned element structure, which would matter more if there were no sibling tools to clarify the model.

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

Parameters3/5

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

Schema description coverage is 100%, so nodeId and documentId are already documented. The description adds no parameter-specific meaning, matching the baseline for fully covered schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get a node with its elements' names a clear verb and resource, and the qualifier 'with its elements' distinguishes it from node_list or element_get. It does not explicitly contrast with sibling tools, but the intent is unambiguous from the names and title.

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

Usage Guidelines2/5

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

There is no guidance about when to choose this over node_list, element_get, or document_get, and no exclusions or prerequisites beyond the schema's required IDs. The only implied usage is the tool's own name, so an agent gets no routing help.

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

node_listList canvasesA
Read-onlyIdempotent
Inspect

List the canvases (nodes) of a whiteboard — ids and titles — to find where something lives.

ParametersJSON Schema
NameRequiredDescriptionDefault
documentIdYesParent document ID

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds modest behavioral context by saying the output contains ids and titles, but it does not address pagination, ordering, or nesting behavior; with annotations carrying the safety weight this is adequate but not rich.

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?

A single sentence front-loads the action and resource, then gives the output fields and purpose. Every phrase earns its place; there is no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity read-only list with one required parameter, the description plus schema gives an agent the call shape, the output fields, and the use case. It does not specify pagination or size limits, but nothing in the annotations or output schema suggests those are required to invoke the tool correctly.

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

Parameters3/5

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

Schema description coverage is 100% and the single parameter is already documented as 'Parent document ID', so the description need not repeat parameter details. The description contributes only the whiteboard context, matching the baseline for schema-covered parameters.

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 description names the specific verb 'List', the target resource ('canvases (nodes) of a whiteboard'), and the returned fields ('ids and titles'), ending with the intended use ('to find where something lives'). This makes the tool's job unmistakable and differentiates it from single-node operations like node_get.

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

Usage Guidelines3/5

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

The phrase 'to find where something lives' gives a clear discovery use case, so an agent can infer when listing is appropriate. However, it does not explicitly state when to prefer this over siblings such as node_get or document_list, nor does it mention exclusions.

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

node_picturePicture of a canvasA
Read-onlyIdempotent
Inspect

A PNG picture of one canvas, drawn the way the app draws thumbnails and link previews: look at what you drew, then fix it. The whole canvas by default; pass region (x, y, width, height in canvas units) to zoom in on a part, and size for the longest side in pixels (64–2048, default 1200; a region is never blown up past 4 px per canvas unit). Not shown: Mermaid diagrams (a grey placeholder), syntax colours in code, colour in emoji; text in Verdana or Trebuchet MS is drawn in a stand-in font and may wrap elsewhere; text in Chinese, Japanese, Korean, Arabic, Thai or Indic scripts is drawn as empty squares here while the canvas shows it. The reply carries the picture and one line with its size, its scale (px per canvas unit) and the region drawn.

ParametersJSON Schema
NameRequiredDescriptionDefault
sizeNoLongest side of the picture in pixels (default 1200)
nodeIdYesNode (canvas) ID
regionNoThe part of the canvas to draw, in canvas units; the whole canvas when omitted
documentIdYesParent document ID

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial behaviour that is nowhere in structured fields: the 4 px-per-canvas-unit zoom cap, the default 1200 px size, and a detailed fidelity contract (Mermaid placeholders, missing syntax colour, emoji colour, font substitution, CJK/Arabic/Thai/Indic rendered as empty squares). That last point prevents an agent from wrongly concluding content is missing.

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 the core purpose before the caveats, and every clause carries information an agent needs (zoom cap, default size, rendering gaps, reply format). It is dense and semicolon-heavy in a single block, which slightly hurts scanability, but nothing is 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?

There is no output schema, and the description compensates by describing the reply (the picture plus one line with size, scale in px per canvas unit, and the region drawn). Combined with the fidelity caveats and parameter behaviour, an agent has everything needed to call it correctly and interpret the result.

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% and the schema already documents size, region, nodeId and documentId, so baseline would be 3. The description raises it by adding semantics not in the schema — the 4 px-per-canvas-unit ceiling on region zoom, 'longest side' sizing semantics, and the interaction between region and size.

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+resource ('A PNG picture of one canvas') and immediately characterises the rendering pipeline ('drawn the way the app draws thumbnails and link previews'), which cleanly separates it from data-oriented siblings like node_get. The 'look at what you drew, then fix it' clause pins down the intent an agent should have.

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 a clear usage context (visual self-inspection of a canvas after drawing) and explains region vs full-canvas behaviour. It stops short of naming an alternative such as node_get or stating when a picture is the wrong choice, so there is no explicit exclusion guidance.

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

node_updateUpdate canvasB
DestructiveIdempotent
Inspect

Rename a canvas or change its description, size or background colour.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleNoNew title
nodeIdYesNode ID
contentNoNew description
documentIdYesParent document ID
canvasWidthNoNew canvas width
canvasHeightNoNew canvas height
backgroundColorNoCanvas background color hex (e.g., #0d1117)

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already cover the safety profile: readOnlyHint=false, destructiveHint=true, idempotentHint=true. The description adds that only listed canvas properties are affected, but it does not clarify partial-update behavior, such as whether omitted optional fields are reset or preserved.

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?

A single, front-loaded sentence enumerates exactly what the tool updates. There is no filler, repetition, or unnecessary detail, so every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The schema documents all parameters and the annotations cover idempotency and destructiveness. However, the description lacks usage context that would help an agent choose this over sibling update tools, and it does not state whether partial updates are supported, which is relevant for a 7-parameter tool with only 2 required fields.

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

Parameters3/5

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

The input schema has 100% description coverage, so the baseline is 3. The description maps user-facing concepts to parameters (rename to title, description to content, size to canvasWidth/canvasHeight, background to backgroundColor), but adds no constraints or syntax beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Rename'/'change') and names the resource (canvas), listing concrete mutable attributes: title, description, size, and background color. However, it does not explicitly distinguish node_update from sibling tools such as element_update or document_update, so it stops short of full differentiation.

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

Usage Guidelines2/5

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

No guidance is given for when to use this tool versus alternatives. The description implies it is for canvas modifications, but the large sibling list includes other update tools (element_update, document_update), and no routing or exclusion clues are provided.

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

table_append_rowAppend table rowAInspect

Append one row to a table. Values are padded/truncated to the table's CURRENT column count, and the element height grows proportionally — no follow-up geometry write needed. Runs on current state in a transaction: safe under concurrent edits, no revision token. Rejected at the 20-row cap and on locked tables.

ParametersJSON Schema
NameRequiredDescriptionDefault
nodeIdYesParent node ID
valuesYesCell contents for the new row (Markdown), left to right
elementIdYesTable element ID
documentIdYesParent document ID

TDQS

A4.2/5.0
Behavior5/5

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

The description discloses several behaviors beyond the minimal annotations: value padding/truncation to current column count, proportional height growth without follow-up geometry writes, transactional concurrency safety with no revision token, and rejection conditions. The annotations are all false or minimal, so the description carries the full transparency burden and does so thoroughly.

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?

Three sentences with no filler. The main action is front-loaded, followed by behavioral details and constraints. Each sentence adds distinct, essential information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a straightforward append-row operation, the description covers behavior, concurrency, and failure cases. It omits the return value, but there is no output schema and the operation's effect is a side effect. The 20-row cap and locked-table rejection are explicitly mentioned, which is sufficient for correct invocation.

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

Parameters3/5

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

Schema coverage is 100% – each parameter already has a description in the schema. The description adds no additional parameter-specific semantics beyond what the schema provides (e.g., 'values' are Markdown cell contents, which the schema already states). Baseline 3 applies.

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 description states 'Append one row to a table' – a specific verb, resource, and scope. It is clearly distinct from sibling tools like table_update_cell (which updates cells) and element_create (which creates arbitrary elements).

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

Usage Guidelines3/5

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

Usage is implied by the action and constraints (20-row cap, locked tables), but the description does not explicitly contrast with alternatives or state when to use another tool instead. No sibling names or 'when not to use' guidance is provided.

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

table_update_cellUpdate table cellA
DestructiveIdempotent
Inspect

Replace exactly ONE table cell, addressed by 0-indexed row and column (row 0 is the header by convention). Works on the table's CURRENT state inside a transaction, so it cannot clobber concurrent edits and needs no revision token — prefer it over element_update when editing a cell of a whiteboard a human may also be editing. Cell content is CommonMark Markdown.

ParametersJSON Schema
NameRequiredDescriptionDefault
colYesColumn index, 0-based
rowYesRow index, 0-based (row 0 renders as the header)
valueYesNew cell content (Markdown)
nodeIdYesParent node ID
elementIdYesTable element ID
documentIdYesParent document ID

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly=false, idempotent=true, and destructive=true, and the description adds genuinely useful context: transaction semantics, no concurrent clobbering, no revision token, and CommonMark Markdown content. It enriches the annotations rather than merely repeating them.

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?

The description is compact and well-structured, front-loading the core behavior in the first sentence, then adding the usage-guiding transaction context and alternative in the second sentence. There is no 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 single-cell update tool with six fully documented parameters, known annotations, and no nested objects, the description sufficiently covers scope, indexing, concurrency behavior, content format, and the distinguishing use case. Nothing critical is missing for correct invocation.

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

Parameters3/5

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

Input schema coverage is 100%, documenting all six required parameters including 0-based row/col. The description reinforces what the schema already says (e.g., row 0 is the header, Markdown content) but adds little substantial parameter meaning beyond that schema coverage.

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 description states a specific verb-resource operation ('Replace exactly ONE table cell') with precise addressing semantics and explicitly differentiates itself from element_update. An agent can distinguish this from the sibling tools without opening schemas.

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?

It names the direct alternative (element_update) and gives the exact condition for preferring this tool: editing a cell of a whiteboard a human may also be editing. The rationale is clear: transaction-safe, current-state updates with no revision token.

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

template_cloneClone templateAInspect

Start a whiteboard from a template — clone it into a new document owned by the current user (counts toward the user's document-creation allowance)

ParametersJSON Schema
NameRequiredDescriptionDefault
titleNoCustom title for the new document
templateIdYesTemplate ID to clone

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already indicate this is not read-only and is not destructive. The description adds valuable side-effect context: the clone creates a new document owned by the current user and counts toward the user's document-creation allowance. This goes beyond what the annotations convey.

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?

A single sentence with no fluff, front-loaded with the core action and followed by the most important behavioral consequence. Every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity two-parameter tool, the description covers the key side effects, ownership, and quota impact. It does not describe the return value, which is a minor gap given there is no output schema, but the information needed to call the tool correctly is present.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents both parameters adequately. The description clarifies the overall operation but does not add parameter-level detail beyond what the schema provides, so the baseline score of 3 is appropriate.

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 description uses a specific verb ('clone') and resource ('template'), and clearly states the result: a new document owned by the current user. This distinguishes it from siblings like template_create, template_update, and document_create even without opening their schemas.

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?

The opening phrase 'Start a whiteboard from a template' gives a clear context for when to use this tool. It does not explicitly name alternatives or exclusions, but the intended use is evident from the template-to-document framing.

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

template_getRead templateA
Read-onlyIdempotent
Inspect

Get a template with all its nodes and elements

ParametersJSON Schema
NameRequiredDescriptionDefault
templateIdYesTemplate ID

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the return includes all nodes and elements, which is useful context about the result, but it does not disclose any additional behavioral aspects such as error handling, performance, or permission requirements.

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?

A single, front-loaded sentence that states the action (Get), the resource (a template), and the scope (all nodes and elements). There is no filler or unnecessary detail, making it appropriately sized and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with one parameter and no output schema, the description is sufficient: it tells the agent what the tool returns (a template with its content) and the annotations cover the safety profile. Nothing essential is missing for an agent to call it correctly, though it could mention that the templateId must be provided (which is in the schema).

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

Parameters3/5

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

Schema coverage is 100% because the only parameter (templateId) has a description in the schema. The description does not add any extra meaning beyond the schema; it simply mentions 'template' but does not clarify the ID format or usage. Baseline of 3 is appropriate.

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?

Clear verb 'Get' and resource 'template', explicitly stating it includes all nodes and elements. This distinguishes it from template_list (which returns many templates) and other template operations like template_create or template_update. An agent can immediately understand the tool's specific purpose without looking at siblings.

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

Usage Guidelines3/5

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

The description implies this is the tool for fetching a single template with its full content, but it does not explicitly state when to use it over alternatives (e.g., template_list for listing templates, node_get for individual nodes). No exclusions or alternative routing are provided, leaving usage somewhat to inference.

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

template_listList templatesA
Read-onlyIdempotent
Inspect

Browse starting points: list the templates that can be cloned into a new whiteboard. Admins see all templates (including unpublished); regular users see only published templates.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already convey readOnly/idempotent/non-destructive, so the description's added role-based visibility (admins see unpublished templates; regular users only published) is meaningful extra context. It doesn't describe response shape or pagination, but for a zero-parameter list all templates the safety profile is fully covered.

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?

Two short sentences with no filler: the first front-loads the tool's purpose and use case, and the second earns its place by clarifying permission-dependent visibility.

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 zero-parameter, low-complexity list tool with read-only annotations, the description is complete: it says what is listed, why it matters, and who sees what. No output schema is present, but the tool name and 'list' language make the return nature clear.

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?

The input schema has zero properties and schema description coverage is 100%, so there are no parameter semantics to explain; baseline 4 applies because the description correctly has no parameter documentation to add.

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?

Opening 'Browse starting points: list the templates that can be cloned into a new whiteboard' states a concrete verb and resource plus the use case, and the role-based visibility line distinguishes it from single-template getter, creator, cloner, and publisher 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?

The description gives clear context — browse available starting points before cloning into a new whiteboard — and explains the admin vs regular-user behavior. It does not explicitly name alternatives or say when not to use it, but no exclusion is necessary for a parameterless list operation.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updates
    • Changedbatch_create_elements1 field changed
      • changedInput schema / properties / elements / description
        Previous value: -"Array of element objects, each with 'type' and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow; a circle is an ellipse with equal width and height): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex, both REQUIRED then): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). A text element sizes itself: leave width and height out, and the width is measured from the text, or is maxWidth when you set one. The wrap width is stored and read back as frameWidth; an update takes it by either name, maxWidth or frameWidth, and the element's width follows it. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor (optional, default #1a1a1a), strokeWidth (optional, default 3), opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A fill field on a stroke that is not closed is refused. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot), opacity (0 to 1: the line and its markers together). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle, opacity (0 to 1). Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20, default 3), cols (1..10, default 3), cells (optional string[][] matching rows×cols; without it the table is empty), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). width and height size the whole table. A read returns each row of cells as { values: [...] }. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; an item shows its first 40 characters), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."New value: +"Array of element objects, each with 'type' and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow; a circle is an ellipse with equal width and height): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex, both REQUIRED then): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). A text element sizes itself: leave width and height out, and the width is measured from the text, or is maxWidth when you set one. The wrap width is stored and read back as frameWidth; an update takes it by either name, maxWidth or frameWidth, and the element's width follows it. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor (optional, default #1a1a1a), strokeWidth (optional, default 3), opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A fill field on a stroke that is not closed is refused. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot), opacity (0 to 1: the line and its markers together). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle, opacity (0 to 1). Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20, default 3), cols (1..10, default 3), cells (optional string[][] matching rows×cols; without it the table is empty), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). width and height size the whole table. A read returns each row of cells as { values: [...] }. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; a long item or title wraps onto more lines and its row grows taller, so give the checklist enough height for every row: rows past the bottom are hidden), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."
    • Changedelement_create1 field changed
      • changedInput schema / properties / element / description
        Previous value: -"Element object with required 'type' field and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow; a circle is an ellipse with equal width and height): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex, both REQUIRED then): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). A text element sizes itself: leave width and height out, and the width is measured from the text, or is maxWidth when you set one. The wrap width is stored and read back as frameWidth; an update takes it by either name, maxWidth or frameWidth, and the element's width follows it. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor (optional, default #1a1a1a), strokeWidth (optional, default 3), opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A fill field on a stroke that is not closed is refused. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot), opacity (0 to 1: the line and its markers together). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle, opacity (0 to 1). Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20, default 3), cols (1..10, default 3), cells (optional string[][] matching rows×cols; without it the table is empty), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). width and height size the whole table. A read returns each row of cells as { values: [...] }. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; an item shows its first 40 characters), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."New value: +"Element object with required 'type' field and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow; a circle is an ellipse with equal width and height): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex, both REQUIRED then): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). A text element sizes itself: leave width and height out, and the width is measured from the text, or is maxWidth when you set one. The wrap width is stored and read back as frameWidth; an update takes it by either name, maxWidth or frameWidth, and the element's width follows it. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor (optional, default #1a1a1a), strokeWidth (optional, default 3), opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A fill field on a stroke that is not closed is refused. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot), opacity (0 to 1: the line and its markers together). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle, opacity (0 to 1). Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20, default 3), cols (1..10, default 3), cells (optional string[][] matching rows×cols; without it the table is empty), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). width and height size the whole table. A read returns each row of cells as { values: [...] }. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; a long item or title wraps onto more lines and its row grows taller, so give the checklist enough height for every row: rows past the bottom are hidden), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."
    • Changednode_create_with_elements1 field changed
      • changedInput schema / properties / elements / description
        Previous value: -"Array of element objects, each with 'type' and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow; a circle is an ellipse with equal width and height): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex, both REQUIRED then): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). A text element sizes itself: leave width and height out, and the width is measured from the text, or is maxWidth when you set one. The wrap width is stored and read back as frameWidth; an update takes it by either name, maxWidth or frameWidth, and the element's width follows it. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor (optional, default #1a1a1a), strokeWidth (optional, default 3), opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A fill field on a stroke that is not closed is refused. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot), opacity (0 to 1: the line and its markers together). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle, opacity (0 to 1). Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20, default 3), cols (1..10, default 3), cells (optional string[][] matching rows×cols; without it the table is empty), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). width and height size the whole table. A read returns each row of cells as { values: [...] }. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; an item shows its first 40 characters), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."New value: +"Array of element objects, each with 'type' and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow; a circle is an ellipse with equal width and height): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex, both REQUIRED then): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). A text element sizes itself: leave width and height out, and the width is measured from the text, or is maxWidth when you set one. The wrap width is stored and read back as frameWidth; an update takes it by either name, maxWidth or frameWidth, and the element's width follows it. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor (optional, default #1a1a1a), strokeWidth (optional, default 3), opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A fill field on a stroke that is not closed is refused. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot), opacity (0 to 1: the line and its markers together). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle, opacity (0 to 1). Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20, default 3), cols (1..10, default 3), cells (optional string[][] matching rows×cols; without it the table is empty), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). width and height size the whole table. A read returns each row of cells as { values: [...] }. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; a long item or title wraps onto more lines and its row grows taller, so give the checklist enough height for every row: rows past the bottom are hidden), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."
  2. 1 tool update
    • Changeddocument_share3 fields changed
      • addedInput schema / properties / commenterEmails
        Added value: +{
        +  "description": "Subset of `emails` who can comment and ask @agent for changes, without editing",
        +  "items": {
        +    "format": "email",
        +    "pattern": "^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
        +    "type": "string"
        +  },
        +  "type": "array"
        +}
      • changedInput schema / properties / editorEmails / description
        Previous value: -"Subset of `emails` to grant edit access (live coediting)"New value: +"Subset of `emails` who can edit (live coediting) and comment"
      • changedInput schema / properties / emails / description
        Previous value: -"Email addresses to grant view access"New value: +"Email addresses to share with; new people listed only here get view access (look only, no comments)"
  3. 3 tool updates
    • Changedbatch_create_elements1 field changed
      • changedInput schema / properties / elements / description
        Previous value: -"Array of element objects, each with 'type' and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow; a circle is an ellipse with equal width and height): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex, both REQUIRED then): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). A text element sizes itself: leave width and height out, and the width is measured from the text, or is maxWidth when you set one. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor (optional, default #1a1a1a), strokeWidth (optional, default 3), opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A fill field on a stroke that is not closed is refused. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20, default 3), cols (1..10, default 3), cells (optional string[][] matching rows×cols; without it the table is empty), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). width and height size the whole table. A read returns each row of cells as { values: [...] }. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; an item shows its first 40 characters), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."New value: +"Array of element objects, each with 'type' and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow; a circle is an ellipse with equal width and height): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex, both REQUIRED then): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). A text element sizes itself: leave width and height out, and the width is measured from the text, or is maxWidth when you set one. The wrap width is stored and read back as frameWidth; an update takes it by either name, maxWidth or frameWidth, and the element's width follows it. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor (optional, default #1a1a1a), strokeWidth (optional, default 3), opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A fill field on a stroke that is not closed is refused. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot), opacity (0 to 1: the line and its markers together). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle, opacity (0 to 1). Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20, default 3), cols (1..10, default 3), cells (optional string[][] matching rows×cols; without it the table is empty), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). width and height size the whole table. A read returns each row of cells as { values: [...] }. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; an item shows its first 40 characters), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."
    • Changedelement_create1 field changed
      • changedInput schema / properties / element / description
        Previous value: -"Element object with required 'type' field and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow; a circle is an ellipse with equal width and height): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex, both REQUIRED then): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). A text element sizes itself: leave width and height out, and the width is measured from the text, or is maxWidth when you set one. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor (optional, default #1a1a1a), strokeWidth (optional, default 3), opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A fill field on a stroke that is not closed is refused. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20, default 3), cols (1..10, default 3), cells (optional string[][] matching rows×cols; without it the table is empty), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). width and height size the whole table. A read returns each row of cells as { values: [...] }. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; an item shows its first 40 characters), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."New value: +"Element object with required 'type' field and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow; a circle is an ellipse with equal width and height): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex, both REQUIRED then): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). A text element sizes itself: leave width and height out, and the width is measured from the text, or is maxWidth when you set one. The wrap width is stored and read back as frameWidth; an update takes it by either name, maxWidth or frameWidth, and the element's width follows it. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor (optional, default #1a1a1a), strokeWidth (optional, default 3), opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A fill field on a stroke that is not closed is refused. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot), opacity (0 to 1: the line and its markers together). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle, opacity (0 to 1). Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20, default 3), cols (1..10, default 3), cells (optional string[][] matching rows×cols; without it the table is empty), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). width and height size the whole table. A read returns each row of cells as { values: [...] }. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; an item shows its first 40 characters), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."
    • Changednode_create_with_elements1 field changed
      • changedInput schema / properties / elements / description
        Previous value: -"Array of element objects, each with 'type' and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow; a circle is an ellipse with equal width and height): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex, both REQUIRED then): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). A text element sizes itself: leave width and height out, and the width is measured from the text, or is maxWidth when you set one. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor (optional, default #1a1a1a), strokeWidth (optional, default 3), opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A fill field on a stroke that is not closed is refused. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20, default 3), cols (1..10, default 3), cells (optional string[][] matching rows×cols; without it the table is empty), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). width and height size the whole table. A read returns each row of cells as { values: [...] }. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; an item shows its first 40 characters), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."New value: +"Array of element objects, each with 'type' and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow; a circle is an ellipse with equal width and height): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex, both REQUIRED then): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). A text element sizes itself: leave width and height out, and the width is measured from the text, or is maxWidth when you set one. The wrap width is stored and read back as frameWidth; an update takes it by either name, maxWidth or frameWidth, and the element's width follows it. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor (optional, default #1a1a1a), strokeWidth (optional, default 3), opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A fill field on a stroke that is not closed is refused. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot), opacity (0 to 1: the line and its markers together). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle, opacity (0 to 1). Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20, default 3), cols (1..10, default 3), cells (optional string[][] matching rows×cols; without it the table is empty), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). width and height size the whole table. A read returns each row of cells as { values: [...] }. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; an item shows its first 40 characters), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."
  4. 6 tool updates
    • Changedbatch_create_elements2 fields changed
      • changedInput schema / properties / elements / description
        Previous value: -"Array of element objects, each with 'type' and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor, strokeWidth, opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20), cols (1..10), cells (string[][] matching rows×cols), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; an item shows its first 40 characters), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."New value: +"Array of element objects, each with 'type' and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow; a circle is an ellipse with equal width and height): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex, both REQUIRED then): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). A text element sizes itself: leave width and height out, and the width is measured from the text, or is maxWidth when you set one. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor (optional, default #1a1a1a), strokeWidth (optional, default 3), opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A fill field on a stroke that is not closed is refused. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20, default 3), cols (1..10, default 3), cells (optional string[][] matching rows×cols; without it the table is empty), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). width and height size the whole table. A read returns each row of cells as { values: [...] }. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; an item shows its first 40 characters), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."
      • changedInput schema / properties / returnElements / description
        Previous value: -"Set true to get every created element back in full (stored form). By default the reply is short: each element's id, type and revision token, in input order."New value: +"Set true to get every created element back in full (stored form). By default the reply is short: each element's id, type (the same value reads return as elementType) and revision token, in input order."
    • Changedbatch_update_elements1 field changed
      • changedInput schema / properties / updates / description
        Previous value: -"Array of update objects, each with 'elementId' and fields to update. Geometry and link fields sit at the top level: x, y, width, height, rotation, isLink, linkTarget, locked. Everything else is a shape property and goes inside `properties` (e.g., {properties: {fillColor: \"#00FF00\", text: \"Done\"}}). A shape property outside `properties`, or a property the element's type does not have, is refused and nothing is written. Per entry: expectedRevision is the element's `revision` token from the read this change is based on (every read tool returns it per element). It is REQUIRED when properties replaces a composite value (cells, items, points, text, uml attributes/methods, startEndpoint/endEndpoint, chart data/seriesColors) and optional otherwise. If the element changed since that read the write fails with a CONFLICT asking you to re-read; a composite write without the token fails with a MissingRevisionError. To change one cell, row, or item of a whiteboard a human may also be editing, prefer table_update_cell / table_append_row / checklist_toggle_item — they work on current state and need no token. Any stale or token-less composite entry aborts the WHOLE batch. Updates merge per key: omitted properties are preserved, provided ones are replaced whole. For checklists, properties.items replaces the entire item list (ids are backfilled) — omit items to keep it; table cells are likewise replaced whole and reshaped to the table's rows×cols; chart data and seriesColors are replaced whole too. For freehand strokes, properties.points replaces the local point array, and the element's width/height follow the new points on their own. Connector startAnchor/endAnchor may only be set to a corner/edge (corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; corner-top is the triangle apex, triangle-only); 'center' is rejected. Omit the anchor keys to leave a legacy connector's anchors untouched."New value: +"Array of update objects, each with 'elementId' and fields to update. Geometry and link fields sit at the top level: x, y, width, height, rotation, isLink, linkTarget, locked. Everything else is a shape property and goes inside `properties` (e.g., {properties: {fillColor: \"#00FF00\", text: \"Done\"}}). A shape property outside `properties`, or a property the element's type does not have, is refused and nothing is written. Setting fillStyle 'linear' or 'radial' needs a hex fillColor and a fillColor2, sent in the same update or already stored on the shape; fillStyle 'solid' turns a gradient back into a plain fill. A read can show properties whose names start with two underscores: they are internal, leave them as they are. Per entry: expectedRevision is the element's `revision` token from the read this change is based on (every read tool returns it per element). It is REQUIRED when properties replaces a composite value (cells, items, points, text, uml attributes/methods, startEndpoint/endEndpoint, chart data/seriesColors) and optional otherwise. If the element changed since that read the write fails with a CONFLICT asking you to re-read; a composite write without the token fails with a MissingRevisionError. To change one cell, row, or item of a whiteboard a human may also be editing, prefer table_update_cell / table_append_row / checklist_toggle_item — they work on current state and need no token. Any stale or token-less composite entry aborts the WHOLE batch. Updates merge per key: omitted properties are preserved, provided ones are replaced whole. For checklists, properties.items replaces the entire item list (ids are backfilled) — omit items to keep it; table cells are likewise replaced whole and reshaped to the table's rows×cols, sent as string[][] or as the { values: [...] } rows a read returns; chart data and seriesColors are replaced whole too. For freehand strokes, properties.points replaces the local point array, and the element's width/height follow the new points on their own. A fill field needs the stroke to be closed, by the same update or already. Connector startAnchor/endAnchor may only be set to a corner/edge (corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; corner-top is the triangle apex, triangle-only); 'center' is rejected. Omit the anchor keys to leave a legacy connector's anchors untouched."
    • Changedelement_create1 field changed
      • changedInput schema / properties / element / description
        Previous value: -"Element object with required 'type' field and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor, strokeWidth, opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20), cols (1..10), cells (string[][] matching rows×cols), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; an item shows its first 40 characters), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."New value: +"Element object with required 'type' field and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow; a circle is an ellipse with equal width and height): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex, both REQUIRED then): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). A text element sizes itself: leave width and height out, and the width is measured from the text, or is maxWidth when you set one. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor (optional, default #1a1a1a), strokeWidth (optional, default 3), opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A fill field on a stroke that is not closed is refused. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20, default 3), cols (1..10, default 3), cells (optional string[][] matching rows×cols; without it the table is empty), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). width and height size the whole table. A read returns each row of cells as { values: [...] }. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; an item shows its first 40 characters), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."
    • Changedelement_update1 field changed
      • changedInput schema / properties / changes / description
        Previous value: -"Fields to update. Geometry and link fields sit at the top level: x, y, width, height, rotation, isLink, linkTarget, locked. Everything else is a shape property and goes inside `properties` (e.g., {properties: {fillColor: \"#00FF00\", text: \"Done\"}}). A shape property outside `properties`, or a property the element's type does not have, is refused and nothing is written. Updates merge per key: omitted properties are preserved, provided ones are replaced whole. For checklists, properties.items replaces the entire item list (ids are backfilled) — omit items to keep it; table cells are likewise replaced whole and reshaped to the table's rows×cols; chart data and seriesColors are replaced whole too. For freehand strokes, properties.points replaces the local point array, and the element's width/height follow the new points on their own. Connector startAnchor/endAnchor may only be set to a corner/edge (corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; corner-top is the triangle apex, triangle-only); 'center' is rejected. Omit the anchor keys to leave a legacy connector's anchors untouched."New value: +"Fields to update. Geometry and link fields sit at the top level: x, y, width, height, rotation, isLink, linkTarget, locked. Everything else is a shape property and goes inside `properties` (e.g., {properties: {fillColor: \"#00FF00\", text: \"Done\"}}). A shape property outside `properties`, or a property the element's type does not have, is refused and nothing is written. Setting fillStyle 'linear' or 'radial' needs a hex fillColor and a fillColor2, sent in the same update or already stored on the shape; fillStyle 'solid' turns a gradient back into a plain fill. A read can show properties whose names start with two underscores: they are internal, leave them as they are. Updates merge per key: omitted properties are preserved, provided ones are replaced whole. For checklists, properties.items replaces the entire item list (ids are backfilled) — omit items to keep it; table cells are likewise replaced whole and reshaped to the table's rows×cols, sent as string[][] or as the { values: [...] } rows a read returns; chart data and seriesColors are replaced whole too. For freehand strokes, properties.points replaces the local point array, and the element's width/height follow the new points on their own. A fill field needs the stroke to be closed, by the same update or already. Connector startAnchor/endAnchor may only be set to a corner/edge (corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; corner-top is the triangle apex, triangle-only); 'center' is rejected. Omit the anchor keys to leave a legacy connector's anchors untouched."
    • Changednode_create_with_elements2 fields changed
      • changedInput schema / properties / elements / description
        Previous value: -"Array of element objects, each with 'type' and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor, strokeWidth, opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20), cols (1..10), cells (string[][] matching rows×cols), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; an item shows its first 40 characters), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."New value: +"Array of element objects, each with 'type' and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow; a circle is an ellipse with equal width and height): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex, both REQUIRED then): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). A text element sizes itself: leave width and height out, and the width is measured from the text, or is maxWidth when you set one. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor (optional, default #1a1a1a), strokeWidth (optional, default 3), opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A fill field on a stroke that is not closed is refused. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20, default 3), cols (1..10, default 3), cells (optional string[][] matching rows×cols; without it the table is empty), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). width and height size the whole table. A read returns each row of cells as { values: [...] }. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; an item shows its first 40 characters), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."
      • changedInput schema / properties / returnElements / description
        Previous value: -"Set true to get every created element back in full (stored form). By default the reply is short: each element's id, type and revision token, in input order."New value: +"Set true to get every created element back in full (stored form). By default the reply is short: each element's id, type (the same value reads return as elementType) and revision token, in input order."
    • Addednode_picture
  5. 8 tool updates
    • Addedaccount_get
    • Changedbatch_create_elements2 fields changed
      • changedInput schema / properties / elements / description
        Previous value: -"Array of element objects, each with 'type' and type-specific properties. Common fields: x, y, width, height, rotation, fillColor, strokeColor, strokeWidth. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Text label (rectangle, triangle, diamond, hexagon, ellipse, block-arrow): text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Text element: text, fillColor (REQUIRED hex; choose a deliberate color that contrasts with the canvas), fontSize, fontFamily, textAlign. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; p is optional pressure in [0,1]; maximum 2000 points), strokeColor, strokeWidth. Width/height are derived from point extents when omitted. Line: lineStyle, startMarker, endMarker. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), lineStyle, startMarker, endMarker, label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class: name, attributes, methods, stereotype. UML Note: text, fontSize, textColor, textAlign, verticalAlign, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20), cols (1..10), cells (string[][] matching rows×cols), borderColor, backgroundColor, textColor. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."New value: +"Array of element objects, each with 'type' and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor, strokeWidth, opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20), cols (1..10), cells (string[][] matching rows×cols), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; an item shows its first 40 characters), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."
      • addedInput schema / properties / returnElements
        Added value: +{
        +  "description": "Set true to get every created element back in full (stored form). By default the reply is short: each element's id, type and revision token, in input order.",
        +  "type": "boolean"
        +}
    • Addedbatch_reorder_elements
    • Changedbatch_update_elements1 field changed
      • changedInput schema / properties / updates / description
        Previous value: -"Array of update objects, each with 'elementId' and fields to update. Per entry: expectedRevision is the element's `revision` token from the read this change is based on (every read tool returns it per element). It is REQUIRED when properties replaces a composite value (cells, items, points, text, uml attributes/methods, startEndpoint/endEndpoint, chart data/seriesColors) and optional otherwise. If the element changed since that read the write fails with a CONFLICT asking you to re-read; a composite write without the token fails with a MissingRevisionError. To change one cell, row, or item of a whiteboard a human may also be editing, prefer table_update_cell / table_append_row / checklist_toggle_item — they work on current state and need no token. Any stale or token-less composite entry aborts the WHOLE batch. Updates merge per key: omitted properties are preserved, provided ones are replaced whole. For checklists, properties.items replaces the entire item list (ids are backfilled) — omit items to keep it; table cells are likewise replaced whole and reshaped to the table's rows×cols; chart data and seriesColors are replaced whole too. For freehand strokes, properties.points replaces the local point array. Geometry alone does not reshape the ink; when replacing points, also set width/height to their matching extents. Connector startAnchor/endAnchor may only be set to a corner/edge (corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; corner-top is the triangle apex, triangle-only); 'center' is rejected. Omit the anchor keys to leave a legacy connector's anchors untouched."New value: +"Array of update objects, each with 'elementId' and fields to update. Geometry and link fields sit at the top level: x, y, width, height, rotation, isLink, linkTarget, locked. Everything else is a shape property and goes inside `properties` (e.g., {properties: {fillColor: \"#00FF00\", text: \"Done\"}}). A shape property outside `properties`, or a property the element's type does not have, is refused and nothing is written. Per entry: expectedRevision is the element's `revision` token from the read this change is based on (every read tool returns it per element). It is REQUIRED when properties replaces a composite value (cells, items, points, text, uml attributes/methods, startEndpoint/endEndpoint, chart data/seriesColors) and optional otherwise. If the element changed since that read the write fails with a CONFLICT asking you to re-read; a composite write without the token fails with a MissingRevisionError. To change one cell, row, or item of a whiteboard a human may also be editing, prefer table_update_cell / table_append_row / checklist_toggle_item — they work on current state and need no token. Any stale or token-less composite entry aborts the WHOLE batch. Updates merge per key: omitted properties are preserved, provided ones are replaced whole. For checklists, properties.items replaces the entire item list (ids are backfilled) — omit items to keep it; table cells are likewise replaced whole and reshaped to the table's rows×cols; chart data and seriesColors are replaced whole too. For freehand strokes, properties.points replaces the local point array, and the element's width/height follow the new points on their own. Connector startAnchor/endAnchor may only be set to a corner/edge (corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; corner-top is the triangle apex, triangle-only); 'center' is rejected. Omit the anchor keys to leave a legacy connector's anchors untouched."
    • Changedelement_create1 field changed
      • changedInput schema / properties / element / description
        Previous value: -"Element object with required 'type' field and type-specific properties. Common fields: x, y, width, height, rotation, fillColor, strokeColor, strokeWidth. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Text label (rectangle, triangle, diamond, hexagon, ellipse, block-arrow): text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Text element: text, fillColor (REQUIRED hex; choose a deliberate color that contrasts with the canvas), fontSize, fontFamily, textAlign. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; p is optional pressure in [0,1]; maximum 2000 points), strokeColor, strokeWidth. Width/height are derived from point extents when omitted. Line: lineStyle, startMarker, endMarker. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), lineStyle, startMarker, endMarker, label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class: name, attributes, methods, stereotype. UML Note: text, fontSize, textColor, textAlign, verticalAlign, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20), cols (1..10), cells (string[][] matching rows×cols), borderColor, backgroundColor, textColor. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."New value: +"Element object with required 'type' field and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor, strokeWidth, opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20), cols (1..10), cells (string[][] matching rows×cols), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; an item shows its first 40 characters), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."
    • Changedelement_list1 field changed
      • addedInput schema / properties / summary
        Added value: +{
        +  "description": "Set true for a short listing: each element's id, type, position, size, rotation, link fields and revision token, without its properties (text, points, cells, colors). Use element_get for one element's content.",
        +  "type": "boolean"
        +}
    • Changedelement_update1 field changed
      • changedInput schema / properties / changes / description
        Previous value: -"Fields to update. Common: x, y, width, height, rotation. Use 'properties' for shape-specific changes (e.g., {properties: {fillColor: \"#00FF00\"}}). Updates merge per key: omitted properties are preserved, provided ones are replaced whole. For checklists, properties.items replaces the entire item list (ids are backfilled) — omit items to keep it; table cells are likewise replaced whole and reshaped to the table's rows×cols; chart data and seriesColors are replaced whole too. For freehand strokes, properties.points replaces the local point array. Geometry alone does not reshape the ink; when replacing points, also set width/height to their matching extents. Connector startAnchor/endAnchor may only be set to a corner/edge (corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; corner-top is the triangle apex, triangle-only); 'center' is rejected. Omit the anchor keys to leave a legacy connector's anchors untouched."New value: +"Fields to update. Geometry and link fields sit at the top level: x, y, width, height, rotation, isLink, linkTarget, locked. Everything else is a shape property and goes inside `properties` (e.g., {properties: {fillColor: \"#00FF00\", text: \"Done\"}}). A shape property outside `properties`, or a property the element's type does not have, is refused and nothing is written. Updates merge per key: omitted properties are preserved, provided ones are replaced whole. For checklists, properties.items replaces the entire item list (ids are backfilled) — omit items to keep it; table cells are likewise replaced whole and reshaped to the table's rows×cols; chart data and seriesColors are replaced whole too. For freehand strokes, properties.points replaces the local point array, and the element's width/height follow the new points on their own. Connector startAnchor/endAnchor may only be set to a corner/edge (corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; corner-top is the triangle apex, triangle-only); 'center' is rejected. Omit the anchor keys to leave a legacy connector's anchors untouched."
    • Changednode_create_with_elements2 fields changed
      • changedInput schema / properties / elements / description
        Previous value: -"Array of element objects, each with 'type' and type-specific properties. Common fields: x, y, width, height, rotation, fillColor, strokeColor, strokeWidth. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Text label (rectangle, triangle, diamond, hexagon, ellipse, block-arrow): text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Text element: text, fillColor (REQUIRED hex; choose a deliberate color that contrasts with the canvas), fontSize, fontFamily, textAlign. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; p is optional pressure in [0,1]; maximum 2000 points), strokeColor, strokeWidth. Width/height are derived from point extents when omitted. Line: lineStyle, startMarker, endMarker. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), lineStyle, startMarker, endMarker, label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class: name, attributes, methods, stereotype. UML Note: text, fontSize, textColor, textAlign, verticalAlign, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20), cols (1..10), cells (string[][] matching rows×cols), borderColor, backgroundColor, textColor. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."New value: +"Array of element objects, each with 'type' and type-specific properties. A field that is not listed here for the element's type is refused: nothing is created and the error names the field. Common fields: x, y, width, height, rotation. x/y are the top-left corner and cannot be negative, also on a rotated shape; a shape that reaches past the canvas edge is moved back inside. rotation is any angle in degrees (stored as 0-359) and turns the shape about its center. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Colors are hex, #RGB or #RRGGBB. Layer order is creation order: in one call, earlier array entries are drawn under later ones. batch_reorder_elements changes it afterwards. Shapes (rectangle, triangle, diamond, hexagon, ellipse, block-arrow): fillColor and strokeColor are both REQUIRED — choose them, there is no default. fillColor is a hex color or 'none' for an outline-only shape that shows what is behind it; strokeWidth 0 draws no outline, and strokeColor may then be left out; opacity (0 to 1, default 1) makes the whole shape see-through — fill, outline and label together; fillStyle 'linear' or 'radial' turns the fill into a two-color gradient from fillColor to fillColor2 (both hex): linear runs along gradientAngle in degrees (0 = left to right, the default; 90 = top to bottom) and turns with the shape's rotation, radial runs from fillColor at the center to fillColor2 at the edge; rectangle also takes cornerRadius, block-arrow takes direction (right | left | up | down). Text label on those shapes: text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Markdown traps: a line that starts with a number and a dot is a list item and is renumbered from 1 (write `2\\.` to keep the number); a line break inside a paragraph needs two trailing spaces before the newline; runs of spaces collapse to one. Text element: text, fillColor (REQUIRED hex — it is the color of the letters, a text element has no background; choose one that contrasts with the canvas), fontSize, fontFamily (Inter and Outfit are loaded; any other font depends on the viewer's device), fontWeight (100-900), lineHeight, textAlign, maxWidth (wrap width). Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; maximum 2000 points), strokeColor, strokeWidth, opacity (0 to 1). The line is smoothed through the points, so sparse points round off corners; straight: true joins them with straight lines and keeps corners sharp. closed: true joins the last point back to the first and makes the stroke a shape that takes a fill: fillColor (hex or 'none', the default), and the same fillStyle / fillColor2 / gradientAngle gradient as the basic shapes. A closed stroke that crosses itself fills everything it encloses; one stroke cannot have a hole. strokeWidth 0 draws no line, which leaves a filled closed stroke without an outline. Use a closed filled stroke for any organic filled shape instead of stacking ellipses or hatching. p is optional pressure in [0,1] and is drawn: the line is strokeWidth wide at p = 1 and thins to a third of it at p = 0; a stroke without p keeps one thickness. width/height are always the extent of the points; a value sent for either is ignored. Line: runs from (x, y) to (x + width, y + height); width and height cannot be negative, so tilt it the other way with rotation. strokeColor, strokeWidth, lineStyle (solid | dashed | dotted), startMarker, endMarker (none | arrow | diamond | circle | crow's-foot). Bezier curve: placed like a line, from (x, y) to (x + width, y + height); controlPoint1X/controlPoint1Y (offset from the start) and controlPoint2X/controlPoint2Y (offset from the end) bend it, and without them it is a gentle S. strokeColor, strokeWidth, lineStyle. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), strokeColor, strokeWidth, lineStyle, startMarker (default circle), endMarker (default arrow), label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class and UML Interface: name, attributes, methods, stereotype. UML Component, Package and Artifact: name, stereotype. All UML shapes: fillColor, strokeColor, strokeWidth. UML Note: text, fontSize, textColor, textAlign, verticalAlign, strokeColor, strokeWidth, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20), cols (1..10), cells (string[][] matching rows×cols), borderColor, backgroundColor, textColor, fontFamily, fontSize, textAlign (left | center | right), verticalAlign (top | middle | bottom). Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically; an item shows its first 40 characters), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."
      • addedInput schema / properties / returnElements
        Added value: +{
        +  "description": "Set true to get every created element back in full (stored form). By default the reply is short: each element's id, type and revision token, in input order.",
        +  "type": "boolean"
        +}
  6. 5 tool updates
    • Changedbatch_create_elements1 field changed
      • changedInput schema / properties / elements / description
        Previous value: -"Array of element objects, each with 'type' and type-specific properties. Common fields: x, y, width, height, rotation, fillColor, strokeColor, strokeWidth. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Text label (rectangle, triangle, diamond, hexagon, ellipse, block-arrow): text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Text element: text, fillColor (REQUIRED hex; choose a deliberate color that contrasts with the canvas), fontSize, fontFamily, textAlign. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; p is optional pressure in [0,1]; maximum 2000 points), strokeColor, strokeWidth. Width/height are derived from point extents when omitted. Line: lineStyle, startMarker, endMarker. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), lineStyle, startMarker, endMarker, label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class: name, attributes, methods, stereotype. UML Note: text, fontSize, textColor, textAlign, verticalAlign, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20), cols (1..10), cells (string[][] matching rows×cols), borderColor, backgroundColor, textColor. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Node link: isLink, linkTarget (node ID)."New value: +"Array of element objects, each with 'type' and type-specific properties. Common fields: x, y, width, height, rotation, fillColor, strokeColor, strokeWidth. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Text label (rectangle, triangle, diamond, hexagon, ellipse, block-arrow): text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Text element: text, fillColor (REQUIRED hex; choose a deliberate color that contrasts with the canvas), fontSize, fontFamily, textAlign. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; p is optional pressure in [0,1]; maximum 2000 points), strokeColor, strokeWidth. Width/height are derived from point extents when omitted. Line: lineStyle, startMarker, endMarker. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), lineStyle, startMarker, endMarker, label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class: name, attributes, methods, stereotype. UML Note: text, fontSize, textColor, textAlign, verticalAlign, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20), cols (1..10), cells (string[][] matching rows×cols), borderColor, backgroundColor, textColor. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."
    • Changedbatch_update_elements1 field changed
      • changedInput schema / properties / updates / description
        Previous value: -"Array of update objects, each with 'elementId' and fields to update. Per entry: expectedRevision is the element's `revision` token from the read this change is based on (every read tool returns it per element). It is REQUIRED when properties replaces a composite value (cells, items, points, text, uml attributes/methods, startEndpoint/endEndpoint) and optional otherwise. If the element changed since that read the write fails with a CONFLICT asking you to re-read; a composite write without the token fails with a MissingRevisionError. To change one cell, row, or item of a whiteboard a human may also be editing, prefer table_update_cell / table_append_row / checklist_toggle_item — they work on current state and need no token. Any stale or token-less composite entry aborts the WHOLE batch. Updates merge per key: omitted properties are preserved, provided ones are replaced whole. For checklists, properties.items replaces the entire item list (ids are backfilled) — omit items to keep it; table cells are likewise replaced whole and reshaped to the table's rows×cols. For freehand strokes, properties.points replaces the local point array. Geometry alone does not reshape the ink; when replacing points, also set width/height to their matching extents. Connector startAnchor/endAnchor may only be set to a corner/edge (corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; corner-top is the triangle apex, triangle-only); 'center' is rejected. Omit the anchor keys to leave a legacy connector's anchors untouched."New value: +"Array of update objects, each with 'elementId' and fields to update. Per entry: expectedRevision is the element's `revision` token from the read this change is based on (every read tool returns it per element). It is REQUIRED when properties replaces a composite value (cells, items, points, text, uml attributes/methods, startEndpoint/endEndpoint, chart data/seriesColors) and optional otherwise. If the element changed since that read the write fails with a CONFLICT asking you to re-read; a composite write without the token fails with a MissingRevisionError. To change one cell, row, or item of a whiteboard a human may also be editing, prefer table_update_cell / table_append_row / checklist_toggle_item — they work on current state and need no token. Any stale or token-less composite entry aborts the WHOLE batch. Updates merge per key: omitted properties are preserved, provided ones are replaced whole. For checklists, properties.items replaces the entire item list (ids are backfilled) — omit items to keep it; table cells are likewise replaced whole and reshaped to the table's rows×cols; chart data and seriesColors are replaced whole too. For freehand strokes, properties.points replaces the local point array. Geometry alone does not reshape the ink; when replacing points, also set width/height to their matching extents. Connector startAnchor/endAnchor may only be set to a corner/edge (corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; corner-top is the triangle apex, triangle-only); 'center' is rejected. Omit the anchor keys to leave a legacy connector's anchors untouched."
    • Changedelement_create1 field changed
      • changedInput schema / properties / element / description
        Previous value: -"Element object with required 'type' field and type-specific properties. Common fields: x, y, width, height, rotation, fillColor, strokeColor, strokeWidth. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Text label (rectangle, triangle, diamond, hexagon, ellipse, block-arrow): text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Text element: text, fillColor (REQUIRED hex; choose a deliberate color that contrasts with the canvas), fontSize, fontFamily, textAlign. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; p is optional pressure in [0,1]; maximum 2000 points), strokeColor, strokeWidth. Width/height are derived from point extents when omitted. Line: lineStyle, startMarker, endMarker. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), lineStyle, startMarker, endMarker, label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class: name, attributes, methods, stereotype. UML Note: text, fontSize, textColor, textAlign, verticalAlign, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20), cols (1..10), cells (string[][] matching rows×cols), borderColor, backgroundColor, textColor. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Node link: isLink, linkTarget (node ID)."New value: +"Element object with required 'type' field and type-specific properties. Common fields: x, y, width, height, rotation, fillColor, strokeColor, strokeWidth. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Text label (rectangle, triangle, diamond, hexagon, ellipse, block-arrow): text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Text element: text, fillColor (REQUIRED hex; choose a deliberate color that contrasts with the canvas), fontSize, fontFamily, textAlign. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; p is optional pressure in [0,1]; maximum 2000 points), strokeColor, strokeWidth. Width/height are derived from point extents when omitted. Line: lineStyle, startMarker, endMarker. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), lineStyle, startMarker, endMarker, label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class: name, attributes, methods, stereotype. UML Note: text, fontSize, textColor, textAlign, verticalAlign, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20), cols (1..10), cells (string[][] matching rows×cols), borderColor, backgroundColor, textColor. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."
    • Changedelement_update2 fields changed
      • changedInput schema / properties / changes / description
        Previous value: -"Fields to update. Common: x, y, width, height, rotation. Use 'properties' for shape-specific changes (e.g., {properties: {fillColor: \"#00FF00\"}}). Updates merge per key: omitted properties are preserved, provided ones are replaced whole. For checklists, properties.items replaces the entire item list (ids are backfilled) — omit items to keep it; table cells are likewise replaced whole and reshaped to the table's rows×cols. For freehand strokes, properties.points replaces the local point array. Geometry alone does not reshape the ink; when replacing points, also set width/height to their matching extents. Connector startAnchor/endAnchor may only be set to a corner/edge (corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; corner-top is the triangle apex, triangle-only); 'center' is rejected. Omit the anchor keys to leave a legacy connector's anchors untouched."New value: +"Fields to update. Common: x, y, width, height, rotation. Use 'properties' for shape-specific changes (e.g., {properties: {fillColor: \"#00FF00\"}}). Updates merge per key: omitted properties are preserved, provided ones are replaced whole. For checklists, properties.items replaces the entire item list (ids are backfilled) — omit items to keep it; table cells are likewise replaced whole and reshaped to the table's rows×cols; chart data and seriesColors are replaced whole too. For freehand strokes, properties.points replaces the local point array. Geometry alone does not reshape the ink; when replacing points, also set width/height to their matching extents. Connector startAnchor/endAnchor may only be set to a corner/edge (corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; corner-top is the triangle apex, triangle-only); 'center' is rejected. Omit the anchor keys to leave a legacy connector's anchors untouched."
      • changedInput schema / properties / expectedRevision / description
        Previous value: -"expectedRevision is the element's `revision` token from the read this change is based on (every read tool returns it per element). It is REQUIRED when properties replaces a composite value (cells, items, points, text, uml attributes/methods, startEndpoint/endEndpoint) and optional otherwise. If the element changed since that read the write fails with a CONFLICT asking you to re-read; a composite write without the token fails with a MissingRevisionError. To change one cell, row, or item of a whiteboard a human may also be editing, prefer table_update_cell / table_append_row / checklist_toggle_item — they work on current state and need no token."New value: +"expectedRevision is the element's `revision` token from the read this change is based on (every read tool returns it per element). It is REQUIRED when properties replaces a composite value (cells, items, points, text, uml attributes/methods, startEndpoint/endEndpoint, chart data/seriesColors) and optional otherwise. If the element changed since that read the write fails with a CONFLICT asking you to re-read; a composite write without the token fails with a MissingRevisionError. To change one cell, row, or item of a whiteboard a human may also be editing, prefer table_update_cell / table_append_row / checklist_toggle_item — they work on current state and need no token."
    • Changednode_create_with_elements1 field changed
      • changedInput schema / properties / elements / description
        Previous value: -"Array of element objects, each with 'type' and type-specific properties. Common fields: x, y, width, height, rotation, fillColor, strokeColor, strokeWidth. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Text label (rectangle, triangle, diamond, hexagon, ellipse, block-arrow): text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Text element: text, fillColor (REQUIRED hex; choose a deliberate color that contrasts with the canvas), fontSize, fontFamily, textAlign. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; p is optional pressure in [0,1]; maximum 2000 points), strokeColor, strokeWidth. Width/height are derived from point extents when omitted. Line: lineStyle, startMarker, endMarker. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), lineStyle, startMarker, endMarker, label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class: name, attributes, methods, stereotype. UML Note: text, fontSize, textColor, textAlign, verticalAlign, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20), cols (1..10), cells (string[][] matching rows×cols), borderColor, backgroundColor, textColor. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Node link: isLink, linkTarget (node ID)."New value: +"Array of element objects, each with 'type' and type-specific properties. Common fields: x, y, width, height, rotation, fillColor, strokeColor, strokeWidth. Position alternatives: centerX/centerY compute x/y from the center point; do not combine x with centerX or y with centerY. Text label (rectangle, triangle, diamond, hexagon, ellipse, block-arrow): text, fontSize, textColor, textAlign, verticalAlign. Text element content, supported shape labels, and table cells use raw CommonMark Markdown. Supported formatting includes **bold**, *italic*, `inline code`, ~~strike~~, [links](url), nested `-` / `1.` lists, and fenced code blocks. A fenced ```mermaid block renders as a Mermaid diagram; other supported language-tagged fences render as syntax-highlighted code. Escape literal Markdown markers with backslash. Text element: text, fillColor (REQUIRED hex; choose a deliberate color that contrasts with the canvas), fontSize, fontFamily, textAlign. Freehand pen stroke: type 'freehand', points (REQUIRED non-empty array of element-local {x, y, p?}; minimum x and y must both be 0; p is optional pressure in [0,1]; maximum 2000 points), strokeColor, strokeWidth. Width/height are derived from point extents when omitted. Line: lineStyle, startMarker, endMarker. Connector: startElementId, endElementId, startAnchor (REQUIRED), endAnchor (REQUIRED), lineStyle, startMarker, endMarker, label. Connector anchors must be one of corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; 'center' is rejected. Pick the facing edges/corners. corner-top is the triangle apex and is triangle-only. UML Class: name, attributes, methods, stereotype. UML Note: text, fontSize, textColor, textAlign, verticalAlign, colorVariant ('yellow' | 'peach' | 'pink' | 'mint' | 'sky' | 'lavender'); fillColor overrides colorVariant. Table: rows (1..20), cols (1..10), cells (string[][] matching rows×cols), borderColor, backgroundColor, textColor. Checklist: title and items (up to 200 {text, checked} entries; ids are assigned automatically), fillColor, strokeColor, strokeWidth, textColor, checkboxColor, fontSize. Chart: chartType (bar | line | pie | number; pie uses the first series, number shows the latest value of the first series with its change), title, data ({ series: up to 6 names, rows: up to 60 { label, values } with one number or null per series, never more values than series }), seriesColors (hex, one per series by position; per slice for pie — when you reorder or remove series, send seriesColors in the new order), valuePrefix / valueSuffix (e.g. \"$\", \"%\"), target (number card), showLegend, showValues, fillColor, strokeColor, strokeWidth, textColor, fontSize. Charts have no text property. Node link: isLink, linkTarget (node ID)."
  7. 10 tool updates
    • Changedagent_listener_key_create1 field changed
      • changedInput schema / properties / documentId / description
        Previous value: -"The board this key listens to — the documentId you just created or were asked to watch"New value: +"The whiteboard this key listens to — the documentId you just created or were asked to watch"
    • Changedbatch_update_elements1 field changed
      • changedInput schema / properties / updates / description
        Previous value: -"Array of update objects, each with 'elementId' and fields to update. Per entry: expectedRevision is the element's `revision` token from the read this change is based on (every read tool returns it per element). It is REQUIRED when properties replaces a composite value (cells, items, points, text, uml attributes/methods, startEndpoint/endEndpoint) and optional otherwise. If the element changed since that read the write fails with a CONFLICT asking you to re-read; a composite write without the token fails with a MissingRevisionError. To change one cell, row, or item of a board a human may also be editing, prefer table_update_cell / table_append_row / checklist_toggle_item — they work on current state and need no token. Any stale or token-less composite entry aborts the WHOLE batch. Updates merge per key: omitted properties are preserved, provided ones are replaced whole. For checklists, properties.items replaces the entire item list (ids are backfilled) — omit items to keep it; table cells are likewise replaced whole and reshaped to the table's rows×cols. For freehand strokes, properties.points replaces the local point array. Geometry alone does not reshape the ink; when replacing points, also set width/height to their matching extents. Connector startAnchor/endAnchor may only be set to a corner/edge (corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; corner-top is the triangle apex, triangle-only); 'center' is rejected. Omit the anchor keys to leave a legacy connector's anchors untouched."New value: +"Array of update objects, each with 'elementId' and fields to update. Per entry: expectedRevision is the element's `revision` token from the read this change is based on (every read tool returns it per element). It is REQUIRED when properties replaces a composite value (cells, items, points, text, uml attributes/methods, startEndpoint/endEndpoint) and optional otherwise. If the element changed since that read the write fails with a CONFLICT asking you to re-read; a composite write without the token fails with a MissingRevisionError. To change one cell, row, or item of a whiteboard a human may also be editing, prefer table_update_cell / table_append_row / checklist_toggle_item — they work on current state and need no token. Any stale or token-less composite entry aborts the WHOLE batch. Updates merge per key: omitted properties are preserved, provided ones are replaced whole. For checklists, properties.items replaces the entire item list (ids are backfilled) — omit items to keep it; table cells are likewise replaced whole and reshaped to the table's rows×cols. For freehand strokes, properties.points replaces the local point array. Geometry alone does not reshape the ink; when replacing points, also set width/height to their matching extents. Connector startAnchor/endAnchor may only be set to a corner/edge (corner-tl, corner-tr, corner-bl, corner-br, corner-top, edge-top, edge-right, edge-bottom, edge-left; corner-top is the triangle apex, triangle-only); 'center' is rejected. Omit the anchor keys to leave a legacy connector's anchors untouched."
    • Changedelement_update1 field changed
      • changedInput schema / properties / expectedRevision / description
        Previous value: -"expectedRevision is the element's `revision` token from the read this change is based on (every read tool returns it per element). It is REQUIRED when properties replaces a composite value (cells, items, points, text, uml attributes/methods, startEndpoint/endEndpoint) and optional otherwise. If the element changed since that read the write fails with a CONFLICT asking you to re-read; a composite write without the token fails with a MissingRevisionError. To change one cell, row, or item of a board a human may also be editing, prefer table_update_cell / table_append_row / checklist_toggle_item — they work on current state and need no token."New value: +"expectedRevision is the element's `revision` token from the read this change is based on (every read tool returns it per element). It is REQUIRED when properties replaces a composite value (cells, items, points, text, uml attributes/methods, startEndpoint/endEndpoint) and optional otherwise. If the element changed since that read the write fails with a CONFLICT asking you to re-read; a composite write without the token fails with a MissingRevisionError. To change one cell, row, or item of a whiteboard a human may also be editing, prefer table_update_cell / table_append_row / checklist_toggle_item — they work on current state and need no token."
    • Removedtemplate_create
    • Removedtemplate_delete
    • Removedtemplate_publish
    • Removedtemplate_unpublish
    • Removedtemplate_update
    • Removedwelcome_template_clear
    • Removedwelcome_template_set
  8. 46 tool updates
    • First observedagent_listener_key_create
    • First observedagent_listener_key_revoke
    • First observedagent_listener_keys_list
    • First observedbatch_create_elements
    • First observedbatch_delete_elements
    • First observedbatch_update_elements
    • First observedchecklist_toggle_item
    • First observedcomment_create
    • First observedcomment_reopen
    • First observedcomment_reply
    • First observedcomment_resolve
    • First observedcomments_list_unresolved
    • First observeddocument_create
    • First observeddocument_delete
    • First observeddocument_get
    • First observeddocument_list
    • First observeddocument_share
    • First observeddocument_update
    • First observedelement_create
    • First observedelement_delete
    • First observedelement_get
    • First observedelement_list
    • First observedelement_update
    • First observedfolder_create
    • First observedfolder_delete
    • First observedfolder_list
    • First observedfolder_rename
    • First observednode_create
    • First observednode_create_with_elements
    • First observednode_create_with_id
    • First observednode_delete
    • First observednode_get
    • First observednode_list
    • First observednode_update
    • First observedtable_append_row
    • First observedtable_update_cell
    • First observedtemplate_clone
    • First observedtemplate_create
    • First observedtemplate_delete
    • First observedtemplate_get
    • First observedtemplate_list
    • First observedtemplate_publish
    • First observedtemplate_unpublish
    • First observedtemplate_update
    • First observedwelcome_template_clear
    • First observedwelcome_template_set

Publisher details

Operator
Graph Knowledge S.R.L.
Operator website
https://unpaged.io
Vendor relationship
First-party
Trust center
Not applicable
Restrictions
Free plan: 5 document creations per account, up to 50 canvases per document you own, 5 collaborators per document. Premium ($10/month or $100/year) removes the document and canvas limits and allows 50 collaborators. The client must support OAuth with dynamic client registration. · Publisher source

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    A shared whiteboard for you and your AI agent I wanted my AI agent and me to be able to point at the same thing. Any MCP-capable agent can read the canvas, draw on it, drop thought bubbles, animate elements, and react when you sketch something.
    1
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Lets Claude, Codex, Cursor and other MCP clients draw hand-drawn Excalidraw diagrams on a local whiteboard, saving them as real .excalidraw files the agent can inspect, revise and undo. It also provides rendering to PNG, SVG import, and docs so agents can self-serve setup and troubleshooting.
    56 npm
    1
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    A local-first whiteboard MCP server that enables AI agents to create, inspect, and update canvas diagrams and shapes collaboratively via 13 semantic tools.
    4
    MIT
Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources