Skip to main content
Glama
gma3-mcp

gma3-mcp

by nf-s

Build a looping chase and watch one cycle

gma3_build_chase

Builds a chase in a new or empty sequence with one cue per step or preset, sets timing and wrap-around, then verifies playback in Preview without affecting live output.

Instructions

Build a chase into an empty or new sequence (or replace: true to rebuild one, keeping its executor assignments): one cue per step (steps: each a look or looks, a phaser in a look, an optional name and command; or presets: one cue per preset on fixtures, a list or a range {pool, from, to}), every cue Time-triggered after step_seconds (or cycle_seconds / number of steps) with an optional crossfade, and Wrap Around on, so the last cue is followed by the first. 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. sequence_settings and protect_running as in gma3_store_cues. Then, unless observe: false, PLAYS the chase (Goto cue 1, live output) and OBSERVES it over time on the server side (no Lua loop needed), sampling its current cue to verify one cycle: the cue order through the wrap and each step against step_seconds / the sequence's rate. A cycle longer than observe_max_seconds (default 45, at most 120; keep it under your client's request timeout) is observed from a late cue through the wrap instead. The chase is switched off afterwards unless leave_running: 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.

Input Schema

NameRequiredDescriptionDefault
fadeNoCrossfade per cue in seconds (CueInFade); it does not lengthen the step.
nameNoSequence name.
stepsNo2 to 100 steps, one cue each; a step with a command needs no look.
detailNoReturn every item's full result with its steps (default false: one line per item).
verifyNo
observeNoPlay the chase and verify one cycle (default: as verify, true).
presetsNoOne cue per preset on fixtures (instead of steps): a list, or a range {pool, from, to} of the presets that exist, each cue named after its preset.
replaceNoRebuild a sequence that has cues: delete them first (the sequence and its executor assignments stay, checked). Default false: such a sequence is refused.
fixturesNoTarget for every step that does not name its own fixtures.
sequenceYesAn empty or new sequence.
data_poolNoData pool number (DataPool n). Default: the current data pool, as without this parameter.
exclusiveNoRequired (true).
step_secondsNoTime per step (each cue's TrigTime), at least 0.2 s.
cycle_secondsNoTime for the whole loop, divided over the steps (instead of step_seconds).
leave_runningNo
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).
sequence_settingsNoSequence settings applied after the build, as gma3_configure_sequence takes them (priority, off_when_overridden, wrap_around, ...).
observe_max_secondsNo

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, the description carries the full burden and does so thoroughly. It discloses Preview-only operation, separate programmer and selection, ClearAll sent only in Preview, no live output, operator Normal programmer checks, look application order, failure handling that leaves already-stored cues intact, the 2.5.1 readback limitation, exclusive access requirement, playback/observation behavior, and automatic switch-off unless leave_running is true.

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 the main action and its sentences mostly carry operational meaning. However, it is a very long, dense single paragraph with nested clauses and repeated technical asides, making it harder to scan than necessary for an already complex tool.

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 complex 18-parameter tool with no output schema, the description is complete enough to call the tool correctly. It covers build semantics, failure behavior, Preview isolation, verification/observation, timing limits, default behavior, and the shape of the returned result.

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 high at 83%, so the schema already documents most parameters. The description still adds useful meaning: steps versus presets mode, cue-per-step timing, replace semantics that preserve executor assignments, observe behavior and its defaults, observe_max_seconds limits, and compact versus detail result modes.

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 states a specific verb and resource: build a looping chase into an empty/new sequence, or rebuild one with replace: true. It distinguishes the operation from simple cue storage by explaining that it creates one Time-triggered cue per step, enables Wrap Around, and optionally observes a full cycle.

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?

It gives clear applicability conditions: the target sequence should be empty or new, and replace: true is required to rebuild one that already has cues, otherwise the sequence is refused. It does not explicitly compare against the sibling gma3_store_cues beyond referencing shared parameters, so the alternative-routing guidance is good but not complete.

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