Skip to main content
Glama
yiw190

reaper-mcp

by yiw190
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

render

Exports REAPER mixes or selected tracks as audio files to a specified folder, supporting stems, time bounds, sample rate, and loudness checks.

Instructions

Render. No undo. Long timeout. bounds: project | time_selection | custom | items. Default: the master mix. stems=true renders the selected tracks as stems instead (pass track_indices to select them). path is the output folder; the file name comes from pattern. Sets all media online (action 40101) first unless media_online=false. Refuses when a target file already exists (REAPER's overwrite prompt would hang the bridge) and when tracks are soloed (pass allow_solo=true, or solo_indices / mute_indices to solo/mute tracks for this render only; they are restored afterwards). Returns files [{path, bytes, length_sec, peak_db, lufs_i}] and warnings (near-silent, missing file, master muted); measure=false skips the loudness scan.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNo
stemsNo
boundsNo
measureNo
patternNo
channelsNo
end_beatsNo
allow_soloNo
sample_rateNo
start_beatsNo
media_onlineNo
mute_indicesNo
solo_indicesNo
track_indicesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.5.0
    • addedInput schema / properties / allow_solo
      Added value: +{
+  "type": "boolean"
+}
    • addedInput schema / properties / measure
      Added value: +{
+  "type": "boolean"
+}
    • addedInput schema / properties / media_online
      Added value: +{
+  "type": "boolean"
+}
    • addedInput schema / properties / mute_indices
      Added value: +{
+  "items": {
+    "minimum": 0,
+    "type": "integer"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / solo_indices
      Added value: +{
+  "items": {
+    "minimum": 0,
+    "type": "integer"
+  },
+  "type": "array"
+}
  2. First observedv0.1.0

TDQS

A4.2/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: it discloses that there is no undo, a long timeout, that media is set online (action 40101) first, and two refusal conditions with their cause (overwrite prompt hanging the bridge, soloed tracks). The return payload and warnings are also described, including measure=false skipping the loudness scan.

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?

The critical facts (no undo, long timeout) are front-loaded, and almost every clause carries operational information. The middle sentences are long and stacked with parentheticals, which slightly hurts scannability, but there is very little filler.

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 14-parameter render tool with no output schema and no annotations, the description covers the mutation risk, failure modes, return shape and most parameters. The remaining gap is the four unexplained audio-format/range parameters, which an agent would have to guess at from the schema alone.

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 compensate, and it explains roughly ten of the fourteen parameters: path (output folder), pattern (file name), bounds enum, stems + track_indices, media_online, allow_solo, solo_indices/mute_indices, and measure. channels, sample_rate, start_beats and end_beats are left entirely unexplained, which keeps it from a 5.

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 opening 'Render.' is nearly tautological, but the following sentences make the operation concrete: rendering the master mix (or stems) to files in a folder. The distinction from siblings is implicit via 'stems=true' and 'track_indices', but no sibling tool is named, so it lands at a solid 4 rather than a 5.

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?

It states defaults ('Default: the master mix'), variants ('stems=true renders the selected tracks as stems'), and workarounds for the two documented refusals (allow_solo=true, media_online=false). It doesn't position itself against siblings like batch or action, so there is no explicit alternative routing.

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