Unpaged
Server Details
Whiteboard where any shape opens into another canvas. Claude Code and Codex plugins render plans on it.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
- Status
- Unhealthy
- Uptime
- 58.1% over 63 days
- OAuth
- Works in Glama
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- –
TDQS
Scored across 47 tools
Most tools have clearly distinct resource/action targets, and the descriptions explicitly distinguish nested read/write levels such as document_get, node_get, element_list and element_get. Some selection risk remains among the multiple creation paths (element_create, batch_create_elements, node_create, node_create_with_elements, node_create_with_id) and specialized mutation helpers like table_update_cell and checklist_toggle_item.
The dominant pattern is singular-resource_action in snake_case, e.g. document_create, element_update, folder_list, comment_reply. There are minor deviations such as batch_create_elements, group_elements, ungroup_elements and comments_list_unresolved, but the names remain readable and predictable overall.
At 47 tools, the surface is heavy for an agent to scan and choose from reliably, even though Unpaged is a broad domain with documents, nodes, elements, comments, folders, templates, images and listener keys. Several tools are useful but specialized, and the set would benefit from consolidation or stronger grouping.
Coverage is strong across the whiteboard lifecycle: document, node, element, comment, folder, template, image and listener-key operations are broadly represented. Remaining gaps are minor, such as no comment edit/delete, no document search, and no direct move of an element between canvases, but agents can usually work around them.
Available Tools
47 toolsaccount_getWhich accountARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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 whiteboardAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | Where this key lives, for the key list — e.g. 'claude-code on my-laptop' (optional) | |
| documentId | Yes | The whiteboard this key listens to — the documentId you just created or were asked to watch |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark a non-idempotent write with readOnlyHint=false, and the description matches (minting a key) rather than contradicting. It goes far beyond annotations, disclosing the one-time key display, polling intervals and header overrides, dedup-by-id requirement, cursor continuation semantics, HTTP 401/409/429/503 handling, and the 20-live-key eviction policy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose in the first sentence, followed by operational detail. It is dense and long, but nearly every clause (polling, errors, eviction) earns its place; slightly more structure/breaks would help readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a complex lifecycle, the description fully carries the burden: it covers response shape ({events,nextCursor}), pagination, error handling, key lifetime, and revocation, leaving 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented. The description reinforces the scope (ONE whiteboard, bound to documentId) but adds no syntax or format detail 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.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: receive @agent notifications for one whiteboard by minting a receive-only listener key bound to its documentId. It distinguishes itself from siblings agent_listener_key_revoke and agent_listener_keys_list by defining the create/receive role and scoping it to a single whiteboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear operating context: one key per whiteboard, independent whiteboards, and a precondition (prove you can open the whiteboard and read comments). It routes the reciprocal action to agent_listener_key_revoke, but does not explicitly frame when to choose creation over the list/revoke siblings beyond that pointer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
agent_listener_key_revokeRevoke listener keyADestructiveIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| keyId | Yes | keyId from agent_listener_keys_list |
TDQS
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.
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.
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.
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.
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.
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 keysARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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)AInspect
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. To make a card that moves as one, give its shapes the same "group" label: the elements of this call sharing a label become one new group (two or more each), and the reply gives each its groupId. 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, image, uml-class, uml-interface, uml-component, uml-package, uml-artifact, uml-note.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | Parent node ID | |
| elements | Yes | 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), 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, endMarker (none | arrow | diamond | circle | crow's-foot; default circle at the start, arrow at the end), 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. Image (a picture): pictureKey, naturalWidth and naturalHeight exactly as image_import answered them, and an optional description (what a screen reader says, at most 1000 characters). A key the whiteboard does not hold is refused: import the picture first. An imported key can be used by element_create in the same whiteboard during this session. Give width alone or height alone and the other follows the picture's proportions; with neither, it lands at its natural size fitted to half the default canvas. Node link: isLink, linkTarget (node ID). | |
| documentId | Yes | Parent document ID | |
| returnElements | No | 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. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say non-read-only, non-destructive, non-idempotent; the description goes well beyond them by disclosing all-or-nothing validation, the group-label mechanism that yields new groups with groupIds, and the exact short reply shape (id, type, revision token in input order). These are non-obvious behaviors that materially change how an agent should batch its call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then the atomicity guarantee, then the group and reply semantics. The long supported-types list is justified because it is the tool's acceptance surface, though it tails off slightly into enumeration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, high-parameter tool with full schema coverage, no output schema and clear annotations, the description supplies everything an agent needs beyond structured fields: atomicity, grouping, ordering of the reply, and the accepted type set. The only omission, sibling routing, is already penalized under usage guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the bulk of field-level semantics lives in the elements schema, so the description's job is small; it still adds value by enumerating supported types and explaining that same-label entries become one group of two or more. It does not itself document returnElements, leaving that to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete verb and scope — 'Draw many shapes on a canvas at once' — and enumerates the element kinds it accepts, so an agent can tell it is the multi-element creation path. It never names element_create or batch_update_elements, so the distinction from siblings is implied by 'batch/at once' 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'the fast, atomic way to lay out a diagram or a plan' and 'All elements are validated before any are created' imply the situation (bulk layout, all-or-nothing). However, there is no explicit guidance on when to prefer this over the singular element_create, nor any stated prerequisite such as needing the parent nodeId to already exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
batch_delete_elementsDelete elements (batch)ADestructiveIdempotentInspect
Delete multiple elements atomically
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | Parent node ID | |
| documentId | Yes | Parent document ID | |
| elementIds | Yes | Element IDs to delete | |
| expectedRevisions | No | Optional map of elementId to its `revision` token from your read. Any provided token that is stale aborts the whole batch with CONFLICT. |
TDQS
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.
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.
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.
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.
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.
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 orderADestructiveIdempotentInspect
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. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | Parent node ID | |
| position | Yes | front: 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. | |
| documentId | Yes | Parent document ID | |
| elementIds | Yes | IDs of the elements to move | |
| relativeTo | No | ID of the element the moved ones are placed next to. REQUIRED for above and below; leave it out for front and back. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: declares atomicity, guarantees that moved elements keep their relative order regardless of id ordering, states that no revisions change and no revision token is required, and describes the reply shape (id + new zOrder, 0 = back) with a warning that later moves shift those numbers. That is unusually complete behavioral context for a mutation tool whose only annotations are readOnly=false, destructive=true, idempotent=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core action and its directions in the first clause, then layers on ordering guarantee, revision behavior, and return format. Dense but each sentence carries distinct information; the illustrative 'shadow under a figure' phrasing is the only mild padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description takes on the burden and explains the return value, its zOrder convention, and its staleness. It also covers atomicity, idempotency implications, and revision behavior—everything an agent needs to invoke it correctly for a 5-parameter mutation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 genuinely non-obvious semantics by stating that elementIds ordering does not determine the relative order of the moved shapes. The relativeTo requirement and position enum meaning are already documented in the schema, so no further credit is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a concrete verb and resource ('Change which shapes are drawn in front of which') and enumerates the four operations (front, back, above, below). It clearly separates itself from batch_update_elements/element_update by scoping the tool to z-order only, and from batch_delete_elements by noting nothing is deleted or redrawn.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete use cases ('slide a shadow under a figure, or uncover a label') and implicitly names the alternative it replaces—deleting and redrawing elements—while noting no revision token is needed, which steers the agent away from element_update. It stops short of explicitly naming sibling tools or stating when-not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
batch_update_elementsUpdate elements (batch)ADestructiveIdempotentInspect
Move, restyle or rewrite many shapes at once, atomically — for restructuring a canvas after feedback.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | Parent node ID | |
| updates | Yes | 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. 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. A read can also show groupId (and groupRotation): group membership changes only through group_elements and ungroup_elements. 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. Image elements (type 'image') are pictures. A read returns properties pictureKey, naturalWidth and naturalHeight (the stored picture's size in pixels) and an optional description (what a screen reader says for it) — never the picture's bytes or a link. An update may move, resize or turn a picture and set properties.description (at most 1000 characters; an empty one removes it); width alone or height alone keeps the picture's proportions, both together are taken as given. pictureKey, naturalWidth and naturalHeight never change: an update that changes them is refused. 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. | |
| documentId | Yes | Parent document ID |
TDQS
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 safety profile is covered structurally. The description's only real addition is "atomically" — a genuinely useful disclosure that a failure aborts the whole batch — but it omits that stale revision tokens cause CONFLICT/MissingRevisionError and that composite writes require a token, which are the behaviors most likely to cause a failed call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and scope, with the atomicity guarantee and the intended scenario attached. No filler, no repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a highly complex, destructive batch mutation the schema is unusually rich (revision tokens, merge semantics, per-type property rules) and annotations cover the safety profile, so a terse description is defensible. The gap is that an agent reading only the description would not learn that partial failures abort everything and that a revision token is mandatory for composite writes — though "atomically" hints at the former.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the `updates` field carries extensive inline documentation (top-level geometry vs `properties`, revision tokens, gradient rules, anchors). The description itself contributes nothing parameter-specific beyond "many shapes at once"; baseline 3 is correct when the schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States concrete verbs (move, restyle, rewrite) against a concrete resource (shapes) plus batch scope and atomicity, which separates it from batch_create_elements, batch_delete_elements and single-element element_update. It never names a sibling explicitly, so the differentiation is inferential 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"For restructuring a canvas after feedback" gives a situational context for use, but there is no when-not guidance and no routing to alternatives such as element_update, table_update_cell or checklist_toggle_item — even though the schema body mentions those siblings, the description does not.
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 itemADestructiveInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| itemId | Yes | Stable id of the item | |
| nodeId | Yes | Parent node ID | |
| checked | No | Target state; omit to toggle the current value | |
| elementId | Yes | Checklist element ID | |
| documentId | Yes | Parent document ID |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | Pin x (canvas coords; requires y too; used when no elementId) | |
| y | No | Pin y (canvas coords; requires x too; used when no elementId) | |
| text | Yes | Message text (CommonMark not rendered — plain text) | |
| nodeId | Yes | Node (canvas) the thread lives on | |
| elementId | No | Pin the thread to this element | |
| documentId | Yes | Document ID |
TDQS
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.
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.
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.
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.
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.
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 commentADestructiveInspect
Reopen a resolved comment thread when the feedback was not actually addressed.
| Name | Required | Description | Default |
|---|---|---|---|
| threadId | Yes | Thread (root comment) ID | |
| documentId | Yes | Document ID |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Reply text | |
| threadId | Yes | Thread (root comment) ID | |
| documentId | Yes | Document ID |
TDQS
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.
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.
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.
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.
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.
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 commentADestructiveInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| threadId | Yes | Thread (root comment) ID | |
| documentId | Yes | Document ID |
TDQS
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.
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.
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.
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.
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.
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 commentsARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| documentId | Yes | Document ID |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Document title | |
| folder | No | Folder NAME to file the document in (created if missing). Mutually exclusive with folderId | |
| folderId | No | Folder ID to file the document in: an existing folder, or the reserved 'visual-plans' (created on demand). Mutually exclusive with folder | |
| canvasWidth | No | Root node canvas width (default: 1920) | |
| canvasHeight | No | Root node canvas height (default: 1080) |
TDQS
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.
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.
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.
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.
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.
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 whiteboardADestructiveIdempotentInspect
Delete a document permanently
| Name | Required | Description | Default |
|---|---|---|---|
| documentId | Yes | Document ID |
TDQS
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.
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.
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.
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.
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.
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 whiteboardARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| documentId | Yes | Document ID |
TDQS
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.
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.
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.
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.
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.
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 whiteboardsARead-onlyIdempotentInspect
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).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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_picturePicture of a whiteboard's mapARead-onlyIdempotentInspect
A PNG picture of a whole whiteboard's map: the Graph Overview the app shows, with a card for every canvas, lines from each canvas to the canvases inside it, and the root canvas dark; node_picture shows one canvas. size is the longest side in pixels (64–2048, default 1200). Each card shows its canvas title on at most two lines. The reply carries the picture and one line with the number of canvases and the picture's size.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Longest side of the picture in pixels (default 1200) | |
| documentId | Yes | Document ID |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: what the rendering looks like (two-line titles, dark root) and what the response contains (the picture plus a summary line with canvas count and image size).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The rendering detail is front-loaded and the routing hint and parameter note follow compactly, with no filler sentences. It is slightly denser than necessary in the visual-content clause, but every sentence carries information an agent can use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so: it names the PNG image plus a one-line summary of canvas count and dimensions. Combined with full schema coverage on both params, nothing needed to invoke or interpret the call is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented, including the 64–2048 range and the 1200 default. The description restates the size semantics ('longest side in pixels') rather than adding new meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('PNG picture of a whole whiteboard's map') and enumerates exactly what the image contains: a card per canvas, connector lines, and a darkened root canvas. It explicitly differentiates from the sibling node_picture ('node_picture shows one canvas'), so an agent can pick between them without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The contrast with node_picture ('shows one canvas') implies the selection rule: whole-document overview here, single canvas there. That is clear usage context, but there is no explicit when-not guidance, no prerequisite or permission note, and no mention of when a visual overview is preferable to node_list/document_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
document_updateUpdate whiteboardADestructiveIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | New title | |
| folder | No | Move to the folder with this NAME (created if missing); null unfiles. Mutually exclusive with folderId | |
| folderId | No | Move to the folder with this ID (existing or reserved); null unfiles. Mutually exclusive with folder | |
| isPublic | No | Set document as publicly accessible via share links | |
| documentId | Yes | Document ID |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: public means anyone with the /share/<id> link can view without an account, a missing folder name is auto-created, and null unfiles. It never explains the destructiveHint=true annotation (what is destroyed or made irreversible), which is the one behavioral question left open.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with the verb and primary operation front-loaded, no filler. The nested parentheticals make it dense to parse, but every clause carries operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter mutation tool with no output schema, the description covers all three operation modes, the unfiling case, folder creation, and the meaning of public access. The remaining gap is the unexplained destructive behavior flagged by annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema descriptions already state 'created if missing', 'null unfiles', and the folder/folderId exclusivity, so most of the description's parameter text is restatement. It does add genuine meaning for isPublic (link semantics, no account required), but that is a single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names three concrete operations on a specific resource (rename a whiteboard, make it PUBLIC, move it to a folder), so the agent knows exactly what the tool does. It does not distinguish itself from the sibling document_share, which plausibly overlaps with the 'make it PUBLIC' capability, leaving a small ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives real routing guidance: 'find the whiteboard with document_list first' and explains the null-to-unfile case plus the folder/folderId mutual exclusion. It stops short of stating when to prefer this over document_share or folder_rename.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
element_createCreate elementAInspect
Draw one shape on a canvas — a rectangle or other shape, connector, table, checklist, note, text or picture. Supported types: rectangle, text, connector, triangle, diamond, hexagon, ellipse, line, bezier-curve, block-arrow, freehand, table, checklist, chart, image, 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"}).
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | Parent node ID | |
| element | Yes | 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), 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, endMarker (none | arrow | diamond | circle | crow's-foot; default circle at the start, arrow at the end), 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. Image (a picture): pictureKey, naturalWidth and naturalHeight exactly as image_import answered them, and an optional description (what a screen reader says, at most 1000 characters). A key the whiteboard does not hold is refused: import the picture first. An imported key can be used by element_create in the same whiteboard during this session. Give width alone or height alone and the other follows the picture's proportions; with neither, it lands at its natural size fitted to half the default canvas. Node link: isLink, linkTarget (node ID). | |
| documentId | Yes | Parent document ID |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a non-read-only, non-idempotent, non-destructive write, matching "Draw ... one shape". The description adds that a full type-specific object must be supplied, but it discloses nothing about failure modes, required permissions, or that repeated calls duplicate elements (non-idempotent) — the error behavior (unknown field refused, unknown pictureKey refused) lives only in the schema text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action, then the type list, then the payload example — no filler. The long comma-separated type enumeration is dense and contains a typo ("uml-note.."), but it carries information the schema does not encode as an enum, so it earns its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter tool with a deeply documented nested `element` object and an example payload, the description gives an agent enough to select and call it. The one real gap is that it never routes an agent to `batch_create_elements` when creating multiple shapes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 three parameters in depth. The description's contribution is a concrete literal example of the `element` payload plus the instruction to match the type's schema — helpful, but marginal against the schema's own extensive field documentation. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Draw one shape on a canvas") and enumerates the element types it accepts, which is the only place those type identifiers appear since the schema's `type` field is an untyped string. It does not name the sibling `batch_create_elements`, so the single-vs-multiple distinction is only implied by "one shape".
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Draw one shape" hints at the single-element use case, but the description never says to use `batch_create_elements` for several shapes or `element_update` to modify. Usage context is only implied; there are no explicit when/when-not statements or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
element_deleteDelete elementBDestructiveIdempotentInspect
Delete an element permanently
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | Parent node ID | |
| elementId | Yes | Element ID | |
| documentId | Yes | Parent document ID | |
| expectedRevision | No | Optional: 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
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.
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.
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.
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.
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.
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 elementBRead-onlyIdempotentInspect
Get an element by ID
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | Parent node ID | |
| elementId | Yes | Element ID | |
| documentId | Yes | Parent document ID |
TDQS
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.
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.
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.
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.
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.
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 elementsARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | Parent node ID | |
| summary | No | 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. | |
| documentId | Yes | Parent document ID |
TDQS
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.
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.
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.
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.
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.
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 elementADestructiveIdempotentInspect
Move, resize, restyle or rewrite one shape — its text, colours, geometry, table cells or checklist items.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | Parent node ID | |
| changes | Yes | Fields to update. Geometry and link fields sit at the top level: x, y, width, height, rotation, isLink, linkTarget. 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. A read can also show groupId (and groupRotation): group membership changes only through group_elements and ungroup_elements. 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. Image elements (type 'image') are pictures. A read returns properties pictureKey, naturalWidth and naturalHeight (the stored picture's size in pixels) and an optional description (what a screen reader says for it) — never the picture's bytes or a link. An update may move, resize or turn a picture and set properties.description (at most 1000 characters; an empty one removes it); width alone or height alone keeps the picture's proportions, both together are taken as given. pictureKey, naturalWidth and naturalHeight never change: an update that changes them is refused. 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. | |
| elementId | Yes | Element ID | |
| documentId | Yes | Parent document ID | |
| expectedRevision | No | 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. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and idempotentHint=true, so the safety profile is covered; the definition adds substantial behaviour beyond that: per-key merge semantics, refusal of misplaced shape properties, composite values (items, cells, points, chart data) being replaced whole, gradient prerequisites, immutable picture fields, and the CONFLICT / MissingRevisionError outcomes. That is unusually rich disclosure, though most of it lives in the `changes` and `expectedRevision` property text and the one-line description contributes little of it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the object (one shape) first and the operation set second; no filler, no restatement of the tool name. Nothing in it fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter, deeply nested mutation tool with no output schema and heavy annotation coverage, the definition is essentially complete: payload routing, revision tokens, cascading replacements and failure modes are all documented. The only shortfall is that neither the description nor the schema says what a successful update returns, and the top-level sentence does not surface the revision-token requirement that a caller must satisfy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the nested `changes` documentation already explains structure, ordering rules and constraints, so the schema does the heavy lifting. The description sentence only gestures at the payload categories ("text, colours, geometry, table cells or checklist items"), which loosely maps onto `changes` but adds no syntax or value details the schema lacks. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with four specific verbs (move, resize, restyle, rewrite) applied to a single resource, then enumerates the exact facets it touches (text, colours, geometry, cells, checklist items). An agent can tell it mutates an existing element rather than creating or fetching one. It stops short of naming the sibling it is not (batch_update_elements), so the single-vs-many split is only implied by "one shape".
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"One shape" implicitly scopes it against batch_update_elements, and the operation words imply when a rewrite is preferable to a delete-and-recreate. But the tool description itself never states preconditions, exclusions, or named alternatives. The only real routing advice (prefer table_update_cell / table_append_row / checklist_toggle_item for single-cell edits) sits buried in the expectedRevision property description rather than in the tool description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
folder_createCreate folderAIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Folder display name (1–60 characters) |
TDQS
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.
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.
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.
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.
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.
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 folderADestructiveIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| folderId | Yes | Folder ID |
TDQS
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.
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.
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.
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.
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.
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 foldersARead-onlyIdempotentInspect
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' }).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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 folderADestructiveInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | New display name (1–60 characters) | |
| folderId | Yes | Folder ID |
TDQS
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.
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.
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.
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.
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.
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.
group_elementsGroup elementsADestructiveInspect
Group shapes so they move, resize and turn as one, the way a person groups them on the canvas: a card's background, title and icons, for example. An element already in a group brings its whole group, so grouping a group with more shapes makes one bigger group (there are no groups inside groups). Only membership changes, so no revision token is needed and no element's revision changes. The reply gives the new groupId and every member's id; each element read shows its groupId. To give a group a canvas inside, set isLink and linkTarget on one of its shapes, usually the back-most: a click anywhere on the group opens it.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | Parent node ID | |
| documentId | Yes | Parent document ID | |
| elementIds | Yes | IDs of the elements to group (two or more) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real context beyond annotations: only membership changes, so no revision token is needed and no revisions bump, plus what the reply contains (groupId and member ids) and how groupId is read back. Does not address why destructiveHint=true (what grouping might displace/supersede) or any permission requirements, leaving that gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core action and behavior, then adds the grouping-of-groups rule and the link variant. Well organized, though the closing isLink sentence is dense and slightly tangential for a grouping tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description correctly explains the return payload. It covers membership semantics and the self-referential group caveat, but says nothing about failure modes, permissions, or what makes the operation 'destructive' -- the main remaining completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 that passing an element already in a group pulls in its whole group, and by describing the isLink/linkTarget behavior on member shapes. It does not explain documentId/nodeId semantics, though those are self-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (group shapes) with concrete examples (a card's background, title and icons) and explains the resulting behavior (move, resize, turn as one). It is clearly distinguished from its sibling ungroup_elements without naming it, since the inverse is obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains the nested/recursive membership rule ('an element already in a group brings its whole group', 'no groups inside groups') and the isLink/linkTarget variant for linking a group to a canvas. Lacks explicit 'use this instead of X when...' routing, though the sibling set makes the alternative obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
image_importImport a pictureAInspect
Adds a picture to a whiteboard from a web link (url), and answers its pictureKey, naturalWidth, naturalHeight, format and byteLength. Nothing is drawn yet: place it with element_create, batch_create_elements or node_create_with_elements as type 'image'. The picture is stored oriented, without its metadata (location included), and fitted inside 2048 pixels; an animated GIF stays animated. An imported key can be used by element_create in the same whiteboard during this session. Adding a picture needs Premium on the account this connection is signed in as.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | An https link to a picture on the web (PNG, JPEG, WebP or GIF), which Unpaged's server fetches. A web page's link is not a picture's: link the picture itself. | |
| documentId | Yes | Document (whiteboard) the picture goes into |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the provided annotations by detailing critical behavioral traits: the picture is stored oriented, metadata (location) is stripped, it is fitted to a 2048-pixel limit, and the session key has limited scope. This provides a complete behavioral profile for the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense with technical detail but extremely efficient. It front-loads the core action and immediately details the operational requirements, using clear, concise language without unnecessary padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool definition is maximally complete. It covers input requirements, output expectations (keys returned), critical behavioral limitations (2048px fit, session scope), and prerequisite business constraints (Premium account). Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds value by reinforcing the constraint that the URL must point directly to the picture file rather than a web page host, helping the agent construct the correct input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource ('Adds a picture to a whiteboard from a web link') and precisely defines the output (pictureKey, dimensions, etc.). Crucially, it immediately distinguishes this from drawing actions by stating 'Nothing is drawn yet,' guiding the agent to subsequent relevant sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool explicitly dictates the workflow: the picture must be followed by a drawing action using specific siblings like element_create or batch_create_elements. Furthermore, it provides a vital operational constraint by stating the requirement for a Premium account.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
image_upload_link_createCreate a picture upload linkAInspect
A one-time link to send ONE picture file (PNG, JPEG, WebP or GIF) from your own machine into a whiteboard, when the picture is not on the web: POST the file's bytes to uploadUrl with the token in an Authorization: Bearer header, never in the link (the reply's command does exactly that with curl). The link works once, for ten minutes, for this whiteboard only, and takes at most maxBytes. The upload's answer is what image_import answers: pictureKey, naturalWidth, naturalHeight, format and byteLength, to place with element_create. Adding a picture needs Premium on the account this connection is signed in as.
| Name | Required | Description | Default |
|---|---|---|---|
| documentId | Yes | Document (whiteboard) the picture goes into |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already signal a non-read-only, non-idempotent mutation, and the description adds substantial behavioral detail: one-time use, ten-minute expiry, whiteboard scoping, maxBytes limit, Bearer-header token handling rather than token-in-link, and Premium account requirement. These are exactly the constraints an agent needs before invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but appropriately sized for a multi-step upload flow. The purpose and usage condition are front-loaded, and every clause contributes either the upload mechanics, security constraint, response shape, or Premium prerequisite.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining return behavior, and it does so by listing the upload response fields pictureKey, naturalWidth, naturalHeight, format, and byteLength and linking them to element_create. It also covers auth placement, expiry, size limits, and account requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one input parameter, documentId, and the schema already has 100% description coverage identifying it as the target whiteboard. The description reinforces that the link is for 'this whiteboard only' but adds no new syntax or format semantics for documentId; uploadUrl and maxBytes are not input parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: create a one-time link to upload one picture file into a whiteboard. It clearly distinguishes this flow from image_import by specifying the case where the picture is not already on the web, and it explains how the result feeds into element_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit usage condition, 'when the picture is not on the web,' and sketches the follow-up workflow via the upload response and element_create. It does not explicitly say to use image_import instead when the picture is already available as a URL, but the sibling context makes that alternative inferable.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Node title | |
| content | No | Node description | |
| documentId | Yes | Parent document ID | |
| canvasWidth | No | Canvas width (default: 1920) | |
| canvasHeight | No | Canvas height (default: 1080) | |
| parentNodeId | No | Parent node ID for hierarchy | |
| backgroundColor | No | Canvas background color hex (e.g., #0d1117) |
TDQS
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.
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.
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.
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.
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.
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 elementsAInspect
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, image, uml-class, uml-interface, uml-component, uml-package, uml-artifact, uml-note.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Node title | |
| content | No | Node description | |
| elements | Yes | 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), 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, endMarker (none | arrow | diamond | circle | crow's-foot; default circle at the start, arrow at the end), 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. Image (a picture): pictureKey, naturalWidth and naturalHeight exactly as image_import answered them, and an optional description (what a screen reader says, at most 1000 characters). A key the whiteboard does not hold is refused: import the picture first. An imported key can be used by element_create in the same whiteboard during this session. Give width alone or height alone and the other follows the picture's proportions; with neither, it lands at its natural size fitted to half the default canvas. Node link: isLink, linkTarget (node ID). | |
| documentId | Yes | Parent document ID | |
| canvasWidth | No | Canvas width (default: 1920) | |
| canvasHeight | No | Canvas height (default: 1080) | |
| parentNodeId | No | Parent node ID for hierarchy | |
| returnElements | No | 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. | |
| backgroundColor | No | Canvas background color hex (e.g., #0d1117) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important behavior: validation happens before creation, the operation is all-or-nothing, and the reply contains the new node plus each element's id, type and revision token in input order. This is rich context for a mutation tool with non-destructive, non-idempotent annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded well, but the description is extremely long and largely duplicates the schema's element documentation. Much of the text does not earn its place in the tool description and makes the definition harder to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description is complete: it covers atomicity, return shape, nesting via links, supported element types, and detailed element semantics. There is no output schema, but the description explains return behavior sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema itself already contains the exhaustive element-property documentation. The description repeats much of that same material rather than adding new parameter semantics, so the baseline of 3 for high schema coverage is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Add a canvas inside a whiteboard with its whole diagram drawn in one atomic call.' It also distinguishes the tool from the multi-step alternative by saying it is 'More efficient than creating a node then adding elements separately.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context ('one canvas per phase, subsystem or topic') and points to the alternative workflow of creating a node then adding elements separately, but it does not explicitly name the sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
node_create_with_idCreate canvas with idAIdempotentInspect
Create a node with a specific ID (useful for pre-linking)
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Node title | |
| nodeId | Yes | Specific node ID to use | |
| content | No | Node description | |
| documentId | Yes | Parent document ID | |
| canvasWidth | No | Canvas width (default: 1920) | |
| canvasHeight | No | Canvas height (default: 1080) | |
| parentNodeId | No | Parent node ID for hierarchy | |
| backgroundColor | No | Canvas background color hex (e.g., #0d1117) |
TDQS
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.
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.
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.
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.
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.
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 canvasCDestructiveIdempotentInspect
Delete a node permanently
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | Node ID | |
| documentId | Yes | Parent document ID |
TDQS
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.
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.
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.
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.
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.
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 canvasBRead-onlyIdempotentInspect
Get a node with its elements
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | Node ID | |
| documentId | Yes | Parent document ID |
TDQS
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.
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.
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.
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.
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.
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 canvasesARead-onlyIdempotentInspect
List the canvases (nodes) of a whiteboard — ids and titles — to find where something lives.
| Name | Required | Description | Default |
|---|---|---|---|
| documentId | Yes | Parent document ID |
TDQS
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.
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.
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.
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.
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.
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 canvasARead-onlyIdempotentInspect
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; an animated picture shows its first frame. The reply carries the picture and one line with its size, its scale (px per canvas unit) and the region drawn.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Longest side of the picture in pixels (default 1200) | |
| nodeId | Yes | Node (canvas) ID | |
| region | No | The part of the canvas to draw, in canvas units; the whole canvas when omitted | |
| documentId | Yes | Parent document ID |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent and non-destructive, but the description goes far beyond them: it discloses fidelity limits (Mermaid as grey placeholder, no syntax colours, colour emoji missing, stand-in fonts for Verdana/Trebuchet, CJK/Arabic/Thai/Indic rendered as empty squares, animations reduced to first frame). It also describes the return payload, the picture plus a line giving size, scale and region drawn.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and defaults are front-loaded before the caveat list, and nearly every clause carries information an agent cannot get elsewhere. It is a single dense paragraph, though, and the long 'Not shown' enumeration makes it a wall of text that could be better partitioned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden itself and does so, specifying the image plus a size/scale/region line. For a tool with a nested region object and non-obvious rendering limitations, the fidelity caveats and defaults make it complete enough to call correctly on the first try.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline would be 3, but the description adds real meaning: region is expressed in canvas units and exists to zoom into a part, size is the longest side in pixels, and crucially a region is never upscaled past 4 px per canvas unit, a constraint absent from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: a PNG picture of one canvas, rendered the way the app draws thumbnails and link previews. It is clear what is produced and at what scope (single canvas node), though it never explicitly contrasts with the sibling document_picture, so an agent must infer the difference from 'one canvas'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'look at what you drew, then fix it' gives a concrete use case, the visual verification loop, which implies when to reach for this tool. It does not name when to prefer document_picture or when a picture is unnecessary, so there is no explicit exclusion or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
node_updateUpdate canvasBDestructiveIdempotentInspect
Rename a canvas or change its description, size or background colour.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | New title | |
| nodeId | Yes | Node ID | |
| content | No | New description | |
| documentId | Yes | Parent document ID | |
| canvasWidth | No | New canvas width | |
| canvasHeight | No | New canvas height | |
| backgroundColor | No | Canvas background color hex (e.g., #0d1117) |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | Parent node ID | |
| values | Yes | Cell contents for the new row (Markdown), left to right | |
| elementId | Yes | Table element ID | |
| documentId | Yes | Parent document ID |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing padding/truncation to the current column count, automatic element-height growth (no geometry write), transactional execution on current state, concurrency safety without a revision token, and the 20-row rejection cap. These are exactly the operational facts an agent needs before a non-idempotent write.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each carrying distinct information (behavior, geometry side effect, concurrency semantics, hard limit), with the core action front-loaded. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers mutation semantics, side effects, concurrency, and limits thoroughly; with no output schema, the only remaining gap is what the call returns (e.g. new row identity), which is minor for an append operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 real meaning on top by explaining how the 'values' array is interpreted against the table's current column count (padded/truncated), which the schema does not say.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Append one row to a table') and the single-row scope distinguishes it from the sibling table_update_cell and from batch_create_elements. An agent can select it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the description establishes it adds a row rather than modifying cells, which implicitly routes away from table_update_cell, but it never names an alternative or states when not to use it (e.g. when the table already has rows to edit).
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 cellADestructiveIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| col | Yes | Column index, 0-based | |
| row | Yes | Row index, 0-based (row 0 renders as the header) | |
| value | Yes | New cell content (Markdown) | |
| nodeId | Yes | Parent node ID | |
| elementId | Yes | Table element ID | |
| documentId | Yes | Parent document ID |
TDQS
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.
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.
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.
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.
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.
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). Copying the template's pictures needs Premium on the account: without it the document is still created, without the pictures, and the result carries picturesWarning — tell the person.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Custom title for the new document | |
| templateId | Yes | Template ID to clone |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false): it discloses the document-creation quota consumption, the Premium dependency for pictures, the partial-success behavior (document still created without pictures), and the picturesWarning field the caller must surface to the user.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core action is front-loaded in the first clause, followed only by consequences an agent must act on (quota, Premium gating, warning propagation). No sentence is filler despite the density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description usefully names the picturesWarning return signal; the mutation's side effects, entitlement requirements, and failure-degradation mode are all covered. Nothing material is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with only two params, so the schema already documents title and templateId fully. The description adds only indirect meaning ('clone it', 'owned by the current user') and does not clarify where a templateId comes from or whether title defaults from the template name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and outcome: 'Start a whiteboard from a template — clone it into a new document owned by the current user.' The 'from a template' scope clearly separates it from document_create (scratch creation) and from template_get/template_list (read-only template access) without needing the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for when to call: to instantiate a new whiteboard from an existing template, with the ownership and allowance implications spelled out. It does not name alternatives (e.g., template_list to find a templateId, or document_create for a blank document), so it falls short of the explicit when/when-not bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
template_getRead templateARead-onlyIdempotentInspect
Get a template with all its nodes and elements
| Name | Required | Description | Default |
|---|---|---|---|
| templateId | Yes | Template ID |
TDQS
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.
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.
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.
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.
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.
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 templatesARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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.
ungroup_elementsUngroup elementsADestructiveIdempotentInspect
Take every shape of a group out of it, so each moves on its own again. The shapes, their layer order and their revision tokens are otherwise unchanged, and a link on one of them stays on it. The reply lists the ids that left the group.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | Parent node ID | |
| groupId | Yes | The group's id, as element reads show it | |
| documentId | Yes | Parent document ID |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a destructive, idempotent mutation, and the description adds valuable behavioral detail: layer order and revision tokens remain unchanged, links stay attached, and the response lists the ids that left the group. This clarifies the exact scope of the destructive operation beyond what the annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three focused sentences with no wasted words. The operation is front-loaded, followed by precise effects and return behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description states exactly what the reply contains: the ids that left the group. Combined with fully documented parameters and annotations, the definition is complete enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents all three parameters, including nodeId, groupId, and documentId. The description does not add parameter-specific semantics beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: taking every shape out of a group so each moves independently. This is clearly the inverse of the sibling group_elements tool and leaves no ambiguity about the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it by explaining the ungrouping effect, but it does not explicitly name alternatives, prerequisites, or when not to use it. The usage context is clear from the operation itself, but explicit guidance is absent.
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.
2 tool updates
- Added
image_import - Added
image_upload_link_create
7 tool updates
- Changed
batch_create_elements1 field changed- changed
Input schema / properties / elements / descriptionPrevious 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), 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, endMarker (none | arrow | diamond | circle | crow's-foot; default circle at the start, arrow at the end), 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)."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), 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, endMarker (none | arrow | diamond | circle | crow's-foot; default circle at the start, arrow at the end), 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. Image (a picture): pictureKey, naturalWidth and naturalHeight exactly as image_import answered them, and an optional description (what a screen reader says, at most 1000 characters). A key the whiteboard does not hold is refused: import the picture first. An imported key can be used by element_create in the same whiteboard during this session. Give width alone or height alone and the other follows the picture's proportions; with neither, it lands at its natural size fitted to half the default canvas. Node link: isLink, linkTarget (node ID)."
- Changed
batch_update_elements1 field changed- changed
Input schema / properties / updates / descriptionPrevious 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. 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. A read can also show groupId (and groupRotation): group membership changes only through group_elements and ungroup_elements. 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."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. 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. A read can also show groupId (and groupRotation): group membership changes only through group_elements and ungroup_elements. 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. Image elements (type 'image') are pictures. A read returns properties pictureKey, naturalWidth and naturalHeight (the stored picture's size in pixels) and an optional description (what a screen reader says for it) — never the picture's bytes or a link. An update may move, resize or turn a picture and set properties.description (at most 1000 characters; an empty one removes it); width alone or height alone keeps the picture's proportions, both together are taken as given. pictureKey, naturalWidth and naturalHeight never change: an update that changes them is refused. 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."
- Changed
document_share3 fields changed- changed
Input schema / properties / commenterEmails / items / patternPrevious value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$" - changed
Input schema / properties / editorEmails / items / patternPrevious value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$" - changed
Input schema / properties / emails / items / patternPrevious value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
- Changed
document_update2 fields changed- removed
Input schema / properties / folderId / anyOfRemoved value: -[ - { - "type": "string" - }, - { - "type": "null" - } -] - added
Input schema / properties / folderId / typeAdded value: +[ + "string", + "null" +]
- Changed
element_create1 field changed- changed
Input schema / properties / element / descriptionPrevious 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), 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, endMarker (none | arrow | diamond | circle | crow's-foot; default circle at the start, arrow at the end), 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)."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), 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, endMarker (none | arrow | diamond | circle | crow's-foot; default circle at the start, arrow at the end), 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. Image (a picture): pictureKey, naturalWidth and naturalHeight exactly as image_import answered them, and an optional description (what a screen reader says, at most 1000 characters). A key the whiteboard does not hold is refused: import the picture first. An imported key can be used by element_create in the same whiteboard during this session. Give width alone or height alone and the other follows the picture's proportions; with neither, it lands at its natural size fitted to half the default canvas. Node link: isLink, linkTarget (node ID)."
- Changed
element_update1 field changed- changed
Input schema / properties / changes / descriptionPrevious value: -"Fields to update. Geometry and link fields sit at the top level: x, y, width, height, rotation, isLink, linkTarget. 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. A read can also show groupId (and groupRotation): group membership changes only through group_elements and ungroup_elements. 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."New value: +"Fields to update. Geometry and link fields sit at the top level: x, y, width, height, rotation, isLink, linkTarget. 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. A read can also show groupId (and groupRotation): group membership changes only through group_elements and ungroup_elements. 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. Image elements (type 'image') are pictures. A read returns properties pictureKey, naturalWidth and naturalHeight (the stored picture's size in pixels) and an optional description (what a screen reader says for it) — never the picture's bytes or a link. An update may move, resize or turn a picture and set properties.description (at most 1000 characters; an empty one removes it); width alone or height alone keeps the picture's proportions, both together are taken as given. pictureKey, naturalWidth and naturalHeight never change: an update that changes them is refused. 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."
- Changed
node_create_with_elements1 field changed- changed
Input schema / properties / elements / descriptionPrevious 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), 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, endMarker (none | arrow | diamond | circle | crow's-foot; default circle at the start, arrow at the end), 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)."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), 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, endMarker (none | arrow | diamond | circle | crow's-foot; default circle at the start, arrow at the end), 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. Image (a picture): pictureKey, naturalWidth and naturalHeight exactly as image_import answered them, and an optional description (what a screen reader says, at most 1000 characters). A key the whiteboard does not hold is refused: import the picture first. An imported key can be used by element_create in the same whiteboard during this session. Give width alone or height alone and the other follows the picture's proportions; with neither, it lands at its natural size fitted to half the default canvas. Node link: isLink, linkTarget (node ID)."
4 tool updates
- Changed
batch_update_elements1 field changed- changed
Input schema / properties / updates / descriptionPrevious 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."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. 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. A read can also show groupId (and groupRotation): group membership changes only through group_elements and ungroup_elements. 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."
- Changed
element_update1 field changed- changed
Input schema / properties / changes / descriptionPrevious 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."New value: +"Fields to update. Geometry and link fields sit at the top level: x, y, width, height, rotation, isLink, linkTarget. 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. A read can also show groupId (and groupRotation): group membership changes only through group_elements and ungroup_elements. 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."
- Added
group_elements - Added
ungroup_elements
4 tool updates
- Changed
batch_create_elements1 field changed- changed
Input schema / properties / elements / descriptionPrevious 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)."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), 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, endMarker (none | arrow | diamond | circle | crow's-foot; default circle at the start, arrow at the end), 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)."
- Added
document_picture - Changed
element_create1 field changed- changed
Input schema / properties / element / descriptionPrevious 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)."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), 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, endMarker (none | arrow | diamond | circle | crow's-foot; default circle at the start, arrow at the end), 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)."
- Changed
node_create_with_elements1 field changed- changed
Input schema / properties / elements / descriptionPrevious 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)."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), 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, endMarker (none | arrow | diamond | circle | crow's-foot; default circle at the start, arrow at the end), 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)."
3 tool updates
- Changed
batch_create_elements1 field changed- changed
Input schema / properties / elements / descriptionPrevious 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)."
- Changed
element_create1 field changed- changed
Input schema / properties / element / descriptionPrevious 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)."
- Changed
node_create_with_elements1 field changed- changed
Input schema / properties / elements / descriptionPrevious 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)."
1 tool update
- Changed
document_share3 fields changed- added
Input schema / properties / commenterEmailsAdded 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" +} - changed
Input schema / properties / editorEmails / descriptionPrevious value: -"Subset of `emails` to grant edit access (live coediting)"New value: +"Subset of `emails` who can edit (live coediting) and comment" - changed
Input schema / properties / emails / descriptionPrevious 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 tool updates
- Changed
batch_create_elements1 field changed- changed
Input schema / properties / elements / descriptionPrevious 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)."
- Changed
element_create1 field changed- changed
Input schema / properties / element / descriptionPrevious 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)."
- Changed
node_create_with_elements1 field changed- changed
Input schema / properties / elements / descriptionPrevious 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)."
6 tool updates
- Changed
batch_create_elements2 fields changed- changed
Input schema / properties / elements / descriptionPrevious 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)." - changed
Input schema / properties / returnElements / descriptionPrevious 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."
- Changed
batch_update_elements1 field changed- changed
Input schema / properties / updates / descriptionPrevious 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."
- Changed
element_create1 field changed- changed
Input schema / properties / element / descriptionPrevious 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)."
- Changed
element_update1 field changed- changed
Input schema / properties / changes / descriptionPrevious 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."
- Changed
node_create_with_elements2 fields changed- changed
Input schema / properties / elements / descriptionPrevious 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)." - changed
Input schema / properties / returnElements / descriptionPrevious 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."
- Added
node_picture
8 tool updates
- Added
account_get - Changed
batch_create_elements2 fields changed- changed
Input schema / properties / elements / descriptionPrevious 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)." - added
Input schema / properties / returnElementsAdded 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" +}
- Added
batch_reorder_elements - Changed
batch_update_elements1 field changed- changed
Input schema / properties / updates / descriptionPrevious 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."
- Changed
element_create1 field changed- changed
Input schema / properties / element / descriptionPrevious 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)."
- Changed
element_list1 field changed- added
Input schema / properties / summaryAdded 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" +}
- Changed
element_update1 field changed- changed
Input schema / properties / changes / descriptionPrevious 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."
- Changed
node_create_with_elements2 fields changed- changed
Input schema / properties / elements / descriptionPrevious 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)." - added
Input schema / properties / returnElementsAdded 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" +}
5 tool updates
- Changed
batch_create_elements1 field changed- changed
Input schema / properties / elements / descriptionPrevious 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)."
- Changed
batch_update_elements1 field changed- changed
Input schema / properties / updates / descriptionPrevious 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."
- Changed
element_create1 field changed- changed
Input schema / properties / element / descriptionPrevious 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)."
- Changed
element_update2 fields changed- changed
Input schema / properties / changes / descriptionPrevious 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." - changed
Input schema / properties / expectedRevision / descriptionPrevious 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."
- Changed
node_create_with_elements1 field changed- changed
Input schema / properties / elements / descriptionPrevious 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)."
10 tool updates
- Changed
agent_listener_key_create1 field changed- changed
Input schema / properties / documentId / descriptionPrevious 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"
- Changed
batch_update_elements1 field changed- changed
Input schema / properties / updates / descriptionPrevious 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."
- Changed
element_update1 field changed- changed
Input schema / properties / expectedRevision / descriptionPrevious 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."
- Removed
template_create - Removed
template_delete - Removed
template_publish - Removed
template_unpublish - Removed
template_update - Removed
welcome_template_clear - Removed
welcome_template_set
46 tool updates
- First observed
agent_listener_key_create - First observed
agent_listener_key_revoke - First observed
agent_listener_keys_list - First observed
batch_create_elements - First observed
batch_delete_elements - First observed
batch_update_elements - First observed
checklist_toggle_item - First observed
comment_create - First observed
comment_reopen - First observed
comment_reply - First observed
comment_resolve - First observed
comments_list_unresolved - First observed
document_create - First observed
document_delete - First observed
document_get - First observed
document_list - First observed
document_share - First observed
document_update - First observed
element_create - First observed
element_delete - First observed
element_get - First observed
element_list - First observed
element_update - First observed
folder_create - First observed
folder_delete - First observed
folder_list - First observed
folder_rename - First observed
node_create - First observed
node_create_with_elements - First observed
node_create_with_id - First observed
node_delete - First observed
node_get - First observed
node_list - First observed
node_update - First observed
table_append_row - First observed
table_update_cell - First observed
template_clone - First observed
template_create - First observed
template_delete - First observed
template_get - First observed
template_list - First observed
template_publish - First observed
template_unpublish - First observed
template_update - First observed
welcome_template_clear - First observed
welcome_template_set
Publisher details
- Operator
- Graph Knowledge S.R.L.
- Operator website
- https://unpaged.io
- Vendor relationship
- First-party
- Documentation
- https://unpaged.io/mcp
- 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
Give Claude a whiteboard: notes, links, images and diagrams on a board you both see and edit.
A live board you share with Claude, ChatGPT and Cursor: notes, frames, arrows and comments.
Online whiteboard your AI agent draws on: live shared canvases, solo or with your team.
Free whiteboard where people and AI draw together: read cloud boards, draw diagrams, build slides.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to collaboratively read, write, draw, and diagram on a shared real-time whiteboard canvas with live human edits.1MIT
- AlicenseNot gradedqualityDmaintenanceA 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.1MIT
- AlicenseAqualityAmaintenanceEnables a coding agent to sketch explanations step by step on a shared hand-drawn canvas beside the chat, highlighting parts as it talks and reading back anything the user draws or notes. Boards persist per chat and can be searched, saved, and exported as Excalidraw files or PNGs.111,183 npm4MIT
- AlicenseAqualityBmaintenanceLets 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.1975 npm1MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.