Skip to main content
Glama
bdstark

gma3-mcp

by bdstark
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Build a phaser and store it as a preset

gma3_build_phaser

Build a grandMA3 phaser effect from steps or templates into a preset, with optional preview and step-by-step verification before storing.

Instructions

Build a repeatable effect from structured steps and store it into Preset ., reading every step back. Steps: per attribute an absolute and/or relative value (unit percent, or physical: degrees for Pan/Tilt) or a preset called into the step, plus step timing (width, transition, accel, decel). phaser: fixture distribution (phase {from, to} in degrees over the selection grid; from > to runs the other way; repeat {groups|wings|blocks: n} repeats it along X) and playback speed (speed_bpm, measure in beats, speed_master 1-16). These three are kept apart in the plan and the result. Templates (instead of steps): dimmer_chase {on, off, speed_bpm, spread}, alternating_colors {colors: [{red, green, blue} or {preset}], x2, speed_bpm, snap}, pan_tilt {pan, tilt (degrees), speed_bpm, spread}: a relative circle around the current position. preview: true returns the expanded steps and the console commands. fixtures are selected in list order on grid X (or group: a stored group with its grid). Every attribute is checked against every fixture before anything is sent (the console ignores unsupported attributes silently). The effect is built in the console's Preview environment (its own empty programmer; nothing is output) and the operator's Normal programmer is fingerprinted before and after: it is never touched. The built programmer is checked per fixture, step and layer, including the phase per fixture, then stored with the gma3_store_preset rules (mode selective or global, existing refuse|merge|overwrite, step presets embedded) and verified step by step; the Preview programmer is cleared and Preview left in every case. audition_ms (default 0: no playback) calls the stored preset on the fixtures in the Normal programmer, which must be empty, for that long and releases it with ClearAll. Requires exclusive: true (not for preview). If a build is interrupted, gma3_phaser_release leaves Preview. Needs bridge 0.23.0.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoPreset mode (default selective).
nameNoPreset name.
unitNoUnit of the step values (default percent).
groupNoA stored group instead of fixtures; its grid sets the distribution order.
stepsNo2-16 steps.
phaserNoPhaser layers: playback speed, phase distribution, measure, speed master, repetition.
presetYesTarget preset "<pool>.<number>"; an All pool (21-25) takes any attributes.
verifyNoRead the stored preset back step by step (default true).
previewNoOnly check and return the plan and commands (default false).
existingNoWhen the preset exists (default refuse).
fixturesNoFixture ids or ranges, distributed in list order.
templateNoA template instead of steps; see the description for its options.
exclusiveNoRequired (true) unless preview.
audition_msNoPlay the stored effect for this long in the empty Normal programmer, then release it (default 0: no playback; max 30000).

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?

With no annotations, the description carries the full behavioral burden and does so thoroughly: it explains the console Preview environment, that nothing is output, that the Normal programmer is fingerprinted and never touched, per-fixture/step/layer validation, storage rules, step-by-step verification, clearing Preview in every case, exclusive requirement, and bridge version dependency.

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

Conciseness4/5

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

It front-loads the purpose and every sentence is information-dense for a 14-parameter nested tool, but the single unbroken paragraph is difficult to scan. Headings or bullets would improve structure, so it is not a 5 despite containing no obvious waste.

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?

With no output schema and no annotations, the description still covers side effects, state isolation, storage behavior, verification, preview output, exclusive locking, interruption recovery, and version requirements. It is complete enough for an agent to call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds substantial semantics beyond the schema: phase direction when from > to, repeat groups/wings/blocks along X, speed_master 1-16, template option shapes that the schema leaves as additionalProperties, audition release behavior, and the meaning of verify/existing. This is meaningfully richer than the structured fields alone.

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 states a specific verb ('Build') and resource ('phaser'), plus the target preset and read-back behavior. It distinguishes structured steps from templates and is clearly separate from siblings like gma3_store_preset and gma3_phaser_release.

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 concrete usage conditions: preview true returns the plan, exclusive true is required unless previewing, audition_ms requires an empty Normal programmer, and interrupted builds are recovered with gma3_phaser_release. It does not explicitly state when not to use this tool or name alternative effect-building tools, so it falls short of a 5.

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