Skip to main content
Glama
gma3-mcp

gma3-mcp

by nf-s

Move fixtures under a grouping fixture (or back to the top level)

gma3_patch_move

Moves fixtures into a grouping fixture's children or back to the stage top level while preserving FIDs, addresses, names, groups, presets, and 3D placement.

Instructions

Moves fixtures into a grouping fixture's children (parent: its FID), e.g. the rig under the MA Show Start's grouping fixtures FID 1-8, or back to the stage's top level (parent: "root"). FIDs, addresses, names, groups and presets are kept. The console asks how to keep the 3D placement: position "absolute" (default) keeps each fixture's place and rotation in the world; "relative" keeps its offset from the parent (the fixture moves with the parent's position and rotation). With a parent at the origin and unrotated both are the same. Pre-checks (nothing sent on failure): every FID exists, holds no fixtures itself, all share one parent (the top level or one top-level grouping fixture) in one stage, and the target is another top-level grouping fixture of that stage (type Grouping) or the top level. Move fixtures with different parents in one call each. In the copy: Cut, ChangeDestination, Paste, and the console's "Move Fixtures" dialog answered by the bridge, each step checked before the next (a failure cancels the dialog). The isolation check compares fixtures without their list positions, because a move renumbers the fixtures after the moved ones. Runs one patch session through the patch edit copy, never a dialog: read-only pre-checks (command line at Root, the copy closed, so nobody is in the Patch menu, no modal open, plus the tool's own checks), then enter the copy, apply the change there, an isolation check, commit, and read back. Requires exclusive: true. Patch changes need exclusive use of the console: the isolation check compares fingerprints of the copy and the live patch, left out the touched FIDs, over several seconds. It is best-effort detection of someone else's changes, not a guarantee, and on a mismatch nothing is committed and the copy is left open for the operator. A committed patch change has NO UNDO (Oops does not revert it). Takes about 10 s (mostly the isolation check). When a session cannot be finished, the copy is closed again only if it provably holds no change; otherwise the result says copyLeftOpen: true and the command line stays inside the edit patch with no Patch window open: the operator keeps the copy by typing ChangeDestination Root at the console (no way to discard it without the Patch menu is known). Needs bridge 0.19.0; a session in a stage with a Name needs bridge 0.45.0. verify compares each fixture with its state before the session: parent, address, name, its groups, and its 3D pose (absolute: in the world; relative: to the parent). A clean success lists each fixture as {fid, parent: [before, after]} in items (detail: true for the poses, groups and rows). Needs bridge 0.42.0.

Input Schema

NameRequiredDescriptionDefault
fidsYesFixture IDs to move (1-256), all with the same parent.
detailNoReturn the full result on a success too: every step's detail and each fixture's state before and after (default false: a clean success, committed and read back matched or not requested, lists one entry per fixture in items; anything else is always returned in full).
parentYesFID of the target grouping fixture, or "root" for the top level of the stage.
verifyNoRead the patch back after the commit and compare (default true).
positionNoHow the 3D placement is kept (default "absolute": the place and rotation in the world).
exclusiveNoRequired, must be true: confirms nobody else uses the console while this runs (see the description). Without it the call is refused and nothing is sent.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

No annotations exist, so the description carries the whole burden and does so well: it discloses that a committed change has no undo, that the run takes about 10 s, that the isolation check is best-effort, and exactly what happens on a mismatch (nothing committed, copy left open). The copyLeftOpen recovery procedure is unusually thorough. It falls short of a 5 only because the three separate bridge-version requirements are scattered across the text and the failure taxonomy is spread over several paragraphs rather than consolidated.

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

Conciseness2/5

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

The purpose and the position semantics are front-loaded, but the remainder is a dense run-on paragraph that repeats itself: the exclusive requirement is stated twice, and bridge versions 0.19.0, 0.45.0 and 0.42.0 appear in three unrelated places. The console-dialog internals (Cut, ChangeDestination, Paste) are implementation detail an agent cannot act on, and the same information could be conveyed in roughly half the length.

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 destructive, exclusive-lock, multi-second patch mutation with no output schema, the description covers what an agent needs: preconditions, what is preserved, the verification comparison, the success shape in items, and recovery when a session cannot finish. Nothing material is missing.

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 every parameter is already documented, and the description largely restates those semantics (parent, position, verify, detail). It does add real value on position: the absolute-versus-relative distinction is explained in terms of world placement versus parent offset, plus the edge case that both are identical with an unrotated parent at the origin. Otherwise the description adds little beyond the schema, so baseline 3 is right.

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 first sentence gives a specific verb and resource with the exact addressing scheme: fixtures are moved into a grouping fixture's children by FID, or to the top level with parent "root". It also states what is preserved (FIDs, addresses, names, groups, presets), which separates it from attribute-level patch siblings such as gma3_patch_set or gma3_patch_retype.

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?

Usage conditions are spelled out: all moved FIDs must share one parent, fixtures with different parents need separate calls, and exclusive: true is mandatory or the call is refused. It does not name a sibling tool as the alternative for adjacent operations (e.g. changing a fixture's address), so the when-not guidance is implicit rather than explicit.

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

Deploy Server

Other Tools