The reaper-mcp server provides comprehensive control over the REAPER DAW via an MCP interface, exposing tools (all prefixed with reaper_) that enable an LLM or any MCP client to:
Project & Transport: Get project info (name, length, tempo, cursor position, transport state, track count); set tempo; play, stop, pause, and record; move the edit cursor; set/clear time selections; enable/disable looped playback; render the project to disk using last-used render settings.
Track Management: List, create, rename, and delete tracks; get/set volume (dB), pan, mute, solo, and arm state; set record input; set automation mode (trim/read/touch/write/latch/etc.).
Master Track: Get/set master track volume and pan.
FX / Plugin Management: List installed FX plugins (VST2/VST3/CLAP/JS/AU) with filtering; add/remove FX on tracks; enable or bypass FX; list/set FX parameters by index or name; list and switch FX presets.
Automation: Add envelope points for track volume, pan, or any FX parameter with configurable interpolation shapes (linear, bezier, square, etc.); clear envelopes.
MIDI & Media Items: List media/MIDI items on a track; insert empty MIDI items; add individual MIDI notes (pitch, velocity, channel, timing); delete media/MIDI items; insert existing audio/MIDI files from disk.
Routing: List, add, remove, and set volume on track sends.
Markers & Regions: List, add, and delete markers and regions; navigate the edit cursor to a marker.
Mix Analysis: Analyze a rendered or quick-exported audio file for DSP metrics (LUFS, loudness range, peak, crest factor, clipping, per-band EQ balance, stereo width/correlation); optionally get AI-powered feedback via Gemini with reference track comparison.
Escape Hatch: Execute any REAPER action by numeric command ID for functionality not explicitly wrapped as a dedicated tool.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@reaper-mcp list my installed synths"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives Claude Code (or any MCP client) full control of Reaper.
Claude can:
List every VST/VST3/CLAP/JS/AU plugin you have scanned
Add plugins to tracks, set parameters, and pick presets
Move volume faders, pan, mute, solo (track and master)
Write automation envelopes (track volume/pan or any FX parameter)
Set up track sends / routing
Create/rename/delete tracks; create/delete media & MIDI items and write MIDI notes (one at a time or a whole part in one batch call)
Insert existing media files — audio samples/loops or .mid clips — onto a track from disk
Add markers and regions; set the time selection and toggle looping
Arm tracks and drive the transport (play / stop / record)
Render the project using the last-used render settings
Trigger any Reaper action by command ID (escape hatch)
All 55 tools are namespaced with a reaper_ prefix (e.g. reaper_create_track) so they
don't collide with other MCP servers. Read tools accept a response_format argument
(markdown for humans, json for machines).
Claude Code ──stdio──▶ reaper-mcp server ──TCP 127.0.0.1:8765──▶ Reaper bridge ReaScript
(MCP) (this package) (runs inside Reaper)The bridge is a Python ReaScript that lives inside Reaper. It opens a non-blocking
TCP listener and polls it from reaper.defer so the DAW UI never freezes.
Every mutation is wrapped in Undo_BeginBlock / Undo_EndBlock, so anything Claude does
is a single undo step.
Related MCP server: reaper-mcp-server
Reaper installed (default location: C:\Program Files\REAPER (x64)\)
Python ReaScript enabled in Reaper. Open Options → Preferences → Plug-ins → ReaScript
and point "Custom path to Python dll" at your Python install (e.g. C:\Users\<you>\AppData\Local\Programs\Python\Python311\).
Restart Reaper. The page should say Python loaded successfully.
Python 3.10+ on your host machine for the MCP server itself.
cd "C:\Users\tommy\Desktop\CODING STUFF\reaper-mcp"
py -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -e .Copy reaper_scripts\reaper_mcp_bridge.py into %APPDATA%\REAPER\Scripts\.
In Reaper: Actions → Show action list → ReaScript: Load → pick the file → Run.
You should see [reaper-mcp] bridge listening on 127.0.0.1:8765 in the ReaScript console.
Optional: in the action list, right-click the loaded action and "Add to toolbar", so you can start the bridge with one click. To make it auto-start with Reaper, install SWS Extension and use SWS: Set startup action.
Add to your Claude Code MCP config (%APPDATA%\Claude\claude_desktop_config.json for Claude Desktop, or ~/.claude.json / project settings for Claude Code):
{
"mcpServers": {
"reaper": {
"command": "C:\\Users\\tommy\\Desktop\\CODING STUFF\\reaper-mcp\\.venv\\Scripts\\python.exe",
"args": ["-m", "reaper_mcp.server"]
}
}
}Restart Claude Code. Verify with the reaper_ping tool — it should return Reaper's version.
Ask Claude things like:
"List every synth I have installed." → reaper_list_installed_fx filtered to instruments
"Make a new track called 'Bass', drop Serum on it, and switch to the first preset." → reaper_create_track → reaper_add_fx_to_track → reaper_list_fx_presets → reaper_set_fx_preset
"Automate the volume of track 1 to fade in over the first 4 seconds." → reaper_add_envelope_point × 2
"Send track 2 to a reverb bus and pull the send down 6 dB." → reaper_add_send → reaper_set_send_volume_db
"Drop a 2-bar MIDI clip on track 3 and write a C major chord." → reaper_insert_midi_item → reaper_add_midi_notes (all 3 notes in one call)
"Mark the chorus at 32 seconds." → reaper_add_marker
"Arm track 1 and start recording." → reaper_set_track_record_arm → reaper_transport_record
Env var | Default | Effect |
|
| Where the MCP server looks for the bridge |
|
| Bridge TCP port (set on both sides if you change it) |
could not reach Reaper bridge — the bridge script isn't running. Re-load it via the action list. Check Reaper's ReaScript console for errors.
Python ReaScript not loaded in Reaper — point Preferences → Plug-ins → ReaScript at a Python install of the same bitness (Python 3.x x64 for Reaper x64) and restart.
could not add FX 'X' (not found?) — call reaper_list_installed_fx and copy the exact name (including the VST3: / VST3i: prefix). Reaper matches by exact suffix.
Preset name doesn't match — some plugins expose presets as .fxp files in %APPDATA%\REAPER\presets\vst-<plugin>\. Call reaper_list_fx_presets to see what Reaper actually sees.
Automation doesn't seem to do anything — set the track to read mode: reaper_set_track_automation_mode(idx, "read").
To add a tool:
Write an h_<method> handler in reaper_scripts/reaper_mcp_bridge.py and register it in HANDLERS.
Add a @mcp.tool(name="reaper_<verb_noun>", annotations={...}) wrapper in reaper_mcp/server.py
that calls _call("<method>", ...). Validate inputs with Annotated[type, Field(...)] and Enum
types, give read tools a response_format argument, and let failures raise (do not return an
error dict — _call raises so FastMCP reports it as an isError result).
Re-load the bridge script in Reaper (Actions list → ReaScript: Load) and restart the MCP server in Claude Code.
The method-name string is the contract between the two files and must match exactly on both sides.
evaluations/reaper_eval.xml holds read-only eval questions (mcp-builder Phase 4) for checking that an
LLM can drive the server. See evaluations/README.md for how to run them and verify answers against a
live project.
Insert one automation point on a track volume/pan or FX-parameter envelope.
Tip: if the envelope can't be obtained, set the track to read mode first
via reaper_set_track_automation_mode(track_index, 'read').
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| target | Yes | Which envelope to write to | |
| time_sec | Yes | Point time in seconds from project start | |
| value | Yes | Point value. For volume: linear gain unless value_is_db=True. For pan: -1..1. For fx_param: the parameter's native value | |
| fx_index | No | Required when target='fx_param': the 0-based FX index | |
| param | No | Required when target='fx_param': parameter index or name | |
| shape | No | Interpolation shape to the next point | linear |
| value_is_db | No | For target='volume', interpret value as dB instead of linear gain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by warning about envelope availability and suggesting a fix. It implies that the operation may fail if the envelope is not writable, which is useful. Annotations already indicate it's a write, non-destructive, non-idempotent operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states the purpose, second gives a practical tip. No wasted words, front-loaded, and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, no output schema) and that annotations cover safety, the description is reasonably complete with the tip. It could mention behavior when a point already exists at the same time, but schema covers value meaning. Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are documented. The description does not add extra information about parameters; it only provides a usage tip. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inserts one automation point on a track volume/pan or FX-parameter envelope. It uses specific verb and resource, and distinguishes from sibling tools like reaper_clear_envelope or reaper_set_track_volume_db.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tip provides guidance on a common prerequisite (setting track to read mode if envelope can't be obtained), but does not explicitly compare this tool to alternatives like reaper_set_track_automation_mode or explain when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an FX to the end of a track's chain.
Returns {track_index, fx_index, name}. If the plugin can't be found the
call fails — re-check the exact string via reaper_list_installed_fx.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| fx_name | Yes | Plugin name as returned by reaper_list_installed_fx, e.g. 'VST3i: Serum (Xfer Records)'. A bare name like 'Serum' works if unambiguous. | |
| show_ui | No | Pop open the plugin's floating window |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false), description explains return value structure and failure mode when plugin not found. Provides useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states core function, second details return and failure mode. No fluff, efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, description covers return structure and failure handling. Schema fully documents parameters. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds value by explaining the failure case and referencing reaper_list_installed_fx for exact plugin names, which enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States 'Add an FX to the end of a track's chain' with specific verb and resource. Distinguishes from siblings like reaper_remove_fx or reaper_set_fx_enabled.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context for when to use (adding FX to end of chain). Guidance on failure: if plugin not found, re-check with reaper_list_installed_fx. Lacks explicit when-not-to-use or alternative tools, but this is implied by sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a project marker at a time. Returns {id, is_region, position_sec}.
| Name | Required | Description | Default |
|---|---|---|---|
| position_sec | Yes | Marker time in seconds | |
| name | No | Marker label |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return value structure ('{id, is_region, position_sec}'), which adds value beyond annotations. Annotations indicate it is not read-only and not destructive, and the description aligns. However, it does not mention any potential side effects or authorization needs, which are relevant given the openWorldHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence stating the action and a brief note on the return value. Every word serves a purpose, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and a clear action, the description provides the essential information: what it does and what it returns. However, it does not address the openWorldHint or differentiate itself from siblings beyond the basic action. It is adequate but could be slightly more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are already well-described in the input schema (position_sec: 'Marker time in seconds', name: 'Marker label') with 100% coverage. The description does not add any additional meaning beyond what the schema provides, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a project marker') and specifies the resource. It distinguishes from sibling tools like reaper_delete_marker or reaper_goto_marker by indicating it is for adding markers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives, nor are there any exclusions or prerequisites mentioned. The usage context is only implied by the tool's name and action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insert a single MIDI note into an existing MIDI item on a track.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| item_index | Yes | 0-based item index from reaper_list_items | |
| pitch | Yes | MIDI note number 0-127 (60 = middle C) | |
| start_sec | Yes | Note start in seconds (project time) | |
| length_sec | Yes | Note duration in seconds | |
| velocity | No | Note velocity 1-127 | |
| channel | No | MIDI channel 0-15 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only, destructive, or idempotent, but the description adds no further behavioral context. It does not mention side effects (e.g., project state modification) or prerequisites (e.g., item must exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded and easy to read, though it could benefit from structuring (e.g., bullet points) for complex tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no nested objects, no output schema), the description is adequate but minimal. It covers the core function but omits details like return value (none) or project state change. With good schema coverage, it is minimally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond what the schema provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('insert a single MIDI note') and the target ('existing MIDI item on a track'). It distinguishes from sibling tools like reaper_insert_midi_item, which likely creates a new item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when adding a note to an existing MIDI item, but does not explicitly state when not to use it or mention alternatives like reaper_insert_midi_item for new items. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a project region spanning [start, end] seconds. Returns {id, is_region, position_sec}.
| Name | Required | Description | Default |
|---|---|---|---|
| start_sec | Yes | Region start in seconds | |
| end_sec | Yes | Region end in seconds (must be >= start) | |
| name | No | Region label |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a mutation (readOnlyHint false) and non-destructive (destructiveHint false). The description confirms mutation by saying 'Add' and specifies the return value, but does not disclose behavioral traits beyond what annotations already imply, such as side effects or undoing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the verb and resource, and provides the output format. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description covers purpose, input parameters, and return structure. Minor gaps include lack of error handling or explanation of 'is_region', but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to compensate. It adds no extra meaning beyond the schema; the mention of 'spanning [start, end] seconds' repeats schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Add a project region' and specifies the resource (region) with its scope in seconds. It distinguishes from siblings like reaper_add_marker by focusing on regions and providing the return type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool over alternatives like reaper_add_marker. It implicitly indicates usage for creating regions but lacks exclusion criteria or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a send from one track to another. Returns the new send's index.
| Name | Required | Description | Default |
|---|---|---|---|
| src_track_index | Yes | 0-based index of the source track | |
| dest_track_index | Yes | 0-based index of the destination track |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a mutation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds that it creates a send and returns an index, but doesn't explain side effects like routing changes or track state modifications. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences (17 words total) convey purpose and return value with no fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with 2 parameters, the description covers the essential action and return value. It lacks error conditions (e.g., invalid track indices) but annotations and schema fill some gaps. Almost complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds no extra meaning beyond the parameter names and types. It doesn't explain how indices relate to track ordering or what valid ranges are (though schema provides minimum). Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create a send'), the resource ('from one track to another'), and the return value ('Returns the new send's index'). It distinguishes from sibling tools like 'remove_send' and 'list_sends'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives (e.g., 'list_sends' to check existing sends before adding). No prerequisites or when-not-to-use context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a rendered mix: local DSP measurements + AI listening feedback.
Two layers. Local DSP (numpy/pyloudnorm) measures the trustworthy numbers — integrated LUFS, loudness range, sample peak, crest factor, clipped samples, per-band frequency balance, and stereo correlation/width/balance. Then (unless include_ai=false) Gemini is given BOTH the audio file and those measurements and returns grounded mix/master feedback with concrete REAPER fixes.
Requires the optional deps: pip install -e .[analyze], and GEMINI_API_KEY in the
environment for the AI layer. Pass a reference_path to compare against a pro track.
This reads files and calls an external API; it never modifies the Reaper project.
| Name | Required | Description | Default |
|---|---|---|---|
| audio_path | Yes | Path to the rendered audio file to analyze (WAV/MP3/FLAC/AAC). Render the project first (reaper_render_project) and pass that file. | |
| focus | No | Optional free-text note on what to focus on, passed to Gemini (e.g. 'the vocal sounds buried', 'too boomy on small speakers'). | |
| reference_path | No | Optional path to a reference/commercial track to compare against. | |
| include_ai | No | If true, send the audio + metrics to Gemini for written feedback. If false, return only the measured DSP metrics (no API call). | |
| model | No | Gemini model that listens to the mix: 'gemini-2.5-flash' (fast/cheap) or 'gemini-2.5-pro' (deeper analysis). | gemini-2.5-flash |
| response_format | No | 'markdown' for human-readable output or 'json' for machine-readable | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, destructive, idempotent), the description adds valuable behavioral details: it reads files, calls an external API (Gemini), requires specific deps and environment variable, and explicitly states it never modifies the project. This fully informs the agent of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with front-loaded purpose and efficient paragraphs, each sentence adding value. Slightly verbose but still concise enough for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two layers, dependencies, external API, optional reference), the description covers all necessary aspects: required setup, behavior, output options, and non-destructive nature. With an output schema present, the description is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. The description adds context for the tool's two layers but does not significantly enhance understanding of individual parameters beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes a rendered mix using two layers (local DSP and AI listening), specifies verb+resource, and distinguishes from sibling tools like reaper_analyze_project by focusing on mix analysis and mentioning it never modifies the project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on prerequisites (deps, API key), optional reference path, and the include_ai flag, and implies when to use this tool (after rendering, for mix analysis). However, it does not explicitly compare to reaper_analyze_project or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-call mix check: quick-export the master mix, then analyze it.
This is the convenient path — no need to pre-configure the render dialog or pass a file. It tells Reaper to render the master mix to a temp file (reusing your project's render codec, e.g. WAV), measures it with local DSP (LUFS, peak, crest, per-band balance, stereo width), then — unless include_ai=false — uploads a small compressed proxy plus those measurements to Gemini for grounded feedback.
Requires the optional deps (pip install -e .[analyze]) and GEMINI_API_KEY for the
AI layer. For best results set the project's render source to 'Master mix' and format
to a single audio file. Writes a temp render but does not modify the project.
| Name | Required | Description | Default |
|---|---|---|---|
| focus | No | Optional free-text note on what to focus on, passed to Gemini (e.g. 'the vocal sounds buried', 'too boomy on small speakers'). | |
| reference_path | No | Optional path to a reference/commercial track to compare against. | |
| bounds | No | Render the whole 'project' or just the current 'time_selection'. | project |
| include_ai | No | If true, send a small audio proxy + metrics to Gemini for written feedback. If false, return only the measured DSP metrics (no API call). | |
| model | No | Gemini model that listens to the mix: 'gemini-2.5-flash' (fast/cheap) or 'gemini-2.5-pro' (deeper analysis). | gemini-2.5-flash |
| response_format | No | 'markdown' for human-readable output or 'json' for machine-readable | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: it renders to a temp file (reusing project's render codec), measures local DSP (LUFS, peak, crest, per-band balance, stereo width), and optionally uploads a small proxy to Gemini. It explicitly states 'Writes a temp render but does not modify the project,' which adds crucial context beyond annotations (idempotentHint=true). It also mentions dependencies and key requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured in three short paragraphs. The first sentence is a clear summary. It front-loads the purpose and then covers prerequisites, behavioral details, and parameter implications. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, with output schema, and integration with rendering and AI), the description covers the full workflow: what happens, what is required, what the user can expect. It explains the optional AI layer and the fallback. The output schema exists, so return values do not need to be detailed in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is described. The description adds context: 'focus' is a free-text note passed to Gemini, 'include_ai' controls whether upload happens, 'bounds' for render span, etc. It also explains the effect of include_ai=false (only DSP metrics, no API call). This enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'One-call mix check: quick-export the master mix, then analyze it.' This distinguishes it from siblings like reaper_render_project (which likely only renders) and reaper_analyze_mix (which probably analyzes an existing mix). It specifies the verb 'analyze' and resource 'project' with the action of rendering first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description frames this as the 'convenient path' without needing to pre-configure the render dialog, implying it simplifies the workflow. It also gives prerequisites: setting project's render source to 'Master mix', format to single audio file, and requiring optional deps and GEMINI_API_KEY for AI. It does not explicitly state when not to use or name alternatives, but the sibling list provides context for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete every point on an envelope. Same target semantics as reaper_add_envelope_point.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| target | Yes | Which envelope to clear | |
| fx_index | No | Required when target='fx_param' | |
| param | No | Required when target='fx_param': parameter index or name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds that it deletes every point on an envelope, which aligns with destructive. It also clarifies the target semantics via reference. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the action, the second provides targeting context. Concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and is destructive, the description covers the core action and target semantics. However, it does not mention the return value (likely void) or the effect on the envelope after clearing. With no output schema, a bit more detail would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds value by referencing the target semantics of a sibling tool, which helps understand the 'target' parameter. However, it does not provide additional details beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Delete), the resource (every point on an envelope), and references sibling tool reaper_add_envelope_point for target semantics. It is specific and distinguishes this tool from others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by referencing 'same target semantics as reaper_add_envelope_point', but does not explicitly state when to use this tool versus alternatives like reaper_set_track_automation_mode or reaper_add_fx_to_track. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear the project time selection.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent, non-destructive, and open-world behavior. The description adds no additional behavioral context, such as side effects or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence with no wasted words. Perfectly concise for the action described.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is sufficiently complete. However, it could briefly mention that this reverses a time selection set by set_time_selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. Baseline score of 4 applies per guidelines for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Clear' and resource 'project time selection', distinguishing it from sibling tool reaper_set_time_selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives. The context implies it is for removing the time selection, but no exclusion criteria or when-not advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insert a new track. Returns the new track's state including its assigned index.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Name for the new track (empty for unnamed) | |
| position | No | 0-based insert position; -1 appends to the end |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the description does not need to repeat safety. It adds that the tool returns the track's state and index, which is useful. However, it does not disclose potential failure modes (e.g., reaching track limit) or any side effects beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences totaling 14 words. Every word adds value, and the key information (action and return) is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no output schema), the description covers the essential purpose and return value. It does not specify the format of the returned state, but for a creation tool this is adequate. The combination with rich schema descriptions provides sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for parameters is 100% (both name and position have descriptions). The tool description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Insert a new track' and specifies the return value 'Returns the new track's state including its assigned index.' This immediately distinguishes it from sibling tools like reaper_delete_track or reaper_list_tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. While the purpose is clear, it does not mention prerequisites, such as the need for a project to exist, or when not to use it (e.g., if the track limit is reached). The context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a media/MIDI item from a track. Later item indices shift down by one.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| item_index | Yes | 0-based item index from reaper_list_items |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, but the description adds a specific behavioral effect: 'Later item indices shift down by one.' This informs the agent about index reordering, which is critical for correctness. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the action clearly, and the second adds a crucial behavioral note. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with full schema coverage and destructive annotations, the description captures the core action and index shifting effect. It could mention undo behavior or envelope handling, but is generally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with descriptions (100% coverage). The description does not add meaning beyond what the schema provides; it only contextualizes the operation, not the parameters themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Delete a media/MIDI item from a track,' which clearly identifies the verb and resource. It distinguishes from sibling tools like reaper_delete_marker (deletes markers) and reaper_delete_track (deletes tracks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting items, but lacks explicit when-not-to-use or alternative tools. It mentions index shifting, which is helpful for usage context but does not provide exclusions like 'use reaper_delete_track to remove entire track.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a project marker or region by its id.
| Name | Required | Description | Default |
|---|---|---|---|
| marker_id | Yes | The marker/region 'id' from reaper_list_markers | |
| is_region | No | True if deleting a region, False for a marker |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds no further behavioral context (e.g., what happens if marker_id is invalid or already deleted).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no unnecessary words. Front-loaded with the action and object. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with good schema and annotations, it is minimally adequate. However, it lacks guidance on error handling or when to use this vs other deletion tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The tool description does not add any meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'project marker or region by its id'. It is specific and distinguishes from sibling tools like reaper_add_marker or reaper_add_region.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives (e.g., reaper_delete_item, reaper_delete_track). No when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete the track at the given index. This is destructive and shifts later indices down by one.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based index of the track to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the context that deletion 'shifts later indices down by one', which goes beyond the destructive hint already in annotations. This provides critical operational understanding. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, directly stating the action and a key side effect. No extraneous information, efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter with full schema coverage and no output schema, the description adequately explains the tool's behavior (delete and shift indices). It is sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes 'track_index' as a 0-based index. The description does not add additional semantic meaning beyond what the schema provides. With 100% schema coverage, baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete the track at the given index', specifying the verb and resource. It distinguishes from sibling tools like reaper_delete_item by focusing on tracks and mentioning the side effect of index shifting, which is unique to track deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives such as muting or rendering without the track. The destructive nature and index shifting are implied but not framed as guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the master track's volume (dB), pan, mute state, and FX count.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | 'markdown' for human-readable output or 'json' for machine-readable | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as readOnly, destructiveHint, and idempotent. The description adds the actual returned data fields but does not disclose additional behavioral traits beyond what is annotated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence of 12 words, immediately stating the action and returned data with no unnecessary text or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one optional parameter and an output schema, the description completely covers what the tool does, leaving no ambiguity. The availability of output schema further reduces the need for additional explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the only parameter (response_format) with 100% coverage, including its enum values and default. The description does not add any further meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact resource (master track) and lists four specific attributes (volume, pan, mute state, FX count), clearly differentiating from siblings like reaper_get_track_state and reaper_get_project_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool to get master track information. While it does not explicitly exclude alternatives, the sibling tools (e.g., reaper_get_track_state) imply that this is specifically for the master track, providing sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current project's name, length, tempo, cursor position, transport state, and track count.
Returns a dict: {name, length_sec, tempo_bpm, cursor_sec, playing, paused, recording, track_count}.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | 'markdown' for human-readable output or 'json' for machine-readable | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, which the description aligns with. The description adds specific details about the returned dict fields, beyond just stating it's a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a clear code block listing the return keys. No wasted words; front-loaded with the core information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read nature, full schema coverage, output schema present, and rich annotations, the description is complete. It covers what the tool returns and how to control output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter (response_format) is well-documented in the schema with enum values. The description does not add extra meaning beyond reminding that both formats are available, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('current project's name, length, tempo, cursor position, transport state, and track count'), clearly distinguishing this read-only info tool from siblings that modify or list specific elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when/when-not guidance, but the purpose and sibling names (e.g., reaper_list_tracks, reaper_get_track_state) make it clear this tool is for a holistic overview, not detailed track-level queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return name, volume (dB), pan, mute/solo/arm, and FX count for a single track.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| response_format | No | 'markdown' for human-readable output or 'json' for machine-readable | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the non-destructive nature is clear. The description adds that volume is in dB and lists returned fields. It doesn't mention any side effects or hidden behaviors, so it's adequate given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that concisely conveys the tool's output without unnecessary detail or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations and a complete schema, the description is sufficient to understand what the tool returns. The presence of an output schema (not shown) further reduces the need for return value explanation. It is complete for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (track_index as 0-based index, response_format with enum). The description does not add additional meaning beyond what the schema provides, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Return' and lists the specific fields (name, volume, pan, mute/solo/arm, FX count) for a single track, making the purpose clear. It distinguishes from sibling tools like reaper_list_tracks (all tracks) and reaper_get_master_track (master).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for a single track, implying usage when you need detailed state of one track. It does not explicitly exclude when to use alternatives, but the context of sibling tools provides differentiation (e.g., list_tracks for overview, setter tools for changes).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move the edit cursor to a marker by its id.
| Name | Required | Description | Default |
|---|---|---|---|
| marker_id | Yes | The marker 'id' from reaper_list_markers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is non-destructive, idempotent, and read-write. The description adds minimal behavioral context beyond that (just 'move the edit cursor'). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It conveys the essential action efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the core action. However, it lacks usage context (e.g., when to prefer this over reaper_set_cursor), making it slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema description already clarifies that marker_id is 'The marker id from reaper_list_markers'. The tool description adds no further parameter meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Move', the resource 'edit cursor to a marker', and the method 'by its id'. It distinguishes the tool from sibling tools like reaper_add_marker or reaper_delete_marker.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., reaper_set_cursor). It doesn't mention that the marker_id should be obtained from reaper_list_markers first, which is critical for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an empty MIDI item on a track spanning [start, end] seconds.
Returns {item_index, position_sec, length_sec}. Add notes with
reaper_add_midi_note.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| start_sec | Yes | Item start in seconds | |
| end_sec | Yes | Item end in seconds (must be > start) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-readOnly and non-destructive. The description adds context by specifying the return value (item_index, position_sec, length_sec) and that the item is initially empty. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and constraints, second states return value and related tool. No waste; concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (3 params, all required, no output schema), the description covers purpose, parameters (via schema), return value, and next steps. It could mention the track index is required, but schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with clear descriptions for each parameter. The description does not add extra meaning beyond what's in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Create' and resource 'empty MIDI item', and specifies the time range. It clearly distinguishes from siblings like reaper_add_midi_note by stating it creates the item, not notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that to add notes, use reaper_add_midi_note, providing a clear next step. It implicitly guides when to use this tool (before adding notes). No explicit exclusions, but adequate for a simple creation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List an FX's parameters with current value, min, and max.
Returns a list of {index, name, value, min, max}. Parameter values are
plugin-native (often normalised 0..1) — read min/max before setting.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| fx_index | Yes | 0-based FX index within the track chain | |
| response_format | No | 'markdown' for human-readable output or 'json' for machine-readable | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable context about plugin-native values often being normalized 0..1 and advises reading min/max before setting, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no wasted words. It front-loads the core purpose and then adds necessary context about return format and value normalization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema is reported to exist (though not shown), the description adequately explains the return structure and behavioral nuance. It could mention potential errors or limitations, but for a simple list tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description does not add further meaning to the parameters themselves (track_index, fx_index, response_format) beyond the schema, but it does explain the return format, which is not directly about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists FX parameters with current value, min, and max. It distinguishes from sibling tools like reaper_list_track_fx (lists FX on a track) and reaper_set_fx_param (sets parameters), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly advises usage by stating 'read min/max before setting', implying this tool is a precursor to reaper_set_fx_param. However, it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every preset available for an FX instance, plus the current selection.
Returns {count, current_index, presets:[{index, name}]}.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| fx_index | Yes | 0-based FX index within the track chain | |
| response_format | No | 'markdown' for human-readable output or 'json' for machine-readable | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds value by specifying the exact return structure (count, current_index, presets array) and that it lists 'every preset' plus selection. No contradictions. Could mention error handling or permissions, but not necessary for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the action, the second gives the return format. No filler, front-loaded, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required params, read-only, idempotent), the description plus schema provide sufficient context. The output schema is provided inline. Could mention error cases, but for a list operation it's complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions. The description does not add extra meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with resource 'presets for an FX instance', and mentions returning current selection. It clearly distinguishes from sibling tools like 'reaper_set_fx_preset' (set) and 'reaper_list_fx_params' (list parameters).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading presets of a specific FX instance. It does not explicitly state when to use vs alternatives, but the purpose is clear and the sibling tools are distinct. No exclusion or alternative mentioned, but given the straightforward read operation, it's clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every FX plugin Reaper has scanned (VST2/VST3/CLAP/JS).
Reads Reaper's own scan-cache files directly (no bridge round-trip). Use
this to find the exact fx_name string to pass to reaper_add_fx_to_track.
Each item: name (pass this to add_fx, e.g. "VST3i: Serum (Xfer Records)"),
kind (VST/VSTi/VST3/VST3i/CLAP/CLAPi/JS), is_instrument (bool), filename.
Result is paginated. The response wraps the page in
{total, count, offset, has_more, next_offset, items}.
| Name | Required | Description | Default |
|---|---|---|---|
| name_filter | No | Case-insensitive substring to narrow results (e.g. 'serum', 'reacomp') | |
| instruments_only | No | If true, return only synths/samplers (instruments) | |
| limit | No | Maximum results to return | |
| offset | No | Number of results to skip for pagination | |
| response_format | No | 'markdown' for human-readable output or 'json' for machine-readable | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, not destructive, idempotent. The description adds that it reads scan-cache files directly (no bridge round-trip), which is helpful behavioral context. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is six sentences, each adding value: purpose, implementation, usage hint, item structure, pagination, response format. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, implementation, usage, item structure, and pagination. It does not mention performance or limits beyond the max 2000, but it is fairly complete for a listing tool with good annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a good description in the schema. The description does not add new parameter-level semantics beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists every FX plugin, specifies categories (VST2/VST3/CLAP/JS), and explains it reads scan-cache files. It distinguishes from siblings by providing the exact fx_name for reaper_add_fx_to_track.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool to find the exact fx_name for reaper_add_fx_to_track. It does not explicitly exclude alternatives like reaper_list_track_fx, but the sibling tools list provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the media/MIDI items on a track.
Each entry: {index, position_sec, length_sec, muted, take_name}. Item
index is 0-based within the track and is what the item tools expect.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| response_format | No | 'markdown' for human-readable output or 'json' for machine-readable | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds value by noting that item index is 0-based within the track and that item tools expect this index, providing context beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. The main action is front-loaded, followed by a clear format definition and an important note about index usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the description's explicit listing of the entry format (index, position_sec, length_sec, muted, take_name), the description is complete for a list tool. No further explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with descriptions for both parameters. The description does not add extra meaning beyond the schema; it focuses on output format rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List the media/MIDI items on a track', using a specific verb and resource. It distinguishes from sibling tools like reaper_delete_item or reaper_insert_midi_item, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing items but provides no explicit guidance on when to use this tool versus alternatives (e.g., for inspection before modification). It does not mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all project markers and regions.
Each entry: {index, is_region, position_sec, region_end_sec, name, id}.
id is the marker/region's displayed number — pass it to delete/goto tools.
Known limitation: name may come back empty even when a marker has a name.
REAPER's Python ReaScript build does not marshal the name out-parameter of
EnumProjectMarkers, so names set via reaper_add_marker/reaper_add_region show
in Reaper's UI but can't be read back here. Identify markers by position/id.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | 'markdown' for human-readable output or 'json' for machine-readable | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosure of known limitation about empty name field is critical for correct agent behavior. Annotations already indicate safe read-only operation, description adds valuable nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one line for purpose, one line for output format, one line for id usage, one paragraph for limitation. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers what tool returns (fields), how id is used (deletion/goto), and important caveat about name. Despite no output schema in provided input, description compensates fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter response_format is fully documented in schema with description and enum. Description adds no additional semantics, which is acceptable given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List all project markers and regions' with specific verb and resource. Distinguishes from siblings like reaper_add_marker and reaper_delete_marker.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly implies when to use (to see all markers/regions) but does not explicitly state when not to use. However, sibling tools cover add/delete/goto, so context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the sends originating from a track.
Each entry: {send_index, dest_track_index, dest_track_name, volume_db, pan, muted}.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based index of the source track | |
| response_format | No | 'markdown' for human-readable output or 'json' for machine-readable | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint. The description adds output format details, enhancing transparency without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: purpose then output format. No fluff, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Combined with annotations and output schema, the description fully covers what the tool does and returns, with no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description does not add new meaning beyond the schema for parameters; it focuses on output fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'sends originating from a track', and distinguishes from sibling tools like reaper_add_send and reaper_remove_send.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading existing sends, but does not explicitly mention when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List FX on a track with each FX's index, name, current preset, enabled state, and param count.
FX index is 0-based within the track's chain and is what the other FX
tools expect.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| response_format | No | 'markdown' for human-readable output or 'json' for machine-readable | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating a safe, idempotent read operation. The description adds context about the 0-based index and the list contents, but does not contradict annotations. No mention of other behavioral traits beyond what annotations provide, so score is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first explains the tool's output, the second provides critical context about the 0-based index. No redundant or extraneous words, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (context signal), the description does not need to detail return values. It covers the essential details: what FX info is returned and how the index is used. The only minor gap is lack of mention of error handling or performance, but overall it's sufficiently complete for a read tool with robust annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters (track_index, response_format) fully described in the input schema. The description does not add any additional meaning or usage details for the parameters, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List FX on a track') and specifies the exact data returned (index, name, preset, enabled state, param count). It distinguishes from siblings like reaper_list_fx_params and reaper_list_fx_presets by focusing on FX on a track rather than their parameters or presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that the FX index is 0-based and used by other FX tools, providing important context for subsequent operations. However, it does not explicitly state when to use this tool vs alternatives (e.g., reaper_list_installed_fx for all available FX) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tracks with index, name, volume (dB), pan, mute/solo/arm state, and FX count.
Track index is 0-based and is the value every other track tool expects.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | 'markdown' for human-readable output or 'json' for machine-readable | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so no contradiction. The description adds value by detailing the returned fields and the index convention, but doesn't elaborate on potential limits (e.g., large projects) or pagination, which is acceptable given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences: first lists output fields, second gives critical usage hint about 0-based indexing. No unnecessary words, perfectly front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, output content, and an important usage note. An output schema exists (though not provided), reducing the need for return value details. It misses mentioning the response_format parameter's effect on output, but that's minor given schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description doesn't need to explain the single parameter (response_format). The description adds no extra parameter details, but the schema itself is clear. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all tracks with specific fields (index, name, volume, etc.), distinguishing it from sibling tools like reaper_get_track_state that focus on a single track. It also clarifies the 0-based index used by other tools, leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent that the track index is 0-based and used by other track tools, guiding when to use this tool (to obtain indices for subsequent operations). However, it does not mention when to avoid using it or suggest alternatives like reaper_get_track_state for single-track queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check that the Reaper bridge is alive and report Reaper's version.
Call this first when anything fails — a clean response confirms both the MCP server and the in-Reaper bridge script are running and reachable.
Returns: {pong: bool, reaper_version: str}.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | 'markdown' for human-readable output or 'json' for machine-readable | markdown |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds that the tool reports Reaper's version and returns a specific structure, providing extra context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, usage guidance, return. Front-loaded with key information, no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health-check tool, the description fully covers purpose, usage, and return format. The annotations provide safety profile, and the schema covers the single parameter. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter 'response_format' is fully defined in the schema with default and description. The description does not add new information about parameters, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Check that the Reaper bridge is alive') and specifies the resource and action, distinguishing it from sibling tools that perform other operations like adding tracks or effects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool ('Call this first when anything fails') and explains what a clean response confirms, giving clear guidance on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an FX from a track's chain. Indices of later FX shift down by one.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| fx_index | Yes | 0-based FX index within the track chain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, so the description adds value by explaining that 'Indices of later FX shift down by one', a key side effect. This goes beyond the annotation and helps the agent understand the impact on the track chain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no filler. The first sentence states the purpose, and the second adds a crucial behavioral detail. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter destructive operation without an output schema, the description is largely complete. It covers the main action and side effect. However, it does not mention error conditions (e.g., invalid indices) or confirm success, which would be useful but are not strictly necessary given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters ('0-based track index', '0-based FX index within the track chain'), achieving 100% coverage. The description adds no further parameter semantics, so it meets the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Remove an FX from a track's chain', using a specific verb and resource. It also clarifies the effect on indices, which distinguishes this from other tools like reaper_set_fx_enabled that disable but do not remove.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies use for removal, but does not mention scenarios where disabling might be preferred or any prerequisites like track existence. This is a basic level of guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a send from a track. Later send indices shift down by one.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based index of the source track | |
| send_index | Yes | 0-based send index from reaper_list_sends |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral detail beyond annotations: 'Later send indices shift down by one' explains the side effect of removal. Annotations already indicate destructiveHint=true, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core action and a key behavioral consequence with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a removal tool with simple parameters and full schema coverage, the description is largely complete. It explains the index-shifting effect, though it could mention undo behavior or track state implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides full descriptions for both parameters (100% coverage). The tool description does not add additional semantic information beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Remove a send from a track' with specific verb and resource, and distinguishes it from sibling tools like reaper_add_send and reaper_list_sends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use by stating what it does, but it does not explicitly provide when-not-to-use or mention alternatives. This is adequate but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename a track. Returns the updated track state.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| name | Yes | New track name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and non-destructive. The description adds that it returns updated track state, but doesn't provide additional behavioral context beyond what annotations convey. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences, front-loaded with the action and return value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple rename tool with two required parameters and no output schema, the description covers the core action and return. However, it could mention the effect on existing track state or validation (e.g., name length) but is largely complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description does not add new meaning beyond what the schema already provides; it simply restates 'rename' and 'returns updated state' without parameter specifics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Rename' and the resource 'track,' distinguishing it from sibling tools like delete_track or set_track_mute. The return of updated track state is also specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Siblings include many track modifications, but no context about prerequisites or situations favoring rename over other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render the project to disk using Reaper's most recent render settings.
This reuses whatever output path, bounds, and format were last configured in Reaper's Render dialog — set those up once manually first. Writes a file but does not modify the project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint (false), destructiveHint (false), idempotentHint (false), and openWorldHint (true). The description expands on these by stating the tool reuses previous settings (no parameters needed) and that it writes a file but does not modify the project, which aligns with the annotations and adds valuable detail about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey the tool's function, prerequisites, and effect. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description fully covers what the agent needs to know: what it does, its prerequisites, and its side effects. The contextual signals confirm the simplicity, so the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds value by explaining why there are no parameters (reuses previous settings), which compensates for the lack of schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders a project to disk using Reaper's last render settings, with specific mention of output path, bounds, and format. This distinguishes it from all sibling tools, none of which perform rendering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs users to set up render settings manually first, providing crucial context. It also clarifies that the tool writes a file without modifying the project, helping agents understand when to use it. No direct alternative is mentioned, but no sibling tool serves the same purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger any Reaper action by numeric command ID (Main_OnCommand).
The escape hatch for actions not yet wrapped as dedicated tools. Look up IDs in Reaper's Actions list (right-click an action → Copy selected action command ID). Marked destructive because arbitrary actions can do anything.
| Name | Required | Description | Default |
|---|---|---|---|
| command_id | Yes | Numeric Reaper action command ID (from the Actions list) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description echoes annotations by mentioning destructive hint and adds context about arbitrary actions. However, annotations already provide readOnlyHint, destructiveHint, and openWorldHint, so the description adds minimal new behavioral insight beyond confirming the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is four short, front-loaded sentences. Every sentence serves a distinct purpose: purpose statement, use-case, lookup instructions, and warning. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with thorough annotations and a clear escape-hatch role, the description covers purpose, usage, parameter sourcing, and safety. No output schema exists but not needed given simplicity. A minor gap: it could mention whether the action's result is observed elsewhere, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes command_id as numeric ID from Actions list; description reinforces with explicit lookup steps (right-click → copy). With 100% schema coverage, the description adds extra practical guidance on obtaining the ID value, elevating it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Trigger any Reaper action by numeric command ID' with specific verb and resource. It distinguishes from sibling tools like reaper_add_marker and reaper_transport_play by framing this as a generic escape hatch for unwrapped actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says 'escape hatch for actions not yet wrapped as dedicated tools' and provides lookup instructions for command IDs. It also warns about the destructive nature, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move the edit cursor to a time in seconds. Returns the resulting cursor position.
| Name | Required | Description | Default |
|---|---|---|---|
| time_sec | Yes | Cursor position in seconds from project start | |
| move_view | No | Scroll the arrange view to follow the cursor |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description accurately states the tool modifies the cursor position and returns the new value. Annotations indicate idempotentHint=true and destructiveHint=false, which align. No contradictions. The description adds value by noting the return value, but does not elaborate on potential side effects beyond what is implied by the move_view parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that efficiently conveys the core action and return behavior. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description adequately covers the primary behavior and return value. However, it does not mention edge cases such as invalid time_sec values or behavior when move_view is false. Slightly above adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters already described. The description does not add new meaning beyond restating the schema. Baseline score of 3 is appropriate as no additional clarification is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Move' and the resource 'edit cursor' with a specific parameter 'time in seconds'. It distinguishes this tool from siblings like reaper_goto_marker (which jumps to markers) and transport controls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as reaper_goto_marker or reaper_transport_play. The description lacks context about prerequisites, limitations, or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable or bypass an FX (enabled=False bypasses it without removing it).
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| fx_index | Yes | 0-based FX index within the track chain | |
| enabled | Yes | True to enable, False to bypass |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutability and idempotency. The description adds that bypassing does not remove the FX, a helpful behavioral detail beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, directly states the action, no unnecessary words. Perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (3 parameters, no output schema), the description is sufficient. Could mention that track and FX must exist, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and describes each parameter adequately. The description adds no extra information about parameters beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('enable or bypass') and resource ('an FX'). It distinguishes from sibling tools like reaper_remove_fx and reaper_set_fx_param.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States when to use (enable/bypass an FX) but does not explicitly exclude other scenarios or list alternatives. However, sibling context makes it clear this is for toggling enabled state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set an FX parameter by index or name. Returns {param_index, value, min, max}.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| fx_index | Yes | 0-based FX index within the track chain | |
| param | Yes | Parameter index as a string, or a (case-insensitive) parameter name from reaper_list_fx_params | |
| value | Yes | New value, within the parameter's min..max range |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and non-destructive nature. Description adds return value shape, enhancing understanding beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with action and return type. Highly efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-param setter with no output schema, description covers purpose, parameter use, and return. Minor missing context on error handling or prerequisites (e.g., track must exist).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description already covers all parameters (100% coverage). Description adds no new meaning to parameters beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'Set an FX parameter by index or name', with verb, resource, and method. Distinct from siblings like reaper_set_fx_enabled and reaper_set_fx_preset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions that param can be a name from reaper_list_fx_params, which implies a workflow, but no explicit when-to-use or when-not-to-use compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch an FX to a preset by name or by index.
Provide exactly one of preset_name or preset_index. Use
reaper_list_fx_presets to discover valid values.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| fx_index | Yes | 0-based FX index within the track chain | |
| preset_name | No | Preset name to select (use this OR preset_index) | |
| preset_index | No | Preset index to select; -1 means 'use preset_name instead' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Warns about providing exactly one of preset_name or preset_index, which is a behavioral constraint. Annotations already indicate idempotent and open-world behavior; description adds no additional behavioral traits beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second adds necessary usage instruction. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main action and parameter constraint well. Lacks mention of return value or error handling, but adequate for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds value by clarifying the mutual exclusivity of preset_name and preset_index, and by referencing a sibling tool for discovering valid values. Schema coverage is 100%, but the description enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('switch'), resource ('FX'), and target ('to a preset by name or by index'). It clearly distinguishes from sibling tools that set parameters or enable/disable FX.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a prerequisite ('Use reaper_list_fx_presets to discover valid values'), but does not explicitly state when to use this tool versus alternatives like reaper_set_fx_param or reaper_set_fx_enabled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable or disable looped playback (repeat over the time selection).
| Name | Required | Description | Default |
|---|---|---|---|
| enabled | Yes | True to enable looped playback, False to disable |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false. The description adds that looped playback is over the time selection, clarifying the scope. No contradictions; it provides useful behavioral context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and context. Every word earns its place; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple boolean toggle with complete schema and clear annotations, the description covers all necessary context. No output schema needed; the tool's effect is fully disclosed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single boolean parameter is fully described. The description does not add extra semantic meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Enable or disable' and the target resource 'looped playback', and specifies the context 'repeat over the time selection'. It effectively distinguishes this from siblings like reaper_transport_play or reaper_set_time_selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when toggling looped playback) but provides no guidance on when not to use or alternatives. Given the tool's simplicity, this is adequate but not excellent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the master track's volume fader in dB.
| Name | Required | Description | Default |
|---|---|---|---|
| db | Yes | Master volume in dB. 0 = unity |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds no additional behavioral context beyond setting volume in dB.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and resource, no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description is complete and sufficient. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already includes the parameter description with range and default (0=unity). The description adds no new semantic information beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Set' and the resource 'master track's volume fader', which distinguishes it from sibling 'reaper_set_track_volume_db' that sets a different track's volume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives, but the naming makes it obvious that this is for the master track specifically. Implied usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the level of a track send in dB.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based index of the source track | |
| send_index | Yes | 0-based send index from reaper_list_sends | |
| db | Yes | Send level in dB. 0 = unity |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false, so the description's minimal statement is acceptable. However, it does not add context beyond what annotations provide, such as immediate effect or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 9 words, front-loaded with the verb and key object. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with 3 required parameters, idempotent and non-destructive annotations, and no output schema, the description is nearly complete. It could mention that send_index should come from reaper_list_sends, but that is covered in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all three parameters. The description adds no additional meaning beyond the schema; baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set the level of a track send in dB' clearly states the action (set), resource (track send level), and unit (dB). It distinguishes from sibling tools like reaper_set_track_volume_db (track volume) and reaper_remove_send (different action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when to use reaper_add_send first or how to obtain send_index via reaper_list_sends. No when-not-to-use or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the project tempo in BPM. Returns the resulting tempo.
| Name | Required | Description | Default |
|---|---|---|---|
| bpm | Yes | Project tempo in beats per minute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true, and the description adds 'Returns the resulting tempo', which provides useful information beyond annotations. However, it does not discuss side effects, permissions, or other behavioral aspects. Given the annotation coverage, the description adds modest value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 9 words, with no redundancy or extraneous information. It efficiently conveys the core purpose and return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single parameter, no output schema, annotations present), the description covers the essential behavior: setting tempo and returning it. It could mention that the valid range is from >0 to 960, but the schema already defines constraints. Overall, it is sufficiently complete for a straightforward setter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is already well-documented in the schema as 'Project tempo in beats per minute'. The description repeats 'in BPM' but adds no new meaning beyond what the schema provides. A baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Set the project tempo in BPM', which is a specific verb+resource combination. It clearly distinguishes itself from sibling tools that deal with markers, FX, tracks, etc., as no other tool sets tempo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or when not to use it. It simply states what it does without any context about prerequisites, exclusions, or alternative approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the project time selection (the loop/render range) to [start, end] seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| start_sec | Yes | Selection start in seconds | |
| end_sec | Yes | Selection end in seconds (must be >= start) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds that it sets the loop/render range in seconds, confirming it is a write operation without destructive effects. This is consistent and adds modest value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately conveys the action and resource. It is front-loaded and contains no filler, making it efficient for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two required number parameters and no output schema, the description fully covers the essential purpose and behavior. No additional details are necessary for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for start_sec and end_sec. The description only restates the range format, adding no new semantic meaning. Baseline score of 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (set) and the resource (project time selection, the loop/render range) with a clear format '[start, end] seconds'. It is specific and distinguishable from sibling tools like 'clear_time_selection' by naming the range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'clear_time_selection' or 'set_loop_enabled'. The description does not mention prerequisites or use cases, relying entirely on the tool name for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a track's automation mode (trim/read/touch/write/latch/latch_preview).
Set to 'read' for written envelopes to play back.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| mode | Yes | Automation mode to apply |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and non-destructive behavior. The description adds that setting 'read' enables playback of envelopes, but does not disclose other side effects, error conditions, or behavior for other modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and lists options, second gives a key functional hint. No redundant words, front-loaded, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple state-setting tool with two parameters and no output schema, the description covers the essential purpose and the most important behavioral nuance (read mode for playback). Only missing explanations for other modes, but enum names are self-explanatory to domain users.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description lists the enum values from the schema but does not add new semantic information (e.g., meaning of each mode) beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets a track's automation mode and lists all valid modes (trim/read/touch/write/latch/latch_preview). The verb 'set' combined with a specific resource differentiates it from sibling tools that affect other track properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides one usage hint: set to 'read' for written envelopes to play back. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., other track settings tools) and does not mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mute or unmute a track. Returns the updated track state.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| mute | Yes | True to mute, False to unmute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false. The description adds that it returns updated track state, which is useful but not critical. No further behavioral traits disclosed (e.g., undo impact, required track existence).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no wasted words. Front-loaded with the core action and return value. Perfectly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple two-parameter tool with strong annotations. However, lacks usage guidance and behavioral depth, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and clearly describes both parameters. The description adds no new meaning beyond the schema, meeting the baseline for well-documented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Mute or unmute' and resource 'track', clearly distinguishing it from sibling tools like reaper_set_track_solo or reaper_set_track_volume_db.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention context or constraints, leaving the agent to infer from naming alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a track's pan. Returns the updated track state.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| pan | Yes | -1.0 = hard left, 0 = center, +1.0 = hard right |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write operation and idempotency. Description adds return value info ('Returns the updated track state'), which is beneficial. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no waste. First sentence states action, second states return. Efficiently packaged.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple setter tool. Missing details about error behavior on invalid index, pan law implications, or effect on automation. Could be more thorough but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters (0-based index, pan range -1 to 1). Description does not add additional context beyond schema, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Set a track's pan' with verb and specific resource. Distinguishes from sibling setter tools like reaper_set_track_volume_db or reaper_set_track_mute by specifying 'pan'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Implicitly when pan adjustment is needed, but lacks differentiation or when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Arm or disarm a track for recording. Returns the updated track state.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| armed | Yes | True to arm, False to disarm |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare idempotentHint=true and destructiveHint=false, covering safety aspects. The description adds that it returns the updated track state. However, it does not disclose potential side effects on recording behavior or audio engine, but with annotations, the bar is lower. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that covers purpose and return value with no wasted words. It is appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two required parameters, no output schema), the description is mostly complete. It lacks details about error conditions or behavior when track index is invalid, but with idempotentHint and openWorldHint, this is a minor gap. Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (track_index and armed) with clear descriptions. The description does not add any extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Arm or disarm' and the resource 'a track for recording', and mentions returning the updated state. This distinguishes it from sibling tools like reaper_set_track_mute or reaper_set_track_solo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not specify prerequisites, related actions like recording transport, or when not to use it. Given sibling tools like reaper_set_track_record_input, usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a track's record input (audio channel or encoded MIDI input).
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| input | Yes | Record input. 0 = audio input 1. Encode MIDI as 4096 + (channel * 32) + device. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and non-destructive behavior. The description adds that the input parameter has a special MIDI encoding formula, which provides additional context beyond annotations. However, it does not describe other behaviors like what happens if the track index is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action without any extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required params, no output schema) and annotations providing safety context, the description is fairly complete. It covers the key encoding detail but could mention that track_index must correspond to an existing track and that the function has no return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have schema descriptions, but the description adds crucial meaning to the 'input' parameter by explaining how to encode MIDI input (4096 + channel*32 + device). This goes beyond the schema's generic description and is actionable for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a track's record input, specifying it can be audio channel or encoded MIDI. This is a specific verb and resource, and it distinguishes from sibling tools like reaper_set_track_record_arm which arms the track.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for configuring track input routing, but does not explicitly state when to use this tool versus alternatives (e.g., for arming, volume, pan). There is no mention of prerequisites or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solo or un-solo a track. Returns the updated track state.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| solo | Yes | True to solo, False to un-solo |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds that it returns the updated track state, which is useful context. However, it does not disclose potential side effects like affecting playback or interaction with other track states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences convey the action and return value with no unnecessary words. Every sentence earns its place, and the description is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no output schema), the description adequately covers the action and return. However, it could explicitly state that the return is the full track state object, not just the solo flag, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; each parameter is already well described in the input schema ('0-based track index', 'True to solo, False to un-solo'). The tool description adds no further semantic information, meeting the baseline but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Solo or un-solo a track. Returns the updated track state.' It uses a specific verb (set) and resource (track solo), distinguishing it from sibling tools like 'reaper_set_track_mute' or 'reaper_set_track_volume_db'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, when soloing is appropriate, or any exclusion criteria. The sibling list shows many similar track-modifying tools, but no comparative context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a track's volume fader in dB. Returns the updated track state.
| Name | Required | Description | Default |
|---|---|---|---|
| track_index | Yes | 0-based track index | |
| db | Yes | Volume in dB. 0 = unity; pass -150 (or lower) for -inf/silence |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false. The description adds that it returns the updated track state, which is useful. No contradictions or missing critical traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core purpose. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with 2 params, the description is sufficient. Mentions return value. Could note undo behavior, but not essential given annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description does not add extra parameter meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets a track's volume fader in dB and returns the updated state. It distinguishes from siblings like reaper_set_master_volume_db and reaper_set_send_volume_db through resource specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives. The name and sibling list imply the context, but the description lacks explicit when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause the transport, keeping the cursor where it is.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the key behavioral detail that the cursor remains in place, which is not conveyed by annotations (idempotentHint, openWorldHint). This is valuable context beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is immediately clear. No extraneous words; every part is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and simple behavior, the description fully covers what the agent needs to know. It is complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description does not need to add parameter information, so it earns a high baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it pauses the transport and keeps the cursor position. The verb 'pause' combined with 'transport' makes the action specific. It distinguishes itself from sibling tools like 'reaper_transport_play', 'reaper_transport_record', and 'reaper_transport_stop'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use pause (to stop without moving cursor), but does not explicitly state when not to use it or compare with alternatives like stop. More guidance would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start playback from the edit cursor.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the annotations. Annotations indicate idempotentHint=true and readOnlyHint=false, but the description doesn't clarify what happens if already playing, if the edit cursor is invalid, or any side effects. It merely states the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and efficient for a simple action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and performs a straightforward action, the description is complete. No additional context is necessary for an AI agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. With zero parameters, the description cannot add parameter-specific meaning. The baseline score of 4 is appropriate as the description is not deficient in this area.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Start playback from the edit cursor' clearly states the action (start), the resource (playback), and the location (edit cursor). This distinguishes it from sibling transport tools like reaper_transport_pause, reaper_transport_record, and reaper_transport_stop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., reaper_transport_record or reaper_transport_stop), nor does it mention prerequisites or typical use cases. It only states the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start recording on all armed tracks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it modifies state (readOnlyHint false) and is not destructive, but the description does not disclose behavior when already recording, error conditions, or side effects. With annotations, the description adds minimal extra context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, non-redundant sentence that conveys the exact action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple start command, the description is adequate but lacks information on what the tool returns or what happens under different conditions (e.g., already recording, no armed tracks). With no output schema, more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, schema coverage is 100%. The description does not need to add param info, and baseline is 4. No additional value needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'start recording' on a defined resource 'all armed tracks'. It clearly distinguishes this from sibling transport tools like play, stop, and pause.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., if already recording, or if no tracks are armed). No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the transport.
If Reaper is recording, the call is refused unless force=true — this
avoids ending a take without the user's go-ahead. Ask the user first, then
retry with force=true.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Stop even if Reaper is currently recording. Defaults to false: if a recording is in progress the call is refused so an in-progress take isn't ended unintentionally. Always confirm with the user before passing true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that call is refused during recording unless force=true, which is critical behavioral info beyond annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose and clear guidance; no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and rich annotations, the description fully covers behavior, usage, and parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes the force parameter well; description adds value by tying it to the recording refusal scenario and user confirmation requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stops transport and distinguishes behavior when recording, differentiating from sibling transport tools like reaper_transport_play and reaper_transport_pause.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use (stop transport) and when not (recording without force), and provides a workflow: ask user first, then retry with force=true.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0reaper_add_envelope_pointreaper_add_fx_to_trackreaper_add_markerreaper_add_midi_notereaper_add_regionreaper_add_sendreaper_analyze_mixreaper_analyze_projectreaper_clear_envelopereaper_clear_time_selectionreaper_create_trackreaper_delete_itemreaper_delete_markerreaper_delete_trackreaper_get_master_trackreaper_get_project_inforeaper_get_track_statereaper_goto_markerreaper_insert_midi_itemreaper_list_fx_paramsreaper_list_fx_presetsreaper_list_installed_fxreaper_list_itemsreaper_list_markersreaper_list_sendsreaper_list_track_fxreaper_list_tracksreaper_pingreaper_remove_fxreaper_remove_sendreaper_rename_trackreaper_render_projectreaper_run_actionreaper_set_cursorreaper_set_fx_enabledreaper_set_fx_paramreaper_set_fx_presetreaper_set_loop_enabledreaper_set_master_volume_dbreaper_set_send_volume_dbreaper_set_temporeaper_set_time_selectionreaper_set_track_automation_modereaper_set_track_mutereaper_set_track_panreaper_set_track_record_armreaper_set_track_record_inputreaper_set_track_soloreaper_set_track_volume_dbreaper_transport_pausereaper_transport_playreaper_transport_recordreaper_transport_stopEach tool has a clear, distinct purpose. Even similar tools like reaper_add_marker and reaper_add_region are differentiated by region spanning a range. Descriptions provide enough detail to avoid confusion.
All tools follow the verb_noun pattern with 'reaper_' prefix. Naming is perfectly consistent across the entire set.
53 tools is high but justified for a DAW control server covering many aspects (tracks, FX, sends, automation, transport, etc.). It's slightly above the ideal range but still well-scoped without redundancy.
Covers most core DAW operations: track management, FX, sends, automation, MIDI, markers, transport, analysis, render. Minor gaps like item editing (split, move) or detailed MIDI editing are missing but not critical for basic workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Producer/Riffusion AI music generation
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/T-Rzeznik/reaper-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
