Skip to main content
Glama
Sign In
gma3-mcp

gma3-mcp

by nf-s
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Set several attributes (a look) in one call

gma3_set_attributes

Set multiple fixture attributes and intensity on explicit fixtures or the current selection in one call, with optional attribute pre-checks and programmer verification.

Instructions

Set a whole look on one target in one call: intensity (At <value>, percent) and/or several attributes, each Attribute "<name>" At Absolute [<unit keyword>] <value>, in the order given. Stops at the first command the console rejects (partial result). Target is explicit: fixtures OR use_selection: true; with fixtures, ClearSelection and then a select (see gma3_set_attribute). Never clears programmer values. Note: setting one colour attribute activates the fixture's whole colour group in the programmer (the other mix channels at their defaults), so the programmer can hold more rows than attributes sent. Small explicit targets are pre-checked against the fixture types' attributes (check_attributes); the programmer is read back and every targeted fixture (and cell) is compared per attribute in the unit sent (verify), as gma3_set_attribute does. Serialised against this server's other mutations only.

Input Schema

NameRequiredDescriptionDefault
valuesNoAttributes to set (up to 32), each once.
verifyNoRead the programmer back after setting (default true): every targeted fixture must hold the value, compared in the unit it was sent in (percent of the attribute range, tolerance 0.5 %). A fixture without the attribute is reported as a mismatch. Needs plugin 0.3.2 or newer; older plugins yield verification 'unavailable'.
fixturesNoExplicit target: fixture IDs/ranges ("1 Thru 5", "1 + 3 + 5 Thru 8", "Fixture 101.1") or a group ("Group 5"). Exactly one of fixtures / use_selection is required.
intensityNoIntensity 0..100 percent, sent as `At <value>` (the Dimmer attribute).
use_selectionNoApply to the fixtures currently selected on the console (explicit opt-in). Fails before sending when nothing is selected.
add_to_selectionNoWith `fixtures`: keep the fixtures already selected and add the target to them, so previously selected fixtures ALSO receive the values (explicit opt-in). Default false: ClearSelection is sent first so exactly the named fixtures are targeted. ClearSelection only deselects; programmer values are never cleared.
check_attributesNoWith `fixtures` resolving to at most 8 fixtures (default true): check each fixture type's attribute list first and fail before sending when a fixture lacks the attribute. Skipped for groups and larger targets.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/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 discloses important behavior: partial results on rejection, selection clearing behavior, the colour-group activation side effect, pre-checking, readback verification, and serialisation against other mutations. These details go well beyond what a bare mutation description would provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The purpose is front-loaded and the content is dense but useful. It is a single long paragraph, and some selection behaviour details are repeated through references, but there is little outright waste.

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?

Given a 7-parameter mutation tool with no annotations and no output schema, the description supplies the missing operational context: target rules, side effects, failure behavior, verification, and mutation serialisation. An agent has enough information to call 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 description coverage is already 100%, so the baseline is 3. The description adds useful command-level meaning: intensity is sent as `At <value>` in percent, attributes use `Attribute "<name>" At Absolute [<unit keyword>] <value>`, and values are applied in the order given.

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 states a specific verb and resource: set a whole look, including intensity and/or several attributes, on one target in one call. It distinguishes this multi-attribute operation from the singular sibling by referencing gma3_set_attribute for selection semantics.

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 clearly requires an explicit target via `fixtures` or `use_selection: true`, and explains when pre-checking and verification apply. It does not explicitly compare against other nearby tools such as gma3_set_color or gma3_set_position, but the multi-attribute use case is 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