mcp_opendaw_create_downtempo_arrangement

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

With no annotations, the description carries the full burden for behavioral disclosure. It transparently details the 5 tracks created and their musical patterns, plus defaults for BPM and key. However, it doesn't state whether the tool mutates the existing project, overwrites tracks, requires prior setup, or how it interacts with existing content. It also omits behavior around parameters like start_beat and unit_index, leaving gaps in the side-effect description.

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 front-loaded with a clear purpose statement, but it then spends several lines on the historical origins of trip-hop in Bristol and a genre characteristics list that, while musically informative, is not essential for invoking the tool. Overall, it is longer than necessary but well-structured with paragraphs and track enumeration.

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 presence of an output schema reduces the need to explain return values. The description provides a rich musical brief (tracks, patterns, key, BPM) and clearly summarizes the creative result. However, critical operational details are missing: parameter semantics for several parameters, explicit use cases, and non-destructive behavior. The tool is complex enough that these gaps make the description only partially complete for an agent to select and invoke it with confidence.

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 0%, so the description must compensate for parameter explanation. It explicitly mentions bpm and key_root (defaults) and uses track_index to define track numbering, but provides no explanation for bars, velocity, start_beat, or unit_index. This leaves 4 of 7 parameters entirely undocumented, which is insufficient for a tool with zero schema descriptions.

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 opening sentence, 'Create a downtempo/trip-hop arrangement — 85 BPM Bristol sound,' uses a specific verb and resource, immediately identifying the tool's function. It clearly distinguishes this from sibling genre-arrangement tools (e.g., create_afrobeat_arrangement, create_lofi_arrangement) by naming the genre and key characteristics.

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 for downtempo/trip-hop creation through detailed genre characteristics and track breakdown, but it never explicitly states when to use this tool over alternatives, nor does it offer exclusions or refer to other tools. No when-to-use guidance is provided beyond the genre itself.

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