REAPER MCP Server

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It explains the algorithmic approach (measure-then-adjust) but omits critical operational details: whether changes are destructive, how it interacts with existing master volume automation, reversibility, or side effects on project state.

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 tightly structured with two high-value sentences. The first front-loads the core action, while the second provides immediately useful reference values without verbosity. 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 single-parameter audio processing tool without output schema, the description adequately covers the primary function. However, given that this is a project-modifying operation (master volume adjustment), it lacks necessary safety context regarding persistence, undo behavior, and interaction with existing project settings that would be expected when annotations are absent.

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?

Despite 0% schema description coverage for the `target_lufs` parameter, the description effectively compensates by defining the semantic meaning (target LUFS level) and providing concrete valid examples (-14, -16, -23). It could improve by mentioning valid ranges or that LUFS is a loudness unit, but the examples provide substantial practical context.

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 the two-step process (measure integrated loudness, then adjust master volume) and specifies the target metric (LUFS level). It clearly distinguishes from sibling tools like `analyze_loudness` (measure-only) and `set_master_volume` (adjust-only) by describing the combined normalization workflow.

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 valuable implicit guidance through concrete target examples (-14 for streaming, -16 for podcasts, -23 for broadcast), hinting at appropriate contexts. However, it lacks explicit when-to-use/when-not-to-use guidance regarding alternatives like manual volume adjustment or `apply_mastering_chain`.

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