Skip to main content
Glama
gma3-mcp

gma3-mcp

by nf-s

Create a macro or replace or append its lines (never runs it)

gma3_store_macro

Stores, replaces, or appends grandMA3 macros and their command lines with validation and read-back checks, without running the macro.

Instructions

mode (required): create (refuses an existing macro), replace (removes the existing lines first, keeping the macro, its appearance and its executor assignments) or append (adds after the existing lines). lines: [{command, wait (seconds, "follow" or "go" = a manual wait until the next Go+), enabled, add_to_cmdline, execute, name, note, raw}]; name, note, cli of the macro. Before anything is sent the references in each line are checked (single objects named with full keywords; a Store earlier in the macro counts as creating its object); raw: true stores a line unchecked. Refuses a locked or running macro, and a name another macro has (naming the holder; the pool's names are read once per call, compared case-insensitively; a duplicate makes lookups by name ambiguous, and whether the console would store "#2" is not verified for macros): on_name_taken refuse (default) | allow_suffix (store anyway); in the batch form a name an earlier macro of the call was stored under counts as taken. Sends Store Macro N, Delete/Store Macro N.L and one set per property; NEVER runs the macro. The console rewrites command text outside quotes (trims, collapses spaces, expands abbreviated keywords): every line is read back and compared exactly; a rewritten line is a mismatch unless accept_console_form: true (it is reported in rewritten either way). 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
cliNo
modeNoRequired (per macro or for the whole batch).
nameNo
noteNo
linesNoRequired unless macros is given.
macroNoMacro number. Required unless macros is given.
detailNoReturn every item's full result with its steps (default false: one line per item).
macrosNoBatch form: several macros, each {macro, mode, lines, name, note, cli}; mode may be given once for all.
verifyNo
previewNo
data_poolNoData pool number (DataPool n). Default: the current data pool, as without this parameter.
on_name_takenNoWhen another macro has the name: refuse (default, nothing is sent) or allow_suffix (store anyway).
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

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, the description carries the full burden and does so: pre-send reference checks, raw bypass, refusal conditions, case-insensitive name pool read per call, batch ordering with no retries and stop-on-unknown-outcome, and per-item outcomes. The console's text rewriting plus read-back comparison and the accept_console_form escape hatch is exactly the kind of non-obvious behavior an agent needs.

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-loaded with mode, which is the right choice, but the rest is a dense run-on with parenthetical nesting that is hard to parse on first read. Length is defensible for the complexity, yet several sentences pack three or four distinct rules each without structural breaks.

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?

A 14-parameter, batch-capable, no-output-schema tool gets thorough coverage of refusal, verification and batch behavior. The omission of preview/verify/cli semantics leaves some gaps, but nothing an agent needs to avoid a destructive mistake 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 only 57% with 14 parameters, and the description adds real meaning for mode, line fields (wait 'follow'/'go', raw, enabled, add_to_cmdline), on_name_taken, accept_console_form and batch-default inheritance. It leaves verify, preview, cli, macro and data_pool largely or entirely unexplained, which keeps it from 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?

States a specific verb+resource (store a macro / replace or append its lines) and explicitly scopes out running it ('NEVER runs the macro'), which cleanly separates it from gma3_run_macro, gma3_edit_macro_line and gma3_macros.

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 when-to-use semantics for each mode (create refuses an existing macro, replace keeps appearance/executor assignments, append adds after existing lines) and when it refuses (locked/running macro, duplicate name). It never names the sibling to use instead for running or single-line edits, so it falls 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