Skip to main content
Glama
bdstark

gma3-mcp

by bdstark
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Store the programmer into a preset with explicit storage rules

gma3_store_preset

Stores current grandMA3 programmer content into a specified preset, with explicit mode, fixture scope, layers, and existing-preset behavior; unmatched values are refused.

Instructions

Store the current programmer content into Preset .. Prepare the programmer first (gma3_select, gma3_set_attribute/color/position, At Preset ... for embedding); this tool only stores. Explicit rules: mode selective | global | universal (never the pool default: a default store resolves a mode conflict silently and can keep one fixture's values), or force global | universal for a forced conversion of an existing preset (removes its selective, or selective and global, data; needs existing: "merge"). existing: refuse (default) | merge | overwrite. fixtures: the scope; every active programmer value must belong to these fixtures (a fixture includes its cells) and each must have one; attributes (optional): exact attribute filter (an activation group, e.g. all ColorRGB_*, is activated as a whole); layers (default [absolute]; also relative, fade, delay, phaser) must cover every value's layers. Anything else in the programmer is refused, because the console stores every active value regardless of the selection. Also refused: universal mode with values that differ between fixtures, embed without a preset reference in the programmer, attributes a feature-group pool's input filter would drop (store into an All pool 21-25 or pass input_filter: false), a locked preset. embed (default false) stores references to the presets active in the programmer; matricks (default false) the selection MAtricks; keep_activation (default false); input_filter overrides the operator default for this store only. The command always carries /Programmer /Active, the mode, /Merge or /Overwrite, /Embed, /MAtricks, /KeepActivation and /NoConfirmation, so the operator's store preferences decide nothing and are not changed (read before and after); Look cannot be overridden per store, so the tool refuses while the operator's StoreLook preference is on. Requires exclusive: true (not for preview). verify (default true) reads the stored rows back and checks each programmer value by mode, value, layers and reference, unexpected content, the preset's mode, dependencies (recursively; incomplete inspection is reported) and that the store preferences are unchanged. Needs bridge 0.22.0.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoPreset mode the data is stored in.
nameNoPreset name.
embedNoStore references to the presets active in the programmer (default false: plain values).
forceNoForced conversion of an existing preset instead of mode (needs existing: merge).
layersNoData layers the values may carry (default [absolute]).
presetYesTarget preset "<pool>.<number>", e.g. "4.12" or "23.1".
verifyNoRead back and check the stored content (default true).
previewNoOnly read, check and return the planned command (default false).
existingNoWhat to do when the preset exists (default refuse).
fixturesYesScope: fixture ids or "a Thru b" ranges; every programmer value must belong to them.
matricksNoStore the selection MAtricks into the preset (default false).
exclusiveNoRequired (true) unless preview: nobody else changes the programmer while the tool runs.
attributesNoExact attribute filter: the programmer may hold only these attributes, and each must be present.
input_filterNoOverride the operator's preset input-filter default for this store only.
keep_activationNoKeep the stored values active in the programmer (default false).

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 thoroughly: it discloses the exact command flags appended, that operator preferences are neither consulted nor changed, the StoreLook refusal case, the exclusive:true requirement, verification behavior, and the bridge version dependency. This is unusually complete 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the body is a dense wall of run-on sentences mixing rules, defaults, and refusals without visual structure. Every clause is informative, yet the presentation makes it harder to scan than the content warrants.

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 15-parameter mutation tool with no annotations and no output schema, the description covers preconditions, per-parameter interactions, refusal cases, and verification semantics. An agent has everything needed to invoke it 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 already 100%, so the baseline is 3, but the description adds meaning beyond the schema: it explains why mode is never the pool default (a conflict resolves silently), what force conversion removes, that fixtures must each carry a value, and how layers/attributes interact with activation groups and pool input filters.

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?

Opens with a specific verb and resource: 'Store the current programmer content into Preset <pool>.<number>.' It also immediately distinguishes itself from the preparation siblings by stating 'this tool only stores', so an agent can tell it apart from gma3_set_attribute/color/position and the other store_* tools.

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?

Explicitly names the prerequisite sequence (gma3_select, gma3_set_attribute/color/position, At Preset for embedding) and states the tool 'only stores'. It further enumerates refusal conditions and when to use force/embed/existing, giving clear when-and-when-not guidance.

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