Skip to main content
Glama
bdstark

gma3-mcp

by bdstark
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Add fixtures to the patch

gma3_patch_add

Add fixtures of a selected type and DMX mode at consecutive FIDs, patching from a start address or 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 operator resolves it at the console (Menu > Patch, Save and Exit or Discard and Exit). Needs bridge 0.19.0. verify reads the new FIDs back: present, patch addresses, name (when given) and mode.

Input Schema

TableJSON 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).
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.6/5.0
Behavior5/5

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

With no annotations, the description fully carries the behavioral burden: read-only pre-checks, patch edit copy workflow, isolation check, exclusive use requirement, no undo, ~10s duration, failure handling with copyLeftOpen, bridge version, and verify readback. This is comprehensive for a mutation tool.

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?

Front-loads the core action and then details preconditions, workflow, and failure behavior in a single dense paragraph. Long but largely justified by the tool's complexity; minor repetition (exclusive requirement appears twice) slightly reduces efficiency.

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?

Given the high complexity, absent annotations, and no output schema, the description covers purpose, usage conditions, behavioral workflow, failure modes, timing, and version dependency. Nothing critical for correct invocation 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 the baseline is 3, but the description adds inter-parameter semantics beyond individual schema entries: address vs findFreeFrom alternative, unpatched when neither is given, consecutive FID block, and what verify reads back. This meaningfully supplements the schema.

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 'Add' and resource 'fixtures to the patch', with scope including one fixture type, one DMX mode, consecutive FIDs, and address/findFreeFrom/unpatched modes. It clearly distinguishes itself from patch modification or removal siblings by focusing on adding new fixtures.

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?

Explains conditions for address vs findFreeFrom vs unpatched, the exclusive requirement, and pre-checks. However, it does not explicitly name alternative sibling tools like gma3_patch_set or gma3_patch_remove for modifying or removing existing fixtures, leaving that routing to inference.

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