Skip to main content
Glama
gma3-mcp

gma3-mcp

by nf-s

Run Lua inside grandMA3

gma3_lua

Run custom Lua 5.4 inside the grandMA3 engine to query or modify show data and return JSON results when structured tools do not cover the task.

Instructions

FALLBACK: use a structured tool when one fits; they check, read back and need no Lua. Patch: gma3_patch_library, gma3_patch_import, gma3_patch_add, gma3_patch_set, gma3_patch_move, gma3_patch_stages, gma3_patch_retype, gma3_patch_type_structure, gma3_place_fixtures, gma3_layout_cells. Dialogs: gma3_dialog (never Mouse()). Groups: gma3_store_group, gma3_configure_matricks. Presets: gma3_apply_preset, gma3_store_preset. Phasers: gma3_build_phaser. Looks: gma3_set_attributes. Cues: gma3_store_cues, gma3_edit_cues, gma3_build_chase, gma3_cue_contents. Recipe cues: gma3_store_recipe_cues, then gma3_cook_recipes. Playback: gma3_configure_sequence, gma3_configure_executor, gma3_playback, gma3_goto_cue. Reads: gma3_objects, gma3_get_object, gma3_list_children, gma3_programmer; used and free pool numbers and executors: gma3_pool_usage. Many objects at once: gma3_store_group (groups), gma3_store_preset (presets, each from explicit content), gma3_store_macro (macros), gma3_edit_macro_line (edits), gma3_assign_to_executor (assignments), gma3_configure_sequence (sequences, with ranges), gma3_set_variable (variables), gma3_store_cues (sequences), gma3_store_tag (tags), gma3_delete_tag (tags), gma3_assign_tag (assignments), gma3_configure_tag (tags) take lists with per-item checks and read-back; never loop over them in Lua. Watching over time: gma3_observe_tempo (how fast running sequences (chases) advance), gma3_observe_values (programmer or DMX output values of fixtures as they change), gma3_build_chase (one cycle of the chase it built), gma3_run_macro (a macro's running line), gma3_timecode_transport (a timecode show's cursor and the sequences it fires). They sample server-side; never write a Lua waiting or polling loop (gma3_lua has a 5 s budget). Evaluate Lua 5.4 code inside the grandMA3 Lua engine and return the result(s) as JSON. The code is first compiled as an expression ('return '), then as a statement block. All grandMA3 Lua API functions are available (Cmd, ObjectList, DataPool, Root, ShowData, Patch, Programmer, SelectedSequence, GetCurrentCue, GetExecutor, GetVar/SetVar, Printf, Echo, Enums, ...). Object handles are returned as {name, class, addr, addrNative, index, childCount}; use handle:Get('Prop') to read properties, :Children(), :Count(), :Ptr(i). Examples: 'SelectedSequence().name', 'GetCurrentCue():Get("No")', 'DataPool().Sequences:Count()', 'local t={} for i,c in ipairs(ObjectList("Fixture Thru")) do t[#t+1]=c.name end return t'. Use gma3_lua_api to look up function signatures. This capability is OFF by default on the console: the operator enables it by starting the bridge with Plugin "gma3_mcp_bridge" "lua" or running Plugin "gma3_mcp_bridge" "lua on" (gma3_status shows the policy). Each request runs under the console's execution budget (default 5 s wall-clock / 20 M VM instructions, operator-configurable) and is aborted with an error when it exceeds it, so keep scripts short and prefer the structured tools (gma3_get_object, gma3_list_children, gma3_objects) for bulk reads. By default the console's own hook on the plugin thread is preserved, which means the instruction budget is NOT enforced and the deadline is only checked when the script yields or returns: a script that loops without yielding cannot be stopped (gma3_status shows lua.bounded; the result's budget.instructionHookEnforced says what applied). The operator can start the bridge with luahook=replace to enforce hard quotas. Because a script may call Cmd() or Set(), every gma3_lua request is serialised with this server's other mutations (it waits for a running workflow and blocks later ones while it runs).

Input Schema

NameRequiredDescriptionDefault
codeYesLua code to evaluate
timeout_msNoRequest timeout (default 15000). Also passed to the console as the wall-clock execution budget, capped by the console's own limit, so the code stops when the client stops waiting.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full load and does so well: capability is OFF by default and enabled by a specific plugin command, 5 s / 20 M instruction budget, default hook does not enforce instruction quotas so a non-yielding loop cannot be stopped, and every request is serialised with other mutations. It stops short of describing the return envelope shape beyond "result(s) as JSON" and the budget field, which is the remaining gap.

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?

Front-loading is correct: FALLBACK and the routing list come first, then the actual semantics. But the routing block is a dense run-on enumeration of roughly fifty sibling tool names that is hard to scan and partly duplicates information available from sibling definitions, making the whole block disproportionately long.

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 tool with real operational complexity (default-off capability, instruction budget quirks, serialisation semantics) the description covers enablement, budget behavior, object handle shape, API discovery via gma3_lua_api, and four worked code examples. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters are documented in the schema, including the timeout_ms/console-budget relationship, so the baseline is 3. The description mentions the budget and the compile-as-expression-then-statement behavior but adds no per-parameter meaning beyond the schema.

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 core sentence states a specific verb and resource: "Evaluate Lua 5.4 code inside the grandMA3 Lua engine and return the result(s) as JSON." The opening "FALLBACK: use a structured tool when one fits" plus the routing list makes it unambiguous which sibling to prefer over this one.

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?

Explicit when-not-to-use guidance leads (use structured tools for patch, dialogs, groups, presets, cues, pool usage, bulk operations, observation) with the exact tool name for each task domain. It even states the failure mode to avoid ("never loop over them in Lua", "never write a Lua waiting or polling loop").

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