Skip to main content
Glama

Change elements

update
Destructive

Change properties of floor-plan elements by id — furniture, walls, rooms, labels — and bulk-rename by regex. Use dry run to preview changes before applying.

Instructions

Change fields of elements by id; fields must match the element kind (e.g. furniture mat/opacity/pitch, wall h_end, room auto/ceiling_flat, polyline divider); a part of a group takes name, brand, model_name and url on its own — its size and place belong to the group. anchor on a resize holds one face still (back/front/left/right of the piece, bottom/top, or a plan side) instead of growing around the center, so a run of joinery keeps its back on the wall. stretch=[part ids] on a group resize says what takes the change: the listed parts grow or shrink, every other part keeps its size and moves along (uprights stay 5.8 cm while the opening between them grows); without it all parts scale together. dry=true answers what it would do — changed fields, clearances around each piece it touches (negative: cm it would sit inside what it faces), findings resolved and created as issues_resolved/issues_new [{ids, kind, extent|cm|over}] with the same kind check_layout gives (only real defects: a piece resting or built in is never listed), and issues_changed for a clash that stays but grows or shrinks (extent_was) — without writing anything, so a size can be tried before it is applied; dry="summary" answers the same decision without listing the parts a group rebuilds. Otherwise the reply names what changed. rename {pattern, to, what: names|labels} renames in bulk by a regex (Rust syntax, (?i) for any case, $1 in to): every piece name — parts of groups included — or label text that matches, in one step; with dry it lists them first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
vNoPlan version (tab) to write to; switches to it first
dryNoTry it without applying: reports what would change, the clearances around every piece it touches, and which layout and ergonomics findings it would resolve or create. Nothing is written and the user's window does not move
itemsNoThe elements to change, one object each: `id` and the fields to set
renameNoRename in bulk by a rule instead of listing items: every name (pieces and the parts of groups) or label text matching `pattern` has it replaced by `to`, in one undoable step

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
vNoPlan version written to, when there are several
okNoAlways true
dryNoNothing was written
idsNoIds created or touched
revNoPlan revision
goneNoIds removed, or their count
textNoThe reply as written
addedNoIds added, or their count
scoreNoScore [before, after]
changedNo{id, from, to} per element changed; a count past 20
resolvedNoFindings settled
unchangedNoAsked ids that came out as they were: {id, now}
clearancesNoFree floor around touched pieces, by id
issues_newNoLayout issues created
propertiesNoProject properties changed
added_countNoRoots added
annotationsNoAnnotation switches {from, to}
score_scopeNoDisciplines scored
new_findingsNoFindings created
changed_countNoRoots changed
issues_changedNoLayout issues resized
unchanged_noteNoWhy they did not change
issues_resolvedNoLayout issues settled
findings_changedNoFindings changed
acceptance_cleanupNoAcceptances orphaned, and the calls that clear them

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the destructiveHint annotation, the description explains real behavioral nuances: group part size/place belongs to the group, anchor holds a face still, stretch controls which parts absorb a resize, dry=true reports clearances and issues without writing, and rename rewrites every matching name in one step. This is substantial added transparency 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.

Conciseness4/5

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

The description is front-loaded with the core operation and every clause covers a distinct, necessary behavior: group parts, anchor, stretch, dry, and rename. It is dense and somewhat run-on as one large paragraph, but there is no filler or redundancy; better formatting would improve scanability without adding content.

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 mutating tool with many element kinds, the description covers the field-selection rules, group semantics, resize behavior, dry-run decision support, and bulk rename. The schema carries the remaining parameter details, and the response behavior is described well enough that an agent can call update correctly.

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

Parameters5/5

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

Even with 100% schema coverage, the description adds significant parameter meaning: it defines valid field/element-kind combinations, explains the effect of anchor and stretch with concrete examples, and spells out what dry=true returns in terms of clearances and issue findings. The description enriches the schema rather than merely repeating it.

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 states a specific verb and resource: 'Change fields of elements by id', and immediately distinguishes this from sibling tools like create, delete, or move. It also adds useful constraints with element-kind examples, so an agent can tell exactly what operation this tool performs.

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 gives clear context for the main cases: field updates by id, group part behavior, anchor/stretch for resizes, dry runs for previewing changes, and bulk rename by regex. It does not explicitly name sibling tools as exclusions, but it frames the important decision points well enough for an agent to choose correctly.

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