Skip to main content
Glama
bdstark

gma3-mcp

by bdstark
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Discover a fixture's attributes

gma3_fixture_attributes

List a grandMA3 fixture or subfixture's attributes, features, DMX ranges, defaults, and channel sets to inspect patch details without changing the show. Read-only.

Instructions

List the attributes of one fixture or subfixture with stable identifiers (attribute name, attributeIndex, uiChannel), pretty name, feature/feature group, activation group, physical unit, natural readout, the channel function's DMX and physical ranges, defaults, optional channel sets, and the DMX address mapping (coarse/fine/ultra as universe.address) from the RT channels. Subfixtures of a compound fixture are listed explicitly (subfixtures[], with their patch index); pass Fixture 501.3 to inspect one. Works with gma3_lua disabled (structured bridge op, plugin >= 0.3.0). Read-only: never changes selection, programmer or playback. The fixture is resolved by fixture ID through the console (patch index is reported separately as subfixtureIndex, never assumed equal). source says whether rows came from the UI channel API ("uiChannels") or the static fixture-type walk ("fixtureTypeWalk", no uiChannel). Null fields were not supplied by the console (explicitly unavailable, never inferred). Results are paginated. Not available: current values (use gma3_programmer / gma3_fixture_output).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum rows to return (default 100, max 500).
offsetNoRows to skip (pagination).
fixtureYesFixture ID (101), subfixture ("501.3") or command reference ("Fixture 501.3"). One (sub)fixture only.
include_channel_setsNoInclude each channel function's ChannelSets (named ranges such as gobo slots). Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/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 declares read-only behavior ('never changes selection, programmer or playback'), the lua-disabled/structured-bridge mode and plugin version floor, that fixture resolution goes through the console rather than assumed patch index, the meaning of `source` values, and that null fields are explicitly unavailable rather than inferred.

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?

Front-loaded with the returned-field inventory, then falls into shorter, higher-value sentences on resolution, source, nulls and pagination. The opening sentence is a dense run-on with nested parentheticals, but with no output schema the enumeration of return fields earns its place.

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?

No output schema exists, so the description must cover returns and it does: field inventory, `subfixtures[]` shape, `source` provenance, null semantics and pagination. Combined with the environment constraints (lua disabled, plugin >= 0.3.0) and the read-only guarantee, nothing critical for correct invocation 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 100% so the baseline is 3, but the description adds real meaning: the accepted fixture formats (numeric ID, '501.3' subfixture, 'Fixture 501.3' command reference), one-and-only-one (sub)fixture constraint, and the semantics of channel sets as named ranges like gobo slots.

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?

Specific verb + resource ('List the attributes of one fixture or subfixture') with an explicit scope (attributes, not current values). It enumerates the returned fields and is clearly distinguishable from gma3_fixture_output and gma3_patch_list, which the description itself references.

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?

States the positive case (inspect one fixture/subfixture's attributes, e.g. 'Fixture 501.3'), the exclusion ('Not available: current values'), and names the alternatives to use instead (gma3_programmer / gma3_fixture_output). An agent is told both when to pick this tool and when not to.

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