Skip to main content
Glama
gma3-mcp

gma3-mcp

by nf-s

List, create, rename and remove patch stages

gma3_patch_stages

List, create, rename, or remove venue stages in grandMA3's live patch, applying changes through an exclusive patch-edit session with read-back verification.

Instructions

Stages (areas of the venue, e.g. "Main Floor", "Basement"; gma3_patch_add takes one by name). action "list" (read-only, the live patch): each stage's index (its position), number, name and nameKind ("default": an empty Name or one set to "Stage ", which read alike; "explicit": any other), fixtures (all, sub-fixtures included) and topLevel, whether it has a Spaces list and how many spaces. "create" {name} or {names: [...]}: appends stages (Acquire, then Name; the bridge deletes what it appended on any problem). "rename" {stage, name}. "remove" {stage}: only an empty stage (no fixtures, no spaces) and never the first or the only one; stages after it move up a place, and one with a default name then reads its new number (refused when that is another stage's name; an unreadable Fixtures, Spaces or children list is a refusal too). stage: the index or the name. Names: no characters the console strips (" . , and the like), trimmed, unique among the stages ignoring case (a stage may change the case of its own name). Pre-checks (nothing sent on failure) read the live stages. 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. The isolation check leaves out only the stages the change touches (appended or removed ones, and the Name and number of a renamed stage and of those moving up). verify reads the stages back from the live patch: names in order, no two alike, and every stage's fixture count (an unreadable count makes it unavailable, not matched). Removing uses Delete on Stages, not verified on a console yet. Needs bridge 0.48.0; the bridge's own re-check of a removal (unreadable lists, a name clash) needs bridge 0.49.0.

Input Schema

NameRequiredDescriptionDefault
nameNocreate: the new stage's name; rename: the new name.
namesNocreate: several new stages at once (1-32), in order.
stageNorename / remove: the stage's index (position, from list) or its name.
actionYes"list" (read-only), "create", "rename" or "remove".
verifyNoRead the patch back after the commit and compare (default true).
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. Not needed for list.

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 patch-edit-copy session flow, the isolation check and its best-effort limits, that committed changes have NO UNDO, that a failure can leave the copy open (copyLeftOpen: true) with the operator's recovery command, the ~10 s runtime, and bridge version requirements per feature. These are exactly the traits an agent cannot infer from structured fields.

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 front-loaded with the resource definition and per-action contracts, but the whole thing is a single dense block of roughly 400 words with long nested clauses that are hard to parse on a first read. Some material is restated, notably the isolation check's exclusion rules and the bridge version numbers appearing in two places, which could be tightened.

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 a multi-action mutation tool with no output schema, the description covers preconditions, locking, verification, timing, version gating, and failure/recovery states, including what the result reports when a session cannot finish. There is no obvious gap an agent would need to call this correctly.

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 real meaning: 'stage' accepts either an index or a name, names must be trimmed, unique case-insensitively, and free of console-stripped characters, and verify is defined as reading names in order plus per-stage fixture counts from the live patch. The nameKind/fixtures/topLevel return fields are also explained, which the schema cannot do.

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 description names the resource (patch stages, defined as venue areas) and enumerates the four actions with their payloads, so an agent knows exactly what each action does. It also positions itself against siblings by noting that gma3_patch_add takes a stage by name, and it distinguishes stages from the fixtures/spaces they contain.

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?

Usage is spelled out per action: list is read-only, create appends, rename needs {stage, name}, remove only works on an empty stage and never the first or only one. It also states exclusive:true is required and that a refusal sends nothing. It stops short of explicitly routing the agent to gma3_patch_list or gma3_patch_add as alternatives for adjacent tasks, which keeps it below 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