Skip to main content
Glama
gma3-mcp

gma3-mcp

by nf-s

Assign an object to an executor

gma3_assign_to_executor

Assign a sequence or macro to a grandMA3 executor on a specific page, with safety checks, optional replacement of a different object, and label-based renaming.

Instructions

Assign a sequence or macro to an executor on an explicit page: give sequence for compatibility or object (Sequence , Macro , optionally DataPool ). Sends 'Assign At Page .'. Before sending anything it checks read-only that the sequence and the page exist and what the executor currently holds; an executor holding a different object is only replaced with replace: true (otherwise the call fails with the previous assignment in the result), and an executor that already holds this sequence is left alone (alreadyAssigned: true, no command sent). Optional label: sends 'Label Page . ""' after assigning. On grandMA3 an executor has no label of its own: it shows its assigned object's name, so this RENAMES THE ASSIGNED OBJECT itself, everywhere it appears (pools, other executors). If labelling fails after the assignment the outcome is partial. Does not change the fixture selection or the programmer and never sends Go/On/Off/Toggle or any playback keyword; whether the console changes the selected sequence on assignment is not controlled by this tool. verify (default true) reads the executor back and compares the assigned object by address, name and class and, when a label was given, the executor's displayed name and the object's own Name; executor configuration, fader/key functions and playback state are NOT verified. Mutations from this server are serialised, but another operator or client can still change the executor between the inspection and the assignment. Batch form (assignments): each target executor is checked to be empty or to hold that sequence already, unless replace is given for that item (or for the whole call); a target listed twice is refused. 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
pageNoExecutor page number (1-9999). The page must already exist; the tool does not create pages. Required unless assignments is given (it may then be a default for every item).
labelNoOptional new name for the assigned sequence (an executor displays its assigned object's name). Names must not contain \ " $ & * ? , . ; ^ { } | ~ (the console strips them); leading/trailing spaces are trimmed.
detailNoReturn every item's full result with its steps (default false: one line per item).
objectNoOne Sequence or Macro reference by number, optionally DataPool <n> qualified. Give object or sequence, never both. Must exist.
verifyNoRead the executor (and the sequence, when labelled) back and compare (default true).
replaceNoReplace an executor that holds a different object (default false: fail and report the previous assignment).
executorNoExecutor number on that page: 101-190 (keys), 201-290 (faders), 301-390 and 401-490 (knobs), plus the Xkeys 191-198 and 291-298. Required unless assignments is given.
sequenceNoSequence number to assign (must exist). Give sequence or object; omit single-source fields with assignments.
data_poolNoData pool number (DataPool n). Default: the current data pool, as without this parameter.
assignmentsNoBatch form: several assignments, each {sequence, page, executor, replace, label}; page may be given once for all.
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.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: it discloses the pre-flight read-only inspection, the failure-with-previous-assignment outcome, the partial outcome when labelling fails, what verify does and explicitly does NOT verify (config, fader/key functions, playback state), that mutations are serialised, and that a concurrent operator can invalidate the inspection.

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 content is valuable but delivered as one dense paragraph with heavy parenthetical nesting and several run-on sentences; batch behaviour is introduced twice. A bulleted or sectioned layout would make the preconditions, side effects, and batch rules far easier to scan and would front-load the executor/sequence/page essentials.

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 an 11-parameter, annotation-free mutation tool with no output schema, the definition covers preconditions (page/sequence must exist), side effects, failure and partial-failure outcomes, verification scope, concurrency risk, and per-item batch semantics with ordering and stop rules — nothing an agent needs to call it correctly is 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?

Schema coverage is 100%, so baseline is 3, but the description adds semantics the schema does not: replace gates overwriting, verify defaults true with a stated comparison basis, label renames the underlying object show-wide, and batch items inherit call-level fields while their own fields win, with duplicate targets refused and stop_on_failure skipping previously failed objects.

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?

States a specific verb and resource: 'Assign a sequence or macro to an executor on an explicit page', including the exact command it emits ('Assign <object> At Page <p>.<e>'). It also distinguishes itself from the sibling gma3_label_executor by warning that labelling here renames the assigned object rather than the executor.

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?

Gives rich conditional guidance: use replace: true when an executor holds another object, the call leaves an already-assigned sequence alone, and the batch form is described as an alternative shape with its own rules. It stops short of naming sibling tools to route to (e.g. gma3_executor_settings, gma3_label_executor) for related tasks.

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