reaper-mcp

Overview Schema Source Related Servers Discussions Admin

envelope

List, read, or replace automation points for a REAPER track parameter such as volume, pan, or mute, with optional beat-range editing and gain/dB conversion.

Instructions

Track envelopes. action: list | get | set. name is REAPER envelope name (Volume, Pan, Mute, ...). set replaces all points, or with start_beats / end_beats only the points in that range (ends included; every new point must lie inside it); get with a range returns only those points. value is the envelope's value; Volume is linear gain (1.0 = 0 dB, 0.5 = -6 dB), also on fader-scaled envelopes. unit=db reads/writes volume-type envelopes (Volume, Trim Volume, send Volume) in dB. set re-activates an envelope left inactive (ACT 0).

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": {
      "action": "<action>",
      "track_index": "<track_index>"
    },
    "name": "envelope"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No
`unit`	No
`action`	Yes
`points`	No
`end_beats`	No
`start_beats`	No
`track_index`	Yes
`envelope_index`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.6.0Oct 27, 2026
- addedInput schema / properties / end_beats
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```
- addedInput schema / properties / start_beats
```
Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
```

Changed1 schema field changedv0.5.0Oct 23, 2026

addedInput schema / properties / unit

Added value: +{
+  "enum": [
+    "gain",
+    "db"
+  ],
+  "type": "string"
+}

First observedv0.1.0Sep 20, 2026

TDQS

A3.6/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden and does disclose important side effects: set replaces all points or only points in a range, every new point must lie inside that range, and set re-activates an inactive envelope. It does not cover every possible behavior, such as permission needs or return shapes, but it is substantially transparent for a mutation-capable tool.

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 description is dense but front-loaded with the action modes and key semantic details. Every sentence carries useful information, though the long run-on style makes it slightly harder to scan.

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 an 8-parameter tool with nested point objects, no annotations, no output schema, and no schema descriptions, the definition covers the most important operational semantics. It remains incomplete because it leaves required track_index, envelope_index, and several point-level fields unexplained.

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 0%, so the description must compensate for undocumented parameters. It adds useful meaning for name, value, unit, start_beats, and end_beats, including gain/dB semantics and range inclusion rules, but it omits explanation of required track_index and envelope_index and does not describe the point object fields such as shape, tension, or selected.

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 identifies the resource (track envelopes) and the three operations (list, get, set), with additional detail about point replacement and ranges. It is clear enough to distinguish the tool from unrelated siblings, but it does not explicitly differentiate it from nearby tools such as track or send.

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 description explains the modes of action=list/get/set and clarifies how set and get behave with start_beats/end_beats ranges. However, it gives no explicit guidance on when to choose this tool over sibling tools like track, send, or item.

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

Deploy Server