Skip to main content
Glama
Sign In
gma3-mcp

gma3-mcp

by nf-s
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Import a fixture type from the library

gma3_patch_import

Imports one fixture type from a console library into the show so it can be patched, with library and duplicate-type pre-checks before committing.

Instructions

Import one fixture type from the console's library into the show, so gma3_patch_add can patch it. file is a file name exactly as gma3_patch_library lists it. Pre-checks (nothing sent on failure): the file is in exactly one library, and the show has no type with the same manufacturer and name (the console would silently add a second one) unless allow_duplicate. Runs one patch session at the copy's fixture-type pool: Import /File "" /Path "" (no dialog; it reads the file from its folder, where Import Library looked the name up in a cached listing that could lack the user library), then waits for exactly one new type and claims it only when its name or manufacturer matches the file. The isolation check compares everything the live patch already has; the new type and the attributes it brings are appended and left out. Then commit and read back: the result has the new type's number, name, GUID and DMX modes with footprints, and attributesAdded. Imports of user-library .xml and WorldServer files are not verified on the console yet (the result warns); user-library .gdtf is (bridge 0.38.0). Requires exclusive: true (see gma3_patch_add for what the patch session means). A committed import has NO UNDO; gma3_patch_remove_type removes an unused type again, but the attributes it brought stay. Needs bridge 0.26.0.

Input Schema

NameRequiredDescriptionDefault
fileYesLibrary file name, e.g. "oppsk@36pcs 4in1 led wall washer.pxml".
sourceNoLibrary the file is in (optional; the file must be in only one library either way).
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.
allow_duplicateNoImport even though the show has a type with the same manufacturer and name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/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 exact console command issued, that no dialog appears, the wait-for-one-new-type and name/manufacturer matching logic, the isolation check, the commit-and-read-back behavior, and that a committed import has NO UNDO (and that attributes survive removal). It even discloses known verification gaps for user-library .xml/WorldServer versus .gdtf.

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?

Purpose is front-loaded in the first sentence, but the remainder is a dense wall of run-on sentences with deeply nested parentheticals (the library-path/cached-listing aside, the isolation-check aside). Every fact is relevant, but the packaging makes it hard to scan for the operational 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 a mutation tool with no annotations and no output schema, the description covers preconditions, execution semantics, return fields (type number, name, GUID, DMX modes with footprints, attributesAdded), failure behavior, undo limitations, and version requirements. Nothing an agent needs to invoke 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 already 100%, so the schema documents all five parameters. The description still adds value by explaining why allow_duplicate exists (the console would silently add a second type) and reinforcing that exclusive must be true or nothing is sent. It does not add much beyond the schema for file/source/verify, which keeps it below a 5.

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 first sentence gives a specific verb and resource ('Import one fixture type from the console's library into the show') and ties it to the downstream sibling gma3_patch_add. An agent can distinguish this from gma3_patch_library (listing) and gma3_patch_add (patching) 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states explicit preconditions for use (file must exist in exactly one library, no existing manufacturer+name match unless allow_duplicate), names the alternative for listing files (gma3_patch_library) and for reversing (gma3_patch_remove_type). It also flags the exclusive:true requirement and the bridge-version dependency, so the agent knows when the call will be refused.

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