Skip to main content
Glama
Sign In
reaper-mcp

reaper-mcp

by yiw190
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

batch

Run multiple REAPER operations in one IPC call and one undo point, with optional stop-on-error, Lua scripts, and grouped tool calls.

Instructions

Many operations in one IPC hop and one undo point. Each call is {func, args} or {func: 'run_lua', code, timeout} or {func, arguments} for a grouped tool name (track/midi/fx/...). Each slot is the inner result, or {error}. There is no rollback: by default one failure does not abort the rest; stop_on_error=true skips the slots after the first failure ({skipped: true}). Handles from earlier calls work later.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "calls": "<calls>"
    },
    "name": "batch"
  }
}

Input Schema

NameRequiredDescriptionDefault
callsYes
stop_on_errorNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.6.0
    • addedInput schema / properties / calls / items / properties / timeout
      Added value: +{
+  "maximum": 600,
+  "minimum": 1,
+  "type": "number"
+}
    • addedInput schema / properties / stop_on_error
      Added value: +{
+  "type": "boolean"
+}
  2. First observedv0.1.0

TDQS

A4/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 meets it: it discloses there is no rollback, that failures do not abort the remaining calls by default, that stop_on_error=true skips later slots and marks them {skipped: true}, and that handles from earlier calls remain valid later. These are exactly the non-obvious traits an agent needs before composing a multi-call batch.

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 the value proposition (one hop, one undo point) before the grammar details; nearly every sentence carries distinct information. It is dense but not padded, with only slight redundancy between the call-shape and handle-reuse statements.

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 complex multiplexer with no annotations and no output schema, the description covers call shapes, per-slot return values, error/skip behavior and cross-call handle reuse. The remaining gap is that valid 'func' values and the 'action' field are only gestured at rather than specified.

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 0%, so the description must explain the parameters, and it does for most: the three call shapes ({func, args}, {func: 'run_lua', code, timeout}, {func, arguments} for grouped names), plus stop_on_error semantics. It omits the 'action' property present in the schema, leaving one field undocumented.

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 states a concrete verb and resource: it runs many tool operations in one IPC hop and one undo point, and names the grouped sibling namespaces (track/midi/fx) it can dispatch into. That differentiates it from calling those sibling tools individually, though the generic name 'batch' alone would not.

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?

The benefit (single IPC hop, single undo point) implies when to prefer it over individual calls, but the description never says so explicitly and gives no when-not guidance or named alternative. Usage must be inferred from the stated benefits.

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