Skip to main content
Glama
gma3-mcp

gma3-mcp

by nf-s

Insert, change, move or remove one macro line (never runs it)

gma3_edit_macro_line

Edit grandMA3 macro lines by inserting, setting, moving, or removing commands in order, with batch edits, read-back verification, and refusal of locked or running macros.

Instructions

action insert (line 1..count+1, needs command), set (any of command, wait, enabled, add_to_cmdline, execute, name, note), move (line -> to; sent as upward moves only, because a downward Move lands one place short), remove. References in a written command are checked unless raw: true. Refuses a locked or running macro. Every line is read back and compared with the expected order and content; accept_console_form as in gma3_store_macro. Never runs the macro. Batch form (edits): the edits run in order, each against the macro as the earlier edits left it (line numbers shift after an insert, move or remove); once an edit on a macro does not succeed, the later edits on that macro are not attempted. Batch form: give the list instead of the single object's fields; the other arguments are defaults for every item (an item's own fields win). Each item gets the single form's checks and read-back, and its own outcome; items run in order, nothing is retried, an unknown outcome stops the rest, and the result has one line per item (detail: true for every step).

Input Schema

NameRequiredDescriptionDefault
toNo
rawNo
lineNoRequired unless edits is given.
nameNo
noteNo
waitNo
editsNoBatch form: several edits in order, each {macro, action, line, ...}; macro may be given once for all.
macroNoMacro number. Required unless edits is given (it may then be a default for every edit).
actionNoRequired unless edits is given.
detailNoReturn every item's full result with its steps (default false: one line per item).
verifyNo
commandNo
enabledNo
executeNo
previewNo
data_poolNoData pool number (DataPool n). Default: the current data pool, as without this parameter.
add_to_cmdlineNo
stop_on_failureNoBatch form: stop at the first item that does not succeed (default false: independent items go on; an item on an object an earlier item failed on is skipped either way).
accept_console_formNo
allow_unresolved_dependentsNoEdit even when a later line uses an object this edit stops an earlier line from storing (default false: refuse).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/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: it discloses the locked/running-macro refusal, reference checking unless raw, the upward-only move workaround, mandatory read-back with order/content comparison, and the batch failure model (stop on first failure, no retries, skip items on already-failed objects). These are behaviors no schema field could convey.

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?

Action semantics are correctly front-loaded, but the batch behavior is stated twice in overlapping sentences ('the edits run in order...' then 'give the list instead of the single object's fields...'), and the parenthetical chaining makes it dense and hard to scan for a 20-parameter tool.

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 20-parameter, mutation-heavy tool with no annotations and no output schema, the description covers ordering, failure semantics, verification, and action-specific requirements. Gaps remain around verify, preview, and macro's defaulting behavior, plus what a successful result actually contains beyond 'one line per item'.

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?

Coverage is 40% across 20 parameters, and the description compensates well for the key ones: line bounds, to as move destination, raw bypassing reference checks, detail controlling per-item verbosity, and each action's applicable fields. It leaves macro, verify, and preview unexplained in both schema and description, which keeps it short of 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?

The description names the resource (a macro line) and enumerates the four concrete operations (insert, set, move, remove) with their operand rules, and the title states the crucial scope: 'never runs it'. An agent can distinguish this from gma3_run_macro and gma3_store_macro 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives per-action conditions (insert needs command, line range 1..count+1; set accepts specific fields; move is sent as upward moves only) and explains when to use the batch edits form versus the single object form, including that top-level arguments become defaults. It stops short of naming an explicit alternative for execution, though 'never runs the macro' plus the gma3_run_macro sibling makes the exclusion inferable.

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