Skip to main content
Glama
gma3-mcp

gma3-mcp

by nf-s

Store a group with an explicit selection grid

gma3_store_group

Creates or overwrites a fixture group with explicit grid-cell order, expanding row, rectangle, mirror, or rows arrangements; previews and verifies the stored selection before use.

Instructions

Create or overwrite Group from a fixture list with explicit selection-grid cells. The cells are the order: the console stores a group in patch order and MAtricks, phasers and At a Thru b distribute along the grid, not along the list. Give either items ([{fixture, x, y, z}]) or an arrangement helper that expands into such a list: row (along one axis), rectangle (row by row, optional serpentine), mirror (left and right halves listed outside-in, right[i] mirrors left[i], optional centre gap), rows (one row per list, each spread over width cells). preview: true returns the expanded list, bounds, gaps and shared cells without sending anything. Rules: duplicate fixtures are refused (the console silently ignores a second selection); shared cells are refused unless allow_shared_cells: true; gaps and offsets are kept (preserve_grid_positions, default true; false lets a recall at the origin compact them); a fixture and its own cells (501, 501.1) are separate items; missing fixtures are refused. An existing group needs overwrite: true (its name is kept unless name is given); a locked group is refused. A name another group already has is refused before anything is sent, naming the holder (the pool's names are read once per call, compared case-insensitively; a duplicate makes lookups by name ambiguous, and whether the console would store "#2" is not verified for groups); on_name_taken: refuse (default) | allow_suffix (store anyway; a "#" read-back is a warning, not a mismatch). In the batch form a name an earlier group of the call was stored under counts as taken. Requires exclusive: true (not for preview): the tool clears the console's fixture selection (programmer values are kept), selects each fixture after its own 'Grid x/y/z' command, checks that the selection is exactly the plan before 'Store Group', sets PreserveGridPositions and the name, then (verify, default true) reads the stored group back and recalls it at Grid 0/0/0 to check order and cells (a one-fixture group is recalled at the cursor, so its recall checks the fixture and the read-back its cell), and finally clears the selection and returns the cursor to 0/0/0. Grid cells are not physical stage positions. Needs bridge 0.21.0. rows: rows of different lengths spread over one width (align spread, start or center); ranges run in their own direction ("402.36 Thru 402.1"). Batch form: give the list instead of the single object's fields; the other arguments are defaults for every item (an item's own fields win). Each item gets the single form's checks and read-back, and its own outcome; items run in order, nothing is retried, an unknown outcome stops the rest, and the result has one line per item (detail: true for every step).

Input Schema

NameRequiredDescriptionDefault
nameNoGroup name (a new group is otherwise named by the console).
groupNoGroup number (1-9999). Required unless groups is given.
itemsNoExplicit list; each fixture once. The cells define the order distributions follow (the console stores the group in patch order).
detailNoReturn every item's full result with its steps (default false: one line per item).
groupsNoBatch form: several groups, each {group, name, items | arrangement, overwrite, ...}, stored one after the other.
verifyNoRead back and recall-check the stored group (default true).
previewNoOnly expand, analyse and check; send nothing (default false).
data_poolNoData pool number (DataPool n). Default: the current data pool, as without this parameter.
exclusiveNoRequired (true) unless preview: nobody else uses the console's selection while the tool runs.
overwriteNoReplace an existing group (default false: refuse).
arrangementNoHelper that expands into the explicit list (see preview).
on_name_takenNoWhen another group has the name: refuse (default, nothing is sent) or allow_suffix (store anyway).
stop_on_failureNoBatch form: stop at the first item that does not succeed (default false: independent items go on; an item on an object an earlier item failed on is skipped either way).
allow_shared_cellsNoAllow two fixtures in one cell (default false: refuse).
preserve_grid_positionsNoStore with PreserveGridPositions (default true).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full behavioral burden and does so in detail: it discloses that exclusive mode clears the console's fixture selection while keeping programmer values, selects fixtures, checks the plan before storing, reads back and recalls for verification, then clears selection and returns the cursor to 0/0/0. It also lists refusal conditions, overwrite and name-collision behavior, and the bridge version prerequisite.

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

Conciseness3/5

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

The description is front-loaded with purpose and covers necessary complexity, but it is a single very dense paragraph with long run-on sentences. It is appropriately sized for a 15-parameter tool, yet it would be easier to scan if structured into shorter sections or bullets.

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 the tool's complexity, including batch operation, multiple arrangement forms, verification, preview, and no output schema, the description is complete enough for an agent to call it correctly. It covers prerequisites, side effects, failure modes, batch ordering, and partial return behavior such as preview output and one-line-per-item results.

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, but the description adds meaningful semantics beyond the schema: it explains why cell order matters, how arrangement helpers expand, how duplicate fixtures and shared cells are handled, and how batch arguments act as defaults. Some parameters such as data_pool and stop_on_failure are left largely to the schema.

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 a specific verb and resource: "Create or overwrite Group <n> from a fixture list with explicit selection-grid cells." It also explains the distinguishing concept that the cells define the stored order, which separates it from generic group or selection tools.

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 using items versus arrangement helpers, preview mode, overwrite mode, and the batch form. It does not explicitly compare against sibling tools such as gma3_selection_grid or gma3_place_fixtures, so it falls short of full when-to-use-vs-alternatives guidance.

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