Skip to main content
Glama

Cook recipes with an explicit option

gma3_cook_recipes

Apply grandMA3 preset, cue, or sequence recipes at once and verify the results, with merge, overwrite, or remove modes and optional preview.

Instructions

Cook the recipes of a preset, a cue part, a cue (all its parts) or a whole sequence, at once and verified (the console also re-cooks group and preset changes by itself in the background a moment later, with merge low priority). mode is required: merge_low_priority (replaces cooked data, keeps every uncooked value), merge (also replaces uncooked values on the recipes' own fixtures and attributes), overwrite (deletes every uncooked value), remove (removes cooked data). First every affected target is listed with its lines, their problems (missing or empty group, missing preset), the coverage before and the cooked coverage the lines should give; merge and overwrite are refused while they would replace or delete uncooked values unless replace_uncooked: true. preview: true stops there. After Cook <target> /<Option> (verify, default true) each target is read back: every predicted fixture and attribute cooked, no cooked values on fixtures no line selects, uncooked values unchanged (merge_low_priority, remove) or changed only where allowed. Lines that are not predicted (phaser recipes, filters) are named; presets that embed other presets are noted (their recipes are not re-cooked). Needs bridge 0.24.0.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYes
targetYesPreset, or sequence with optional cue and part.
verifyNo
previewNo
replace_uncookedNoAllow merge/overwrite to replace or delete uncooked values (default false: refuse).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

No annotations provided, so the description carries full burden. It discloses mutation semantics (what is replaced/deleted vs preserved per mode), the refusal behavior for merge/overwrite, the background re-cook with merge low priority, and bridge version requirement. This is substantive beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely long, dense run-on sentences with no paragraphing. Front-loads purpose but the detailed coverage/verification discussion could be trimmed or restructured; it reads as a spec dump rather than a tool description.

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?

Given 5 params, nested target, no output schema, and a complex domain, the description covers mode semantics, verification, refusal behavior, background behavior, and prerequisites. It's arguably over-complete if anything.

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 description coverage is 40%, and nested target object is only partly documented. Description compensates by explaining mode meanings, verify (verify, default true), preview, and replace_uncooked semantics — going beyond the schema's enum list and default note.

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 (cook) and resource (recipes of preset/cue/sequence) plus the four modes. Clearly distinguishable from siblings like gma3_edit_recipe or gma3_recipes.

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?

Explains mode selection semantics (merge_low_priority vs merge vs overwrite vs remove) and explains preview/verify flow, giving clear when-to-use guidance. Doesn't explicitly name alternatives but the mode descriptions function as decision criteria.

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