Skip to main content
Glama
Sign In
ReaperMCP

ReaperMCP

by xDarkzx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

envelope_add_points

Batch-insert automation points into track or FX parameter envelopes, creating the envelope when needed and setting time, value, shape, and tension.

Instructions

Batch-insert automation points into an envelope.

Point shape codes: 0=linear, 1=square, 2=slow start/end, 3=fast start, 4=fast end, 5=bezier. Tension -1 to +1 for curve skew.

Value units:

  • Volume track env: linear gain where 1.0 = unity (0 dB), 2.0 ≈ +6 dB, 0.5 ≈ -6 dB. Use 10**(db/20) to convert from dB. WARNING: 0.0 = −inf dB (total silence). NEVER clamp a negative dB value to 0.0 — convert it instead: value = 10 ** (db / 20) # e.g. -6 dB → 0.501

  • Pan: -1.0 (hard left) to +1.0 (hard right).

  • Mute: 0.0 or 1.0.

  • FX params: 0.0-1.0 normalized (same as setup_fx_chain's params/params_by_index).

Args: track_index: Track. points: JSON array of {"time":s, "value":v, "shape":0, "tension":0}. envelope_name: Track envelope name (ignored with FX param). fx_index / param_index: Target FX param envelope (-1 for track env). create: If the envelope doesn't exist yet, create it (default True). Creating keeps the track's fader, pan, width and track selection as they were.

Input Schema

NameRequiredDescriptionDefault
createNo
pointsYes
fx_indexNo
param_indexNo
track_indexYes
envelope_nameNoVolume

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.8/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 behavioral burden and does so well: it discloses that creating an envelope preserves the track's fader, pan, width, and selection, and warns about the critical 0.0 = -inf dB silence case. These are significant side-effect and safety details beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose, then organized into point-shape codes, value units, and argument notes. The length is justified given zero schema description coverage and the complexity of automation values; every section adds usable detail.

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

Completeness5/5

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

For a six-parameter mutation tool with no annotations and no output schema, the definition provides enough detail to invoke it correctly, including units, shape codes, sentinels, and create-side effects. Return/error behavior is not described, but that is a minor omission for this add-points operation.

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

Parameters5/5

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

Schema description coverage is 0%, but the description compensates thoroughly for all six parameters. It explains the points JSON object shape, shape codes, tension range, value units for volume/pan/mute/FX params, the -1 sentinel for FX targeting, and create behavior.

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?

The description states a specific verb and resource: 'Batch-insert automation points into an envelope.' It is clearly distinguishable from sibling tools like envelope_get_points and envelope_clear_range, and the scope is apparent without opening the schema.

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?

The description gives clear context for adding points, including the create default and how to target FX parameter envelopes versus track envelopes. It does not explicitly name alternatives such as envelope_get_points for inspecting or envelope_clear_range for removal, so it stops short of full when/when-not guidance.

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