Skip to main content
Glama
gma3-mcp

gma3-mcp

by nf-s

Store a list of cues from explicit content

gma3_store_cues

Store multiple grandMA3 sequence cues in one call from explicit looks, presets, or phasers, using create, merge, or overwrite modes with read-back verification.

Instructions

Store several cues of one sequence in one call, each from explicit content: a look (fixtures with presets, intensity, attribute values and/or a phaser) or several looks, with an optional name, timing, trigger, command and note (the cue's Note, e.g. scene metadata a plugin reads) per cue; a cue with a command needs no look (stored empty). mode create refuses (nothing sent) when any of the cues exists; merge and overwrite store into existing cues. The store creates the sequence when it does not exist; sequence_name names it: a new name another sequence has is refused before anything is sent, naming the holder (a duplicate makes lookups by name ambiguous; whether the console would store "#2" is not verified for sequences), unless on_name_taken: "allow_suffix"; in the batch form a name an earlier sequence of the call took counts as taken. fade, delay, out_fade, out_delay, trigger and time given for the call are defaults for every cue (a cue's own keys win; a cue with its own trigger takes none of the call's time); each stored cue's TrigType and TrigTime are read back against what it was given. presets {pool, from, to} (instead of cues): one cue per existing preset of the range on fixtures, named after it, with the call's timing and trigger. replace: true deletes the existing cues first (the sequence object, its settings and executor assignments stay, checked). sequence_settings (as gma3_configure_sequence) are applied after the build in the same call; a priority above ltp lists the running sequences it would switch off (Off When Overridden on), and protect_running: true turns that off on them. Built in the console's Preview environment: its own programmer and selection, so nothing is output and the operator's Normal programmer is untouched (checked before and after). Each cue starts from an empty programmer (ClearAll, sent only in Preview), its looks are applied in order (presets, then intensity, then values; a later look wins on shared fixtures), each look is checked in the programmer (preset links, values per fixture and cell), then the cue is stored. A look that did not apply stops the batch before that cue is stored; the cues already stored stay (nothing is undone or retried) and the result lists every cue with its status. A cue's stored values cannot be read back on 2.5.1; the cue's existence, name, timing, trigger, command and note are. A cue stored without a name takes the preset's name. Requires exclusive: true. The result is compact by default: outcome, verification, one line per cue (look details only for a cue that did not match), the observed cycle as its cue order and step intervals, and only the steps that did not succeed (with a count of the rest); detail: true returns every step, every look and every sample. Batch form (sequences): several sequences, each {sequence, sequence_name, mode, fixtures, cues}, each built in its own Preview session with these checks. 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
cuesNo1 to 100 cues, stored in the order given. Required unless sequences or presets is given.
fadeNoCue in fade, seconds (Part 0 CueInFade).
modeNoRequired (per sequence or for the whole batch).
timeNoTrigger time in seconds (TrigTime).
delayNoCue in delay, seconds.
detailNoReturn every item's full result with its steps (default false: one line per item).
verifyNo
presetsNoOne cue per existing preset of the range on fixtures, numbered from first_cue, named after the preset (instead of cues).
replaceNoDelete every existing cue first, then store (mode create); the sequence and its executor assignments stay.
triggerNogo, time (needs time), follow (optional time), sound, bpm.
fixturesNoDefault target for looks that do not name their own fixtures.
out_fadeNoOut fade, seconds.
sequenceNoSequence number. Required unless sequences is given.
data_poolNoData pool number (DataPool n). Default: the current data pool, as without this parameter.
exclusiveNoRequired (true).
first_cueNoWith presets: the first cue number (default 1).
out_delayNoOut delay, seconds.
sequencesNoBatch form: several sequences, each {sequence, sequence_name, mode, fixtures, cues}.
on_name_takenNoWhen another sequence has sequence_name: refuse (default, nothing is sent) or allow_suffix (store anyway).
sequence_nameNo
protect_runningNoWith a priority above ltp: turn Off When Overridden off on the running sequences the override would switch off (default false: they are listed in a warning).
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).
sequence_settingsNoSequence settings applied after the build, as gma3_configure_sequence takes them (priority, off_when_overridden, wrap_around, ...).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so in detail: exclusive: true is required, everything is built in the console's Preview environment so nothing is output and the operator's programmer is untouched, and nothing is undone or retried on a failed look. It also discloses the 2.5.1 limitation that stored values cannot be read back, and what verification does cover.

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 content is valuable but the form is a single comma-and-semicolon-chained wall of prose with no paragraphing or bullets, which makes it hard to scan for the one clause that matters. Portions repeat, e.g. the batch form is introduced twice ('Batch form (sequences): several sequences...' and 'Batch form: give the list instead...').

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 23-parameter tool with deep nesting and no output schema, the description covers the environment, failure and partial-success semantics, the default cascade, the batch-vs-single relationship, and the return shape (compact by default, detail: true for every step). Nothing an agent needs in order to call it correctly is left out.

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 coverage is already 91%, so the baseline is 3, but the description adds genuinely new meaning: fade/delay/out_fade/out_delay/trigger/time on the call are defaults that a cue's own keys override, and a cue with its own trigger takes none of the call's time. It also explains on_name_taken's refusal-before-send behaviour and that sequence_settings are applied after the build.

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?

Opens with a specific verb and resource plus the scope that separates it from the singular sibling: 'Store several cues of one sequence in one call.' It then defines exactly what a cue is made of (looks, presets, values, phaser, command, note), so an agent knows the tool's job 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 Guidelines3/5

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

Usage conditions are implied rather than stated: mode create refuses existing cues while merge/overwrite store into them, presets is offered 'instead of cues', and the batch form is described as an alternative to the single object. What is missing is explicit routing against the many siblings — it never says when to prefer gma3_store_cue, gma3_edit_cues or gma3_store_cue_part.

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