Skip to main content
Glama
Sign In
gma3-mcp

gma3-mcp

by nf-s
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Read DMX output of a universe

gma3_dmx

Read live DMX output levels for a universe and channel range, in raw8 or percent, with optional fixture mapping and nonzero filtering. Use it to inspect actual output without changing the show.

Instructions

Raw DMX output for an explicit universe and channel range (channels 1..512; universe 1..1024, further bounded by the console's universe count). unit is explicit: "raw8" (0..255 per address) or "percent" (0..100 as the console converts it). Works with gma3_lua disabled (structured bridge op, plugin >= 0.3.0). Read-only: never changes selection, programmer or playback. Source is "dmx output": output levels, NOT programmer values. A universe that is not granted on this onPC returns no values with granted: false, a limitation (never zeros) and outputState explaining why (gma3_dmx_output has the whole picture). The range is from..to, or from plus count addresses (one of to or count; neither reads the one address from). nonzero_only (also accepted as nonzeroOnly, the result's spelling) is an explicit filter. patched: true additionally maps each returned address to its fixture/channel through the RT channels (bounded; stated in limitations when skipped). 16-bit attributes appear as two separate 8-bit addresses.

Input Schema

NameRequiredDescriptionDefault
toNoLast channel (1..512, >= from). Default: same as from. Not with count.
fromYesFirst channel (1..512).
unitNoraw8 (default): 0..255 per address. percent: 0..100 as converted by the console.
countNoNumber of addresses from `from` (1..512; from + count - 1 <= 512), instead of to.
patchedNoMap each returned address to fixture ID / channel name via the RT channels (default false).
universeYesDMX universe number (1..1024).
nonzeroOnlyNoSame as nonzero_only (the spelling the result uses).
nonzero_onlyNoOnly return addresses whose value is not zero (default false).

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 supplied, the description carries the full burden and does so thoroughly: read-only with no effect on selection/programmer/playback, the granted:false/no-values limitation, outputState rationale, the bounded patched mapping and the 16-bit split into two 8-bit addresses. This is exactly the behavioral context an agent needs before calling.

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 purpose and constraints, then parameter notes; every sentence is substantive. It is dense and slightly repetitive around the nonzero_only spelling alias, which keeps it from a perfect score.

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 an 8-parameter, annotation-free, no-output-schema read tool, the description covers return semantics (values, granted, limitations, outputState) and all behavioral caveats. Nothing essential for a correct call 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 a 3 is the baseline, but the description adds real meaning: unit is framed as explicit with conversion semantics, the from..to vs from+count exclusivity is stated along with the default that neither reads the single address, and the nonzero_only/nonzeroOnly alias is explained. It does not add anything about patched failure modes beyond 'stated in limitations', so not 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?

Opens with a specific verb+resource: 'Raw DMX output for an explicit universe and channel range'. It further distinguishes itself from nearby tools by naming gma3_dmx_output for the whole picture and by explicitly separating DMX output levels from programmer values (gma3_programmer).

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?

Gives clear usage context: works with gma3_lua disabled, requires plugin >= 0.3.0, and defers to gma3_dmx_output for broader state. It does not spell out explicit when-not conditions (e.g. when to prefer gma3_fixture_output), so it stops just short of a 5.

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