Skip to main content
Glama
Sign In
reaper-mcp

reaper-mcp

by yiw190
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

status

Check the Lua bridge to report project tempo, play state, cursor position, tracks, time selection, and mute/solo status. Call first before rendering to clear lingering solos.

Instructions

Check the Lua bridge and return project tempo, play state, cursor_beats, tracks (selected=true on selected ones), time_selection {start_beats, end_beats} when there is one, selected_items [{track_index, item_index}], any_solo, master_mute and dirty (unsaved changes). Call first; clear a lingering solo before rendering. detail=true adds arrangement facts (time signature at the start, tempo_map of tempo/meter changes, length in beats, markers, MIDI vs audio per track) without guessing chords.

Tool call template

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

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

Input Schema

NameRequiredDescriptionDefault
detailNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.0
    • addedInput schema / properties / detail
      Added value: +{
+  "type": "boolean"
+}
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses the returned fields and the extra detail mode, but it does not explicitly say this is read-only, whether the call has side effects, what happens if the Lua bridge is unavailable, or whether detail=true has performance costs.

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

Conciseness4/5

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

The description is dense but front-loaded, starting with the core action and then adding operational guidance and detail-mode behavior. The long list of returned fields is useful, though the single packed sentence makes it slightly harder to scan.

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

Completeness4/5

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

There is no output schema and no annotations, so the description needs to explain what the tool returns, and it does list the key fields and the expanded detail fields. It is reasonably complete for a status tool, though it omits error behavior and the default for detail.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must explain the single optional parameter, and it does: detail=true adds arrangement facts and lists what those facts include. It could be slightly stronger by stating the default value explicitly, but the meaning is clear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it checks the Lua bridge and returns a concrete set of project, transport, selection, and dirty-state fields. It is clearly not a tautology, but it does not explicitly differentiate itself from sibling tools such as transport or project, so it falls just short of the top score.

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

Usage Guidelines4/5

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

It gives clear usage context with 'Call first' and a specific operational caveat about clearing a lingering solo before rendering. It does not name alternatives or state when not to use this tool, so it is strong but not exhaustive.

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

Deploy Server

Other Tools