Skip to main content
Glama
Sign In
gma3-mcp

gma3-mcp

by nf-s
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Set trigger, timing and names on a range of cues

gma3_edit_cues

Edit existing cues in a grandMA3 sequence in one call, applying trigger, timing, names, or commands to cues selected by list, range, or all.

Instructions

Edit existing cues of a sequence in one call: the same trigger (TrigType/TrigTime), the same timing (Part 0 CueInFade, CueInDelay, CueOutFade, CueOutDelay, SnapDelay), one name per cue, and/or a command (command for all, commands one per cue). A switch from Time to another trigger sets each cue's TrigTime to 0 on the console, and a switch back keeps the 0: the result lists the wiped times (wipedTrigTimes); keep_times: true saves them in the sequence's Note first ([gma3-mcp trigtimes 1=2.5 ...]), and trigger time with restore_times: true sets them back and removes them from the note. Choose the cues with exactly one of cues (a list), from/to (a range, either end optional) or all: true; names are given in cue order, one per cue. Refuses (nothing sent) when the sequence or a listed cue does not exist, or the number of names differs. One Set() per property, cue by cue; stops at the first failure and reports every cue. Reads the written properties back per cue. Stored values and the programmer are not touched.

Input Schema

NameRequiredDescriptionDefault
toNo
allNo
cuesNo
fadeNoCue in fade, seconds (Part 0 CueInFade).
fromNo
timeNoTrigger time in seconds (TrigTime).
delayNoCue in delay, seconds.
namesNoOne name per selected cue, in cue order.
verifyNo
commandNoThe same command (Part 0 Command) on every selected cue.
triggerNogo, time (needs time), follow (optional time), sound, bpm.
commandsNoOne command per selected cue, in cue order.
out_fadeNoOut fade, seconds.
sequenceYes
data_poolNoData pool number (DataPool n). Default: the current data pool, as without this parameter.
out_delayNoOut delay, seconds.
keep_timesNoWith a trigger other than time: save the trigger times the switch sets to 0 in the sequence's Note.
snap_delayNo
restore_timesNoWith trigger time: set each cue's saved trigger time from the sequence's Note (time is the fallback) and remove them from it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/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 most of it well: it discloses the Time-trigger wipe-to-0 side effect, the Note-based save/restore mechanism, per-property Set() ordering, abort-on-first-failure with per-cue reporting, read-back, and that stored values and the programmer are untouched. Remaining gaps are the return payload beyond wipedTrigTimes and any permission or rate considerations.

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?

Every sentence carries real information, but it is delivered as one dense semicolon-chained paragraph mixing purpose, side effects, selection rules, failure behavior and return behavior. Front-loading is good; scannability is not, and a reader has to re-parse clauses to find the selection rule.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 19-parameter mutation tool with no annotations and no output schema, the definition covers the risky behaviors, the naming contract, and the destructive Time-wipe consequence, which is the critical part. It is not fully complete: verify, data_pool and sequence semantics are undocumented and the response shape is only partially described.

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?

At 63% schema coverage the description meaningfully compensates, explaining the mutually exclusive cue selectors, that names are positional and one per cue, that trigger accepts go/time/follow/sound/bpm with time implications, and that command vs commands differ in cardinality. It leaves verify, sequence and data_pool unexplained, but the added semantics clearly exceed the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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: 'Edit existing cues of a sequence in one call', and enumerates exactly which properties (trigger, timing, name, command) can be changed in bulk. It is clear what the tool does, but it never names the single-cue siblings gma3_set_cue_timing, gma3_set_cue_trigger or gma3_store_cue, so the agent must infer the boundary itself.

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?

Strong in-tool guidance: the agent is told to select cues with exactly one of cues, from/to or all, and that calls are refused when the sequence or a listed cue is missing or the name count mismatches. The keep_times/restore_times pairing is explained as a when-to-use contract. What is missing is routing guidance between this bulk editor and the single-cue siblings.

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