Skip to main content
Glama

Move elements

move
Destructive

Shift design elements by dx/dy cm or to a target [x,y]; the first ID lands there while others retain offsets, with an optional dry-run preview.

Instructions

Move elements by dx,dy cm, or to=[x,y]: the first id (a piece or a label) goes there and the rest keep their offsets. dry=true answers what it would do without writing anything, dry="summary" answers it short; see update.

Input Schema

NameRequiredDescriptionDefault
dxNoShift in x, cm (with `dy`)
dyNoShift in y, cm (with `dx`)
toNoInstead of dx/dy: where the first id goes, [x,y] as reads give it (a piece's or a label's center); the others keep their offsets
dryNoTry it without applying; see `update`
idsYesThe elements to move together
joinedNoDrag endpoints of walls joined to moved walls (default true)

Output Schema

NameRequiredDescriptionDefault
vNo
okNo
dryNo
idsNo
revNo
goneNo
textNo
addedNo
scoreNo
changedNo
resolvedNo
clearancesNo
issues_newNo
propertiesNo
added_countNo
annotationsNo
score_scopeNo
new_findingsNo
changed_countNo
issues_changedNo
issues_resolvedNo
findings_changedNo
acceptance_cleanupNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.2.0
    • changedInput schema / $defs / Dry / description
      Previous value: -"How much of a dry run to answer with: `true` everything it would change, `\"summary\"` the decision — pieces moved, roots, clearances, findings, score"New value: +"How much of a dry run to answer: `true` everything it would change, `\"summary\"` the decision — pieces moved, roots, clearances, findings, score"
  2. Changed25 schema fields changedv3.0.0
    • changedInput schema / $defs / Dry / description
      Previous value: -"Runs an edit against a copy of the plan and reports what it would do. Trying a size used to mean applying it, reviewing, and undoing — a round trip that showed in the user's window and burned a revision each time. The copy has no history and is thrown away, so nothing of that happens. How much of a dry run to answer with. `true` answers with everything it would change; `\"summary\"` answers with the decision — how many pieces move, which roots, the clearances, the findings and the score — because a group that rebuilds lists ninety-seven parts for a choice that fits in five lines"New value: +"How much of a dry run to answer with: `true` everything it would change, `\"summary\"` the decision — pieces moved, roots, clearances, findings, score"
    • changedInput schema / $defs / Point2 / description
      Previous value: -"[x, y] in centimeters; x grows right, y grows down"New value: +"[x, y] cm"
    • removedOutput schema / properties / acceptance_cleanup / description
      Removed value: -"Acceptances orphaned, and the calls that clear them"
    • removedOutput schema / properties / added / description
      Removed value: -"Ids added, or their count"
    • removedOutput schema / properties / added_count / description
      Removed value: -"Roots added"
    • removedOutput schema / properties / annotations / description
      Removed value: -"Annotation switches {from, to}"
    • removedOutput schema / properties / changed / description
      Removed value: -"{id, from, to} per element changed; a count past 20"
    • removedOutput schema / properties / changed_count / description
      Removed value: -"Roots changed"
    • removedOutput schema / properties / clearances / description
      Removed value: -"Free floor around touched pieces, by id"
    • removedOutput schema / properties / dry / description
      Removed value: -"Nothing was written"
    • removedOutput schema / properties / findings_changed / description
      Removed value: -"Findings changed"
    • removedOutput schema / properties / gone / description
      Removed value: -"Ids removed, or their count"
    • removedOutput schema / properties / ids / description
      Removed value: -"Ids created or touched"
    • removedOutput schema / properties / issues_changed / description
      Removed value: -"Layout issues resized"
    • removedOutput schema / properties / issues_new / description
      Removed value: -"Layout issues created"
    • removedOutput schema / properties / issues_resolved / description
      Removed value: -"Layout issues settled"
    • removedOutput schema / properties / new_findings / description
      Removed value: -"Findings created"
    • removedOutput schema / properties / ok / description
      Removed value: -"Always true"
    • removedOutput schema / properties / properties / description
      Removed value: -"Project properties changed"
    • removedOutput schema / properties / resolved / description
      Removed value: -"Findings settled"
    • removedOutput schema / properties / rev / description
      Removed value: -"Plan revision"
    • removedOutput schema / properties / score / description
      Removed value: -"Score [before, after]"
    • removedOutput schema / properties / score_scope / description
      Removed value: -"Disciplines scored"
    • removedOutput schema / properties / text / description
      Removed value: -"The reply as written"
    • removedOutput schema / properties / v / description
      Removed value: -"Plan version written to, when there are several"
  3. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false; the description adds genuinely new behavioral detail by explaining that dry=true returns the full set of changes without writing and dry="summary" returns a shortened decision view. It does not spell out side effects of moving (e.g., what breaks when walls are detached), which keeps it below a 5.

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 dense sentences, front-loaded with the primary action and both modes, with the dry-run semantics trailing. No filler, and the shorthand style suits the tool's technical domain.

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

Completeness4/5

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

An output schema exists so return values need no explanation, and annotations cover the safety profile. The description covers both modes and the dry-run escape hatch, but omits the `joined` behavior and any sibling routing, which leaves a small gap for a 6-parameter destructive tool.

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%, so all six parameters are already documented, and the description's explanation of 'first id goes there, rest keep offsets' largely restates the `to` parameter's own description. The `joined` parameter is never mentioned in the description. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb (move) and resource (elements) and distinguishes its two operating modes: relative shift via dx/dy versus absolute placement via to=[x,y]. It does not differentiate itself from the many sibling mutation tools (arrange, place, update), but the core action is unambiguous.

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?

Explains the two invocation modes and the dry-run variants, which is useful selection guidance within the tool. However, 'see `update`' is an unexplained pointer with no condition attached, and there is no guidance on when to choose move over siblings like arrange or place.

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