reaper-mcp

Overview Schema Source Related Servers Discussions Admin

render

Exports REAPER project mixes or selected tracks as WAV/MP3 files, with options for stems, time bounds, output paths, loudness measurement, and safe overwrite 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. format wav (bit_depth 16 | 24 | 32 = float) or mp3 (320 kbps) sets the file type for this render only; without it the project's render format is used.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "render"
  }
}

Input Schema

Name	Required	Description	Default
`path`	No
`stems`	No
`bounds`	No
`format`	No
`measure`	No
`pattern`	No
`channels`	No
`bit_depth`	No
`end_beats`	No
`allow_solo`	No
`sample_rate`	No
`start_beats`	No
`media_online`	No
`mute_indices`	No
`solo_indices`	No
`track_indices`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.6.0Oct 27, 2026

addedInput schema / properties / bit_depth

Added value: +{
+  "enum": [
+    16,
+    24,
+    32
+  ],
+  "type": "integer"
+}

addedInput schema / properties / format

Added value: +{
+  "enum": [
+    "wav",
+    "mp3"
+  ],
+  "type": "string"
+}

Changed5 schema fields changedv0.5.0Oct 23, 2026

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"
+}

First observedv0.1.0Sep 20, 2026

TDQS

A4.5/5.0

Behavior4/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: no undo, long timeout, media brought online first unless media_online=false, refusal on existing files because REAPER's overwrite prompt would hang the bridge, and solo/mute restored afterward. The only gap is that it doesn't quantify the timeout or describe failure/timeout behavior beyond the hang rationale.

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 critical facts ('Render. No undo. Long timeout.') followed by bounds and output mapping. Dense but nearly every sentence carries a distinct behavior; the parenthetical stacking around solo/mute and format makes it slightly harder to scan than it needs to be.

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?

No output schema exists, but the description supplies the return shape itself (files with path, bytes, length_sec, peak_db, lufs_i, plus warnings) and enumerates warning types. For a 16-param mutation tool this is close to complete; the unaddressed channels/sample_rate/beat-range params are the only shortfall.

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 across 16 params, and it does for most: path, pattern, bounds (all four enum values), stems, track_indices, media_online, allow_solo, solo_indices, mute_indices, measure, format, and bit_depth (with 32=float and mp3=320 kbps). It leaves channels, sample_rate, and start_beats/end_beats unexplained beyond the 'custom' bounds hint, which is why this is not a 5.

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 the specific operation (offline render of the master mix, or stems with track_indices) and the artifacts it produces (files written to `path` using `pattern`). It is clearly distinguishable from siblings like action, run_lua, or project, which would not describe render-bound/stem semantics.

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

Usage Guidelines5/5

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

Gives explicit branch conditions: stems=true plus track_indices for stems; allow_solo/solo_indices/mute_indices when tracks are soloed; measure=false to skip the loudness scan; format to override the project format for this render only. It also states when the tool refuses (existing target file, soloed tracks) and how to proceed in each case.

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

Deploy Server