Skip to main content
Glama

Update zone

update_zone

Change a zone's name, color, position, or size on a spatial canvas in one undoable step, allowing reversible board edits.

Instructions

Rename, recolour or move/resize a zone. One undoable step.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
nameNo
rectNo
colorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnly=false, destructive=false, idempotent=false and closed-world, so the safety profile is covered. The description adds a genuinely new behavioral fact beyond the annotations: the edit is a single undoable step, which matters for agents chaining mutations with undo_last_change. It still omits whether omitted fields are preserved (patch vs replace semantics).

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

Conciseness5/5

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

Two short sentences, operations listed first and the undo caveat second, with no filler. Every clause adds information.

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

Completeness3/5

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

For a mutation tool with a nested rect object, 0% schema description coverage and no output schema, the description is adequate but thin: it says what fields exist but not the rect units/origin, the hex color convention, or whether unspecified fields are left untouched. Annotations carry safety, so the remaining shortfall is mostly parameter-level.

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

Parameters3/5

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

Schema description coverage is 0%, so the description carries the burden and partially meets it by mapping rename→name, recolour→color, move/resize→rect. However it never mentions the required id parameter, nor the expected format of color (hex) or the x/y/width/height shape of rect, so half the parameter semantics remain undocumented.

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

Purpose4/5

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

The description names the resource (zone) and the three concrete mutations it supports: rename, recolour, move/resize. That is a specific verb+resource statement that an agent can act on, though it never explicitly distinguishes itself from sibling zone tools such as create_zone or delete_zones beyond the obvious naming.

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

Usage Guidelines3/5

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

Usage is only implied by the tool name and the operations listed; there is no statement of when to choose update_zone over update_nodes or create_zone, no preconditions, and no exclusions. An agent can infer this is the edit path for an existing zone, but nothing in the text confirms that.

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