Skip to main content
Glama
Sign In
gma3-mcp

gma3-mcp

by nf-s
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Delete fixtures from the show

gma3_patch_remove

Removes fixtures by FID from the grandMA3 patch, including their cue and group references, with pre-checks and optional read-back verification.

Instructions

Delete fixtures by FID from the patch, removing them from the show (with everything that refers to them, e.g. their values in cues and groups: the console handles references). Fixtures with sub-fixtures are refused. Pre-check (nothing sent on failure): every FID exists and has no sub-fixtures. 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 FIDs back and checks they are gone.

Input Schema

NameRequiredDescriptionDefault
fidsYesFixture IDs to delete (1-256).
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.

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 supplied the description carries the full burden and does so: it discloses the no-undo semantics ('Oops does not revert it'), the cascading deletion of cue/group references, the ~10 s runtime, the session sequence (copy, isolation check, commit, read-back), and the failure state 'copyLeftOpen: true' with the operator recovery command. It also honestly frames the isolation check as best-effort detection rather than a guarantee.

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 first sentence front-loads purpose well, but the remainder is a dense run-on chain of clauses, with some restatement (exclusive is explained both here and in the schema description) and parenthetical asides that slow parsing. The length is defensible for a destructive, no-undo operation, but the structure could be tightened into distinct paragraphs.

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 destructive, session-based mutation tool with no annotations and no output schema, the description covers the full lifecycle: prerequisites, pre-checks, what is destroyed, commit semantics, failure/partial-failure results, and bridge version requirements. An agent has what it needs to decide, call, and interpret the outcome.

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 beyond the schema: 'verify reads the FIDs back and checks they are gone' explains what verification actually does, and the isolation-check/fingerprint explanation gives operational substance to 'exclusive' beyond 'confirms nobody else uses the console'.

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 ('Delete fixtures by FID from the patch, removing them from the show') plus a hard constraint (sub-fixture fixtures refused). That is enough to separate it from gma3_patch_remove_type and gma3_patch_set without opening any schema.

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 clear when-not conditions (sub-fixtures refused, exclusive must be true or the call is refused and nothing is sent) and describes the pre-check gate before anything is transmitted. It does not explicitly name an alternative tool or say when to prefer another patch operation, so it stops short of 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