Skip to main content
Glama
gma3-mcp

gma3-mcp

by nf-s

Store the programmer into a preset with explicit storage rules

gma3_store_preset

Stores current programmer content into a chosen preset with explicit mode, fixture scope, merge/overwrite handling, and optional read-back verification.

Instructions

Store the current programmer content into Preset .. Prepare the programmer first (gma3_select, gma3_set_attribute/color/position, At Preset ... for embedding); this tool only stores. Explicit rules: mode selective | global | universal (never the pool default: a default store resolves a mode conflict silently and can keep one fixture's values), or force global | universal for a forced conversion of an existing preset (removes its selective, or selective and global, data; needs existing: "merge"). existing: refuse (default) | merge | overwrite. fixtures: the scope; every active programmer value must belong to these fixtures (a fixture includes its cells) and each must have one; attributes (optional): exact attribute filter (an activation group, e.g. all ColorRGB_*, is activated as a whole); layers (default [absolute]; also relative, fade, delay, phaser) must cover every value's layers. Anything else in the programmer is refused, because the console stores every active value regardless of the selection. Also refused: universal mode with values that differ between fixtures, embed without a preset reference in the programmer, attributes a feature-group pool's input filter would drop (store into an All pool 21-25 or pass input_filter: false), a locked preset, and a name another preset of the same pool already has (the console keeps names unique within a pool and would store it as "#2"; the pool's names are read once per pool and call, compared case-insensitively, the holder is named, and storing a preset again under its own name is no collision): on_name_taken: refuse (default) | allow_suffix (store anyway; a "#" read-back is expected, with a warning, not a mismatch). embed (default false) stores references to the presets active in the programmer; matricks (default false) the selection MAtricks; keep_activation (default false); input_filter overrides the operator default for this store only. The command always carries /Programmer /Active, the mode, /Merge or /Overwrite, /Embed, /MAtricks, /KeepActivation and /NoConfirmation, so the operator's store preferences decide nothing and are not changed (read before and after); Look cannot be overridden per store, so the tool refuses while the operator's StoreLook preference is on. Requires exclusive: true (not for preview). verify (default true) reads the stored rows back and checks each programmer value by mode, value, layers and reference, unexpected content, the preset's mode, dependencies (recursively; incomplete inspection is reported) and that the store preferences are unchanged. Needs bridge 0.22.0. Batch form (presets): each preset from explicit content instead of the programmer: fixtures (ids or ranges: the target and the scope) with presets, intensity and/or values, or looks. They are built one by one in the console's Preview environment (its own programmer; the operator's Normal programmer and the output are not touched, checked before and after): from an empty Preview programmer, each look is checked right after its commands, then this tool's store, checks and read-back run there. A preset that fails does not stop the others; a name refused as taken fails only its preset, and a name an earlier preset of the call was stored under counts as taken. 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
modeNoPreset mode the data is stored in.
nameNoPreset name.
embedNoStore references to the presets active in the programmer (default false: plain values).
forceNoForced conversion of an existing preset instead of mode (needs existing: merge).
detailNoReturn every item's full result with its steps (default false: one line per item).
layersNoData layers the values may carry (default [absolute]).
presetNoTarget preset "<pool>.<number>", e.g. "4.12" or "23.1". Required unless presets is given.
verifyNoRead back and check the stored content (default true).
presetsNoBatch form: several presets, each from explicit content (built in Preview; the programmer is not stored).
previewNoOnly read, check and return the planned command (default false).
existingNoWhat to do when the preset exists (default refuse).
fixturesNoScope: fixture ids or "a Thru b" ranges; every programmer value must belong to them. Required unless presets is given (it is then the default target of every preset's content).
matricksNoStore the selection MAtricks into the preset (default false).
data_poolNoData pool number (DataPool n). Default: the current data pool, as without this parameter.
exclusiveNoRequired (true) unless preview: nobody else changes the programmer while the tool runs.
attributesNoExact attribute filter: the programmer may hold only these attributes, and each must be present.
input_filterNoOverride the operator's preset input-filter default for this store only.
on_name_takenNoWhen another preset of the pool has the name: refuse (default, nothing is sent) or allow_suffix (the console stores "<name>#2").
keep_activationNoKeep the stored values active in the programmer (default false).
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).

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?

No annotations are supplied, so the description carries the full burden and does so thoroughly: it lists the exact command flags appended (/Programmer /Active, mode, /Merge or /Overwrite, /Embed, /MAtricks, /KeepActivation, /NoConfirmation), states that operator store preferences are neither consulted nor changed, that exclusive: true is required, that bridge 0.22.0 is a prerequisite, and that verify read-back checks values, layers, references, dependencies recursively and preference invariance. Destructive consequences of force (removes selective, or selective and global data) and overwrite/merge semantics are spelled out rather than left implicit.

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 first sentence is well front-loaded, but the remainder is a single dense paragraph of several hundred words with inline parentheticals carrying critical constraints (name-collision comparison rules, preview-programmer semantics, batch ordering). Everything roughly earns its place, yet the lack of sentence-level structure or bullets makes key rules easy to miss on a single read.

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 20-parameter tool with no annotations and no output schema, the description covers what an agent needs: prerequisites, all refusal cases, mutation semantics, exclusivity, verification behaviour, batch isolation in the Preview programmer, per-item failure handling and stop_on_failure interaction. Nothing material for correct invocation appears missing.

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?

With schema coverage at 100% the baseline is 3, but the description adds meaning the schema does not: mode must never be left to the pool default because a default store resolves a mode conflict silently, attributes act as an activation group taken as a whole, layers "must cover every value's layers", and force requires existing: merge. It does not restate trivialities, though its parameter discussion is buried in prose rather than mapped cleanly to argument names.

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 opening sentence names a specific verb, resource and destination: "Store the current programmer content into Preset <pool>.<number>", and immediately scopes it ("this tool only stores") so it is distinguishable from gma3_apply_preset, gma3_store_cue and gma3_store_group. The distinction between the single form and the batch form (built in Preview from explicit content) is also stated, so an agent can route correctly without opening the schema.

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

Usage Guidelines5/5

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

Explicit preconditions are given (prepare the programmer first via gma3_select, gma3_set_attribute/color/position, At Preset for embedding), along with when-not guidance (refuses when the operator's StoreLook preference is on; refuses on locked presets, name collisions, universal mode with differing fixture values). Alternatives are named for the specific failure modes, e.g. store into an All pool 21-25 or pass input_filter: false when a feature-group pool's input filter would drop attributes, and on_name_taken: allow_suffix when a suffix store is acceptable.

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