REAPER MCP Server

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

No annotations provided, so description carries full burden. It explains the creation and routing action but omits safety-critical details: whether the operation is idempotent, what happens if track_indices reference non-existent tracks, or whether existing sends are overwritten.

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 brief (two sentences) with no fluff. The second sentence awkwardly serves double-duty as description and parameter documentation, which is efficient but slightly reduces readability. Information is front-loaded with the core 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?

Adequate for a two-parameter tool with no output schema, covering the core concept (bus routing) and primary parameter. Missing: error conditions, format examples for track_indices, and confirmation of whether the bus becomes the parent or destination of the sends.

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?

With 0% schema description coverage, the description partially compensates by documenting track_indices ('list of track indices to feed into the bus'), explaining the semantic relationship to the bus. However, it fails to document the 'name' parameter or clarify the data type expected for track_indices items.

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 specific action (create bus track) and mechanism (route via sends), distinguishing it from sibling tools like create_track (no routing implied) and create_send (no bus creation implied). However, it doesn't explicitly clarify when to prefer this over creating a track and send separately.

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?

Describes the mechanical operation but provides no guidance on when to use this tool versus alternatives like create_send, nor mentions prerequisites such as whether source tracks must exist beforehand or if name conflicts are handled.

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