Skip to main content
Glama

Change a board

edit_board

Changes a board read at "base". All ops apply, or none. IDs: s12, f3, k4 (or a name). Ops: add, set, text (html, find/with, insert, delete, append), move, delete, connect, frame, arrange, cluster, mermaid, z, group, ungroup, card, send, sync, deck, board.set. send puts cards and stickies (named, or a frame's) in a new sheet or a sheet's table, a Card column linking back to each card; it goes alone in its call, and replies with the sheet's link. sync brings sent cards and their sheet rows in step both ways (the side that changed wins; if both did, the board's, and the reply lists the clashes; a row deleted in the sheet unlinks its card); alone in its call. deck makes a new Slides deck beside the board, a slide per frame (its title, its stickies as cards, clusters as columns, cards as rows with owner and status, pictures placed); the board is unchanged; alone in its call, and replies with the deck's link and which frame each slide came from. "in": "f2" puts items in a frame; "@2" is what op 2 of this call made. A person's change since base is refused, naming them; text find/with still lands. "intent" lights up items first; "answers": "a3" closes an ask. Replies with each op's new IDs and notes (overlaps, frames grown, items outside frames).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "doc": "<doc>"
    },
    "name": "edit_board"
  }
}

Input Schema

NameRequiredDescriptionDefault
docYesThe doc's link or its code.
keyNoA retry key, up to 64 characters. Default: one made from the request.
opsNoAt most 500 edits (an op naming several items counts each), applied in order; "@2" is what op 2 made, "@2.1" its second item. {"op":"add","items":[{"kind":"sticky","text":"Flaky tests","color":"pink","in":"f2"}]} (kinds: sticky, shape, text, image, frame, card, embed; "near": "s5", or "at": [x,y] or [x,y,w,h], in the frame's units with "in" (past its edge the frame grows, moving frames beside it along, and the reply says so); leave out the size: a shape is sized round its words, a text wraps to its frame (or to the width you give); colours: yellow orange red pink violet blue cyan teal green lime grey white, a shape's "color" fills it; a shape's "shape": rect round ellipse diamond triangle parallelogram hexagon star cylinder cloud arrow process decision terminator document data) {"op":"set","ids":["s12"],"props":{"color":"pink","tags":["ops"],"status":"Done","owner":"Priya","due":"2026-11-04","points":3}} (null removes; "w", "h" or "at" resize or place it, a frame too) · {"op":"text","id":"s12","find":"Tues","with":"Tuesday"} ("html", "insert", "delete" with "expect", "append"; "field": text, desc, label) {"op":"move","ids":["s12"],"in":"f3"} ("near", "by": [dx,dy], or "to": [x,y] in the frame they're in, as "at" is; with "in", in that frame; "in": "board" for board units) · {"op":"delete","ids":["s40"]} (a frame takes its contents only with "contents": true) · {"op":"connect","from":"h2","to":"h3","label":"if green"} {"op":"frame","title":"Actions","ids":["s3","s7"]} (wraps them; no ids: an empty frame) · {"op":"arrange","in":"f2","as":"grid"} (row, column, tree, flow, mind; or "ids"; "skip": ["t1"] leaves items where they are; a swimlane flow: {"op":"arrange","in":"f6","as":"flow","lanes":[{"title":"Site lead","ids":["h1","h2"]},{"title":"Trades","ids":["h3"]}]}, a band per lane with its title in a header cell at the left, left to right along the connectors, loops round the outside; a frame laid out fits what it holds, moving frames beside it along; arranging again unchanged changes nothing) A mind map: round shapes sharing a "mind" key, each joined from its parent: [{"op":"add","items":[{"kind":"shape","shape":"round","mind":"m1","text":"Q1 launch","at":[0,0,240,72]},{"kind":"shape","shape":"round","mind":"m1","text":"Website","at":[0,0,200,52]}]},{"op":"connect","from":"@0.0","to":"@0.1","ends":["none","none"]},{"op":"arrange","ids":["@0.0","@0.1"],"as":"mind"}] (root left, children right, as the app lays out one typed with Tab and Enter; arrange again after adding nodes) A flowchart from Mermaid: {"op":"mermaid","in":"f1","text":"flowchart TD\n A([Start]) --> B{Approved?}\n B -->|Yes| C[Order]\n B -->|No| D[Revise] --> B"} (shapes, connectors with their labels, subgraphs as frames, laid out top-down or left-right as the app lays out a pasted one; "near" or "at" too; flowchart or graph TD/LR/BT/RL, node shapes [ ] ( ) ([ ]) [( )] (( )) { } {{ }} [/ /] > ], links --> --- -.-> ==> ~~~ --o --x <--> with |text| or -- text -->, subgraph … end, direction; at most 300 nodes; lines not taken (styles, classes, clicks) are named in the reply) {"op":"cluster","in":"f1","groups":[{"title":"Testing","ids":["s3","s9"]},{"title":"Releases","ids":["s4"]}]} (you pick the groups; Dockito lays them out as labelled columns filling the frame's width, stickies sized to their words, titles given room to wrap; "as": "blocks" for blocks; "fill": false one column each, "fit": false keeps sizes) {"op":"z","ids":["s3"],"to":"front"} · {"op":"group","ids":["s3","s4"]} · {"op":"ungroup","ids":["s3"]} · {"op":"card","ids":["s12"]} (stickies into cards) · {"op":"board.set","props":{"title":"Sprint 42 retro","statuses":["To do","Doing","Done"]}} {"op":"send","in":"f3","to":{"new":"Sprint 42 actions"}} (or "ids": cards, stickies, frames; "to": {"doc": "<a sheet's link>", "table": "Actions"} adds rows to that tab or table; stickies become cards first; columns Card, Title, Owner, Status, Due, Points, Votes, Tags, Frame; at most 500 cards; alone in its call) {"op":"sync"} (the whole board; or "in": "f3", "ids": cards or frames, "doc": one sheet's link; at most 500 cards; alone in its call) {"op":"deck","in":["f1","f2"],"to":{"new":"Sprint 42 retro"},"theme":"Harbor"} (a new deck, a slide per frame in that order; no "in": every frame in reading order; no "to": the board's title; themes Harbor, Harbor Dark, Paper, Slate; at most 40 frames; what a slide can't fit is counted on it and named in the reply; alone in its call)
baseNoThe version you read: v N in get.
noteNoWhy, in a few words. Shown in changes and History.
dryRunNoWork it out and answer, saving nothing.
intentNoLight up items before a change, for people watching: {"items": ["s12", "f2"], "say": "Grouping the stickies"} (20 items, 20 s). "say" alone (a first call, nothing on the board yet) shows the line at the top of the board; "@0" names what this call makes. Alone (no ops) it lights them before a long think.
answersNoThe ask this change answers ("a12"), from get with "asks": taken first, done when the change lands. With no intent, the ask's items light up.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only say readOnly=false / destructive=false / openWorld=false; the description adds conflict semantics (naming the person who changed it), atomic all-or-nothing application, the retry key, original-side effects ("the board is unchanged" for deck), item limits (500 ops, 500 cards, 40 frames), and what the reply lists (overlaps, grown frames, clashes, links). Note the delete op sits uneasily with destructiveHint=false, but the description is explicit about the behavior rather than contradicting it, and recovery paths exist via restore/history.

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

Conciseness3/5

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

Front-loads the essential facts (base, atomicity, ID syntax) but then collapses into a single dense paragraph of semicolon-joined op descriptions with no line breaks or grouping. Large blocks duplicate text already present in the ops schema description, so length outruns added value.

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

Completeness5/5

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

For a tool this complex with 8 parameters, nested ops and no output schema, the definition still covers outcomes: the reply carries each op's new IDs and notes, send/deck return sheet and deck links, clashes are listed. Between description and schema an agent has what it needs to call and interpret the result.

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

Parameters3/5

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

Schema coverage is 100% and each property already documents itself in depth, so the baseline applies. The description does add cross-op semantics for "in": "f2" and "@2" references and the ID shorthand (s12, f3, k4, or a name), but much of the op detail restates what the ops schema already says.

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

Purpose5/5

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

Opening sentence gives a specific verb and resource ("Changes a board") plus a concurrency precondition ("read at 'base'") and an atomicity guarantee ("All ops apply, or none"). The board noun cleanly separates it from the edit_doc/edit_sheet/edit_slides siblings, and the op inventory that follows pins down the scope of the mutation.

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

Usage Guidelines4/5

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

Gives real call-shape rules: send, sync and deck must go "alone in its call"; a person's change since base is refused while text find/with still lands; intent alone lights items before a long think. It does not say when to prefer edit_board over apply or the other edit_* siblings, which keeps it out of the top band.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources