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

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 4, 2026

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

Disambiguation4/5

Most tools target a distinct resource and action, and the descriptions clearly explain boundaries. However, list_diagrams/list_documents and get_board/get_board_image are two pairs that both concern the same underlying resource, so an agent could initially select the wrong one without reading carefully.

Naming Consistency4/5

Nearly all tool names are snake_case verb_noun pairs such as create_project, update_document, and unpublish_listing, which is very consistent. The exceptions are bare 'draw' and the non-pattern 'whoami', so it is not a perfect 5.

Tool Count2/5

With 38 tools, the surface exceeds the 25+ threshold and spans orgs, projects, documents, board drawing, membership, and marketplace publishing. While each subdomain is individually reasonable, the aggregate is heavy and likely to overwhelm an agent; several related actions could be grouped or exposed more sparingly.

Completeness4/5

The set covers the main lifecycle: org/project/document CRUD, board rendering and editing, member management, and template publish/use/update. Minor gaps remain—there is no get_project single-resource read, and groups/links/notes are manipulated only through the generic update_board rather than dedicated tools—but these are workable.

Resources

Need Help?