Skip to main content
Glama
Sign In
gma3-mcp

gma3-mcp

by nf-s
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Read a preset's stored content and references, or a pool's storage defaults

gma3_preset

Inspect grandMA3 preset contents to see stored fixture/attribute modes, values, steps, phaser layers, fades, dependencies, and pool defaults for debugging or verifying show data.

Instructions

Read-only. preset: "." returns what the preset actually stores: per fixture and attribute the mode the value was stored in (selective; global, held by the lowest FID of a fixture type; universal, one holder), value (percent) or steps (each with absolute/relative, width, trans, accel, decel and the preset it integrates; absent layers are the console defaults width/trans 100, accel/decel 0), the phaser layers speedBpm, phase (degrees), measure (beats) and speedMaster (absent: 60 BPM, phase 0), fade/delay, and the source preset of an embedded value; plus PresetMode, StoredData, lock, how many objects reference it, and its dependencies (embedded sources) followed recursively with validity (a deleted source is an invalid dependency) and whether that inspection was complete. pool: returns the pool's default mode and input filter and the operator's store preferences (the defaults a store would otherwise use). Needs bridge 0.22.0.

Input Schema

NameRequiredDescriptionDefault
poolNoPreset pool number (1-9 feature groups, 21-25 All pools).
presetNoPreset as "<pool>.<number>", e.g. "4.12".
data_poolNoData pool number (DataPool n). Default: the current data pool, as without this parameter.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the safety and behavior burden and does well: it declares 'Read-only', explains recursive dependency inspection, validity of deleted sources, and inspection completeness. It also states the bridge version requirement, though it does not cover error handling or permission requirements.

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 description is front-loaded with 'Read-only.' and all details are relevant, but it is written as a single dense paragraph with nested parentheticals and long lists. It is information-rich but could be restructured for easier scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only tool with no output schema, the description explains the returned preset data and pool defaults in substantial detail, including dependency behavior. The main gap is that it does not clarify how the optional parameters interact when multiple are supplied or omitted.

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 coverage is 100%, so the schema already documents all three parameters, and the description adds mainly mode semantics for 'preset' and 'pool'. It does not mention the 'data_pool' parameter, so the baseline of 3 is appropriate.

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 opens with 'Read-only' and then states exactly what the preset mode returns versus what the pool mode returns, giving a specific verb+resource pair. It distinguishes itself from sibling write tools like gma3_store_preset or gma3_apply_preset by framing the operation as inspection of stored content and storage defaults.

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 gives clear context for each parameter mode: 'preset' inspects a preset's stored data and references, while 'pool' returns pool defaults and operator store preferences. It does not name alternatives or explicitly say when not to use the tool, but the mode descriptions make usage clear.

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