Skip to main content
Glama
wretcher207

Reaper Daemon

by wretcher207
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

insert_riff

Render a humanized guitar or bass riff from inline bars or a file and place it on a REAPER track as a MIDI part, with optional dry-run preview and one-step undo.

Instructions

Render ONE humanized guitar or bass part and insert it on a track (skills/guitar-apparatus/). Write the riff as bars_text — one 16-step bar per line, e.g. 'x.x.x.x.x.x.x.x.' — or point at a file with bars_file, never both; omit both to use the built-in 'demo' riff. Step alphabet: '.' rest, 'x' muted chug, 'X' accented root, 'o' let-ring root, 'g' ghost, '_' tie the previous note through this step, '~' slide into the next; UPPERCASE note names (E F G A B C D) are power chords in the key of E and lowercase are single notes, so case matters. Read skills/guitar-apparatus/SKILL.md for the full table before writing anything beyond chugs. Double tracking is two performances, not a copy: call this twice with DIFFERENT seeds for the left and right guitar. MUTATES the project (undo-block wrapped, one Ctrl/Cmd+Z reverts). Refuses in ~0 s when the bridge heartbeat is dead. The rendered .mid is kept under rendered-midi/, including on a dry run, because REAPER holds it by reference.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
mapNoTuning/keyswitch map: argent_e (default), argent_csharp, nolly_e, nolly_csharp.
partNoWhich engine to play the riff on. Default guitar.
riffNoBuilt-in riff when neither bars source is given: 'demo' or 'probe'.
seedNoRNG seed. Same riff + same seed = the same performance.
tempoNoProject tempo override (BPM).
trackYesExact name of the track to insert on.
dry_runNoPreview: return what would run without changing the project.
replaceNoClear the track from `position` first, so a re-cut does not stack takes. Needs a numeric position.
positionNoSeconds from project start. Default: the edit cursor.
bars_fileNoAbsolute path to a riff text file. Mutually exclusive with bars_text.
bars_textNoThe riff inline, one bar per line. Mutually exclusive with bars_file.
low_stringNoOverride the map's low-string MIDI note (e.g. 52 to lift a lead into register).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/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 well: it discloses the project MUTATES, that it is undo-block wrapped and reverts with one Ctrl/Cmd+Z, that it refuses in ~0s when the bridge heartbeat is dead, and that the rendered .mid is retained even on a dry run because REAPER holds it by reference.

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?

Front-loaded with purpose then format, mutation and failure behavior. Dense but every sentence earns its place; the retained-.mid note is slightly peripheral but relevant to dry_run.

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 12-parameter mutation tool with no output schema, the description covers format, mode selection, undo behavior and refusal conditions. Minor gaps remain around return shape and the replace/position interaction, but nothing critical for correct invocation 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 100%, so baseline is 3, but the description adds genuinely non-redundant meaning: the step alphabet legend, the case-sensitivity rule for power chords vs single notes, and the seed semantics for distinct double-tracked performances.

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 scope: 'Render ONE humanized guitar or bass part and insert it on a track'. The 'ONE ... part' scope and the guitar/bass engine distinction let an agent separate it from generic siblings like insert_midi_file or riff_grid.

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 explicit selection rules among its own inputs — bars_text XOR bars_file, omit both for 'demo' — and states the double-tracking workflow (call twice with different seeds). It does not name sibling alternatives such as insert_groove or riff_grid, so it stops short of full routing guidance.

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