DB Planner

Update board layout

update_board

Destructive

Merge a partial board delta. Provide only the ids you are changing. In every id-keyed family (positions, collapsed, drawings, images, groups, links) an omitted id is left unchanged and a null value deletes it. notes is stored whole when provided. For drawings prefer draw, draw_shape and erase_drawings, which mint ids and round for you.

Input Schema

TableJSON Schema

Name	Required	Description
`links`	No	Map of link id to { from, to, label }, or null to delete that link. A cross-link is a connector between ANY two cards, which is how a flowchart step is joined to the table it writes to - neither DBML nor Mermaid can express that, so it lives on the board. from and to are card ids. It stores no geometry; the route is computed from where both cards are. Lowercase id.
`notes`	No	Full notes array (sent whole when changed).
`groups`	No	Map of group id to { name, color, cardIds: [...] }, or null to delete that group. A group is a labelled frame over any cards and is the one construct that spans both document kinds. It stores no geometry: the frame is drawn from where its members are, so moving a card never needs a second write here. Deleting a group does not delete its cards. Mint a lowercase id.
`images`	No	Map of image id to { url, x, y, w, h }, or null to delete that image. Use add_board_image to put a NEW picture on the board; this is for moving, resizing and removing the ones already there.
`drawings`	No	Map of stroke id to a drawing object, or null to delete it. Stored and returned verbatim. kind is "ink" (freehand), "arrow", "rect", "diamond", "ellipse" or "text"; color is "auto" (adapts to the viewer's theme) or "#rrggbb". For ink and arrow, points is a path/vertex list [x,y,x,y,...]; for rect, diamond, ellipse and text it is exactly two OPPOSITE CORNERS [x1,y1,x2,y2], and a text drawing also carries its string.
`collapsed`	No	Map of card id to collapsed flag, or null to remove it.
`positions`	No	Map of card id to {x,y}, or null to remove the card's position.
`projectId`	Yes	Project id (uuid).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`links`	No
`notes`	No
`groups`	No
`images`	No
`drawings`	No
`collapsed`	No
`positions`	No
`updatedAt`	No

TDQS

A4.7/5.0

Behavior5/5

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

The annotation destructiveHint=true already signals mutation, but the description goes further with precise semantics: omitted ids are left unchanged, null deletes, and notes is stored whole. This accurately discloses the destructive and merge-like behavior of the tool beyond what 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.

Conciseness5/5

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

The description is three sentences, front-loads the core merge concept, and each sentence earns its place. It states the key behavioral rule, the whole-notes exception, and the drawing-tool alternative without redundancy or filler.

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

Completeness5/5

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

Given destructiveHint, 100% schema coverage, an output schema, and a rich sibling list, the description covers the essential merge/delete semantics and alternative routing. An agent has enough information to call update_board correctly and avoid destructive mistakes.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds valuable cross-cutting semantics not present in the individual parameter descriptions: the omitted-vs-null distinction across all id-keyed families and the 'notes is stored whole' rule. This lifts it above baseline.

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

Purpose5/5

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

The description opens with 'Merge a partial board delta', a specific verb+resource statement that clearly explains what the tool does. It also differentiates from siblings by explicitly steering drawings to draw, draw_shape, and erase_drawings, so an agent can distinguish it from related board-editing tools without opening each schema.

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

Usage Guidelines4/5

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

The description establishes the partial-update usage pattern ('Provide only the ids you are changing') and gives explicit routing guidance for drawings ('For drawings prefer draw, draw_shape and erase_drawings'). The images parameter schema further points to add_board_image, covering the main alternative cases, though the description itself does not consolidate all alternative routing.

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

All DB Planner tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0

Disambiguation5/5

Every tool targets a distinct resource/action: board retrieval is split into JSON vs image with explicit cross-references, and drawing tools are separated from the generic update_board. Look-alikes like list_documents vs list_diagrams and publish_listing vs use_template are differentiated clearly.

Naming Consistency4/5

Most tools follow a verb_noun pattern: create_project, list_documents, update_board, upsert_org_member. A few noun-only names like my_listings, project_file_counts and template_categories break the pattern, so naming is consistent but not uniform.

Tool Count2/5

40 tools is well beyond the 25+ threshold for a single server, even though the domains are clustered into org/project/document/board/template areas. The large surface will make tool selection and onboarding heavier for an agent than necessary.

Completeness3/5

Core lifecycle coverage for org/project/document/board/template is mostly present, and update_board serves as a flexible escape hatch. However, the board API reads rectangle/diamond/ellipse/free-text drawings and groups/links but only offers explicit create/erase for strokes and arrows; paid template purchase/access is also left unclear.

Resources

Need Help?