Skip to main content
Glama
Sign In
gma3-mcp

gma3-mcp

by nf-s
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Lay out a fixture's cells (string lights, pixel strands)

gma3_layout_cells

Positions the cells of a multi-cell fixture along a line, square wave, zigzag, or point path, either updating the shared layout or creating an own copy for selected fixtures.

Instructions

Positions the cells of a multi-cell fixture along a path. A cell has no position of its own: its place is in the fixture type, shared by every fixture whose DMX mode uses that layout. scope "shared" (default) writes the type's layout: every fixture using it moves, and affects must list exactly those FIDs (preview: true lists them). scope "own" first copies the type for own.fixtures (default: the fixture) under own.name, moves them to the copy in a patch session (FIDs, addresses, cells, groups and preset values are kept), then lays out the copy; the other fixtures keep theirs. path: shape line (direction), square_wave (legs of leg_length along leg_direction, stepping leg_step along advance between them), zigzag (diagonal legs, advancing leg_step per leg) or points; cells are placed every spacing along the path from origin; axes the path does not use keep each cell's value unless origin sets them. count places only the first cells; rest keep|last. Lengths in unit (m, cm, mm, ft, in), relative to the cells' parent geometry (the fixture's own position, rotation and mirroring then apply: place the fixture with gma3_place_fixtures). Refused while the patch copy is open. No undo: previous holds the positions before the call. Read back per cell. Needs bridge 0.29.0.

Input Schema

NameRequiredDescriptionDefault
ownNoown: the new type's name and the fixtures that get it.
pathYes
restNoThe cells after count: keep their positions (default) or stack at the last placed one.
unitNo
countNoPlace only the first count cells (in the chosen order).
orderNoThe order the cells take along the path: "index" (cell numbers, default) or "dmx" (DMX address order: the physical order along a string, e.g. the Festoon 2-string mode 1-9, 19-29, 10-18, 30-40; see cellOrder in gma3_patch_type_structure).
scopeNo
verifyNo
affectsNoshared: every FID that uses this layout (all of them move).
fixtureYesFID of a fixture with cells; its type and mode define the layout.
previewNo
exclusiveNo

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 itself discloses the shared-scope mutation blast radius and the own-scope patch-session copy, including what data is preserved. It also states the lack of undo, the previous-position record, refusal conditions, coordinate behavior, and compatibility requirement.

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 core operation and shared-scope consequences are front-loaded, and nearly every clause carries useful operational information. The single semicolon-heavy paragraph is nevertheless difficult to scan, with important refusal and no-undo details buried near the end.

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 complex nested mutation tool without annotations or an output schema, it unusually covers geometry, fixture-wide effects, copying behavior, recovery information, prerequisites, and compatibility. The undocumented verify/exclusive flags and vague "Read back per cell" instruction leave small but real invocation and follow-up gaps.

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?

The description adds substantial meaning beyond the 50% schema coverage: path-shape geometry, spacing and origin behavior, scope and own defaults, count/rest interaction, units, and the parent-geometry coordinate frame. However, verify and exclusive remain unexplained, and the behavior of a points path is less explicit than the other shapes.

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 opening sentence precisely identifies the operation and resource: positioning cells of a multi-cell fixture along a path. It also distinguishes this type-level cell-geometry operation from whole-fixture placement by referring to gma3_place_fixtures.

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?

It gives concrete selection rules for scope "shared" versus "own", including defaults, the affects requirement, and preview-based FID discovery. The patch-copy refusal, fixture-placement cross-reference, and bridge-version requirement provide further invocation 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