Skip to main content
Glama
wretcher207

Reaper Daemon

by wretcher207
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

transport

Transport and project timing: play, stop, pause, record, set_cursor, set_time_selection, set_tempo (the project's base tempo), plus the tempo map: get_tempo_markers, set_tempo_marker (a tempo and/or time-signature change at a position; a…

Instructions

Transport and project timing: play, stop, pause, record, set_cursor, set_time_selection, set_tempo (the project's base tempo), plus the tempo map: get_tempo_markers, set_tempo_marker (a tempo and/or time-signature change at a position; a time-signature change needs a bar position; index edits an existing marker) and delete_tempo_marker. Mutations run in an undo block (Ctrl/Cmd+Z reverts).

Input Schema

NameRequiredDescriptionDefault
bpmNo
endNoPosition object, e.g. {"type":"cursor"}, {"type":"bar","bar":33}, {"type":"time","seconds":12.5}, {"type":"marker","name":"Chorus"}, {"type":"region","name":"Verse 1"}, {"type":"time_selection"}
clearNoset_time_selection: clear it.
indexNoset/delete_tempo_marker: an existing marker's index from get_tempo_markers.
startNoPosition object, e.g. {"type":"cursor"}, {"type":"bar","bar":33}, {"type":"time","seconds":12.5}, {"type":"marker","name":"Chorus"}, {"type":"region","name":"Verse 1"}, {"type":"time_selection"}
actionYes
linearNoset_tempo_marker: ramp to the next marker.
dry_runNoPreview: return what would run without changing the project.
positionNoPosition object, e.g. {"type":"cursor"}, {"type":"bar","bar":33}, {"type":"time","seconds":12.5}, {"type":"marker","name":"Chorus"}, {"type":"region","name":"Verse 1"}, {"type":"time_selection"}
numeratorNoset_tempo_marker: time signature top (with denominator).
seek_playNo
denominatorNoset_tempo_marker: 1, 2, 4, 8, 16, 32 or 64.
length_barsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv3.23.1
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "play",
-  "stop",
-  "pause",
-  "record",
-  "set_cursor",
-  "set_time_selection",
-  "set_tempo"
-]New value: +[
+  "play",
+  "stop",
+  "pause",
+  "record",
+  "set_cursor",
+  "set_time_selection",
+  "set_tempo",
+  "get_tempo_markers",
+  "set_tempo_marker",
+  "delete_tempo_marker"
+]
    • addedInput schema / properties / denominator
      Added value: +{
+  "description": "set_tempo_marker: 1, 2, 4, 8, 16, 32 or 64.",
+  "type": "integer"
+}
    • addedInput schema / properties / dry_run
      Added value: +{
+  "description": "Preview: return what would run without changing the project.",
+  "type": "boolean"
+}
    • addedInput schema / properties / index
      Added value: +{
+  "description": "set/delete_tempo_marker: an existing marker's index from get_tempo_markers.",
+  "type": "integer"
+}
    • addedInput schema / properties / linear
      Added value: +{
+  "description": "set_tempo_marker: ramp to the next marker.",
+  "type": "boolean"
+}
    • addedInput schema / properties / numerator
      Added value: +{
+  "description": "set_tempo_marker: time signature top (with denominator).",
+  "type": "integer"
+}
  2. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose one important trait: mutations run in an undo block and Ctrl/Cmd+Z reverts them. It also implies a preview path via the dry_run parameter in the schema. It does not address permissions, whether record requires armed tracks, real-time/async behavior of play, or what errors occur on invalid positions.

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?

A single dense sentence, but it is front-loaded with the action inventory and then zooms into the trickier tempo-map semantics. Nearly every clause adds information; the parentheticals are purposeful rather than decorative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter, action-dispatched tool with no output schema and no annotations, the description should clarify return shapes (especially what get_tempo_markers yields) and which parameters pair with which actions. It handles the tempo-marker subset well and hints at the get→set index workflow, but leaves playback and selection actions under-specified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 69%, so several parameters are self-documented, and the description usefully adds meaning for set_tempo_marker (bpm, linear ramp, numerator/denominator signature, index for edits). However bpm, seek_play, and length_bars have no explanation in either the description or the schema, and the description never maps the position/start/end objects to the actions that consume them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete domain ('Transport and project timing') and enumerates every action the tool performs, from playback control to tempo-map editing. It goes further by explaining set_tempo ('the project's base tempo') versus set_tempo_marker, which lets an agent separate those two similar operations without opening the schema. It stops short of full sibling differentiation (e.g., versus the adjacent 'markers' tool).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is implied by the action list — an agent can infer that 'play' is for starting playback and 'get_tempo_markers' should precede 'set_tempo_marker' because the description says index comes 'from get_tempo_markers'. There is no explicit when-to-use/when-not or 'prefer X over Y' routing against siblings like markers or raw_command, so the guidance remains inferential.

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