Skip to main content
Glama
gma3-mcp

gma3-mcp

by nf-s

Add fixtures to the patch

gma3_patch_add

Adds one or more fixtures of one type and DMX mode at consecutive FIDs, patching them to a DMX address, the first free block, or unpatched, with pre-checks and read-back verification.

Instructions

Add count fixtures of one fixture type and DMX mode at consecutive FIDs from fid, patched consecutively from a DMX address (address, or the first free block found from findFreeFrom), or unpatched when neither is given. Pre-checks (nothing sent on failure): the FIDs are free, the whole block is free and fits inside one universe, the mode has a single DMX break. Fixtures are added at the top level of a stage (default: the first stage). Runs one patch session through the patch edit copy, never a dialog: read-only pre-checks (command line at Root, the copy closed, so nobody is in the Patch menu, no modal open, plus the tool's own checks), then enter the copy, apply the change there, an isolation check, commit, and read back. Requires exclusive: true. Patch changes need exclusive use of the console: the isolation check compares fingerprints of the copy and the live patch, left out the touched FIDs, over several seconds. It is best-effort detection of someone else's changes, not a guarantee, and on a mismatch nothing is committed and the copy is left open for the operator. A committed patch change has NO UNDO (Oops does not revert it). Takes about 10 s (mostly the isolation check). When a session cannot be finished, the copy is closed again only if it provably holds no change; otherwise the result says copyLeftOpen: true and the command line stays inside the edit patch with no Patch window open: the operator keeps the copy by typing ChangeDestination Root at the console (no way to discard it without the Patch menu is known). Needs bridge 0.19.0; a session in a stage with a Name needs bridge 0.45.0. verify reads the new FIDs back: present, patch addresses, name (when given) and mode. With count above 1 a clean success lists each new fixture as {fid, name, address} in items (detail: true for the full rows).

Input Schema

NameRequiredDescriptionDefault
fidYesFirst fixture ID; the block uses fid .. fid+count-1, all of which must be free.
modeYesDMX mode number or name within that type.
nameNoOptional name for the new fixtures (default: the console's naming).
typeYesFixture type number or name, as gma3_patch_types lists it.
countNoNumber of fixtures (1-256, default 1).
stageNoStage name (default: the first stage). A stage with a Name needs bridge 0.45.0.
detailNoReturn the full result on a success too: every step's detail and each fixture's state before and after (default false: a clean success, committed and read back matched or not requested, lists one entry per fixture in items; anything else is always returned in full).
verifyNoRead the patch back after the commit and compare (default true).
addressNoDMX start address "U.AAA" (e.g. "2.001"); the block must be free and inside one universe.
exclusiveNoRequired, must be true: confirms nobody else uses the console while this runs (see the description). Without it the call is refused and nothing is sent.
findFreeFromNoInstead of address: use the first free block from this "U.AAA".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations, the description carries the whole burden and does so thoroughly: it discloses the read-only pre-checks, the edit-copy session flow, that a committed patch change has NO UNDO, the exclusive-console requirement, the best-effort isolation check and its ~10 s cost, and the copyLeftOpen failure mode with recovery instructions. Bridge version requirements and verify/read-back behaviour are also stated explicitly.

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?

Purpose is front-loaded in the first sentence and virtually every clause carries operational information, with no filler. The remainder is a dense run-on block with nested parentheticals that would read better as bullets, so it is efficient but not optimally structured.

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 mutating tool with no annotations and no output schema, the description covers what is missing elsewhere: success/failure shapes, the `items`/`detail` return contract, commit/undo semantics, timing, session-abort behaviour and bridge version gates. An agent has everything needed to call it and interpret the outcome.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 11 parameters and the baseline is 3. The description adds genuine meaning only for the address/findFreeFrom/neither relationship and the count>1 `items` return shape, which the schema does not convey; the rest of the parameter meaning is already in structured fields.

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 opening sentence gives a precise verb and resource plus scope: add `count` fixtures of one type and mode at consecutive FIDs, patched at `address`, at the first free block from `findFreeFrom`, or unpatched. The 'add' semantics implicitly separate it from gma3_patch_set/patch_move/patch_retype, but no sibling is named explicitly, so it falls short of full sibling differentiation.

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 clearly specifies the three addressing paths and the exact conditions under which each applies ('address, or the first free block found from findFreeFrom, or unpatched when neither is given'), plus the exclusive:true prerequisite. There is no explicit 'use X instead when…' exclusion against neighbouring patch tools, which keeps it at 4 rather than 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