Skip to main content
Glama

Run Lua inside grandMA3

gma3_lua

Evaluate Lua 5.4 code inside grandMA3's Lua engine and return results as JSON, enabling scripted queries and control through its API.

Instructions

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

TableJSON 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.6/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full behavioral burden — and it discloses a great deal: the capability is off by default with exact enable commands, the default budget (5 s / 20 M instructions), abort-on-exceed behavior, that the console hook is preserved by default so the budget is NOT enforced for non-yielding loops, and that luahook=replace enforces hard quotas. The serialisation with other mutations is also stated. Minor gap: it does not describe the result JSON shape beyond handle fields.

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?

Information-dense and front-loaded with the purpose, followed by handle format, examples, enabling procedure, budget semantics, and serialisation. Every sentence earns its place, but it is a single very long block with a bare API-function list that could be tightened or structured for scannability.

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 complex, high-risk tool with no output schema and no annotations, the description covers execution model, safety profile, budget limits, enablement, error conditions, concurrency, and return format. An agent has everything needed to invoke it correctly or choose an alternative.

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; the description adds genuine meaning about the code parameter (compiled first as 'return <code>' then as a statement block) and supplies concrete examples like 'SelectedSequence().name'. The timeout_ms description ties into the budget semantics, reinforcing coverage.

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?

States a specific verb (Evaluate) and resource (Lua 5.4 code) with the exact engine (grandMA3 Lua engine) and a clearly stated return (JSON). It explicitly differentiates from siblings by naming gma3_get_object, gma3_list_children, and gma3_objects as preferred for bulk reads, so an agent can distinguish it without opening the schema.

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?

Gives explicit when-to-use (arbitrary Lua evaluation) and when-not-to-use ('prefer the structured tools ... for bulk reads', naming three alternatives), plus routing to gma3_lua_api for signatures. It also states the critical precondition that the capability is OFF by default and how the operator enables it, and points to gma3_status for the policy.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.