Skip to main content
Glama
gma3-mcp

gma3-mcp

by nf-s

Write the recipe lines of many cues

gma3_store_recipe_cues

Write standard recipe lines for up to 100 cue parts in one call, using replace or append mode, with batch results and optional cooking of the written parts.

Instructions

Write the standard recipe lines of up to 100 cue parts of one sequence in one call (at most 200 lines per part, 500 per call; a larger build is several calls). cues: [{cue, part? (default 0), name?, note?, lines: [{selection: group, values: "N.M" preset, matricks?, name?, enabled?, selection_mode?, x?/y?/z?: {wings, blocks, groups, width, shift, shuffle, select, fade/delay/phase/speed: {from, to}}}]}]. mode is required: replace deletes every line of the part first (refused while the part holds phaser lines), append adds after the existing ones. The cues must exist (gma3_store_cues creates them); name is the cue's name (Part 0), note its Note. Once for the whole call, before anything is sent: every cue part is read and every group, preset and MAtricks a line names must be in the show. Each line is written as gma3_edit_recipe adds one (Assign Group, Preset and MAtricks At the line, set for the other fields and the per-line MAtricks columns), and every reply is checked. Batch form: each cue part is an item: its steps stop at its first failure, the parts already written stay (nothing is undone or retried), an unknown outcome stops the rest, and its read-back is compact: the line count, then only mismatches (every field written, earlier lines unchanged on append, name, note). The console cooks each written line by itself (merge low priority). cook: a gma3_cook_recipes mode cooks every part afterwards, only when every part was written and matched (replace_uncooked and verify_cook as in gma3_cook_recipes). preview: true checks and returns the plan (detail: true every request). Phaser recipe lines are not written. Needs bridge 0.24.0.

Input Schema

NameRequiredDescriptionDefault
cookNoCook every written part with this gma3_cook_recipes mode afterwards.
cuesYesCue parts and their lines, in order.
modeYes
detailNoReturn every item's full result with its steps (default false: one line per item).
previewNo
sequenceYes
verify_cookNoWith cook: read every cooked part back (default true).
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).
replace_uncookedNoWith cook merge/overwrite: allow replacing or deleting uncooked values (default false: that part's cook is refused).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/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 behavioral burden and does so: hard limits (200 lines/part, 500/call), pre-flight validation of every group/preset/MAtricks, per-item failure semantics (partial writes persist, no undo or retry, unknown outcome halts the rest), compact read-back format, and cook only when every part was written and matched. It even declares the bridge version requirement, which is exactly the kind of constraint an agent cannot infer.

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?

Purpose, limits and mode semantics are front-loaded in the first two sentences, so an agent gets the essentials immediately. The remainder is a dense single paragraph mixing an inline JSON sketch with failure and cook semantics; it earns its length given the tool's complexity but would scan far better as separated clauses.

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 nine-parameter mutation tool with no annotations and no output schema, the description covers everything an agent needs: what is written, ordering, limits, atomicity and partial-failure behavior, what the read-back reports, and when cooking happens. Nothing material about invoking it correctly is left unstated.

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 67%, and the description compensates well: it explains the cues item shape, part default 0, name/note landing on Part 0, the 'N.M' preset string form, the mode enum semantics, and the interaction of cook with replace_uncooked and verify_cook. Some nested MAtricks fields are only covered by the schema, but the description defers to gma3_configure_matricks for their shape rather than leaving them opaque.

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 and resource with scope: writes 'the standard recipe lines of up to 100 cue parts of one sequence in one call'. It differentiates itself from siblings by naming gma3_edit_recipe (one line at a time), gma3_store_cues (creates the cues), gma3_cook_recipes and gma3_configure_matricks, so an agent can tell exactly which tool writes many recipe lines at once.

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 concrete preconditions and exclusions: the cues must already exist, phaser recipe lines are not written, replace is refused while the part holds phaser lines, and workloads above the limits must be split across calls. It implicitly routes single-line work to gma3_edit_recipe but never states that trade-off explicitly, which keeps it 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