mcp_opendaw_create_drum_solo

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

With no annotations, the description carries the full transparency burden. It discloses the tool generates a structured solo with 'phrasing, build-ups, climax' and genre-specific patterns, and notes return values. However, it does not clarify whether the solo is inserted, appended, or overwrites existing notes, nor does it mention side effects on the current project state or which track/unit is targeted.

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 long but well-structured: a concise lead, an explicit contrast with create_drum_fill, a detailed genre breakdown with clear formatting, and concrete usage examples. The genre details are contextually valuable and not redundant. It could be slightly tightened, but the length is justified by the tool's genre-dependent complexity.

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 core concept, genre vocabulary, key parameters, and return value, with examples. However, the omission of three placement-related parameters (start_beat, unit_index, track_index) and the lack of detail about insertion behavior mean it is not fully complete for a 7-parameter tool with no annotations. The presence of an output schema mitigates the return-value gap, but side effects remain undisclosed.

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. It adds valuable semantic detail for solo_type (lists all five genres with style descriptions), bars (range 2-16), velocity (range 0-1 with loudness note), and seed (PRNG reproducibility). However, it completely omits start_beat, unit_index, and track_index, which are likely essential for placement in the DAW project.

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 opens with a specific verb+resource: 'Create a genre-specific drum solo with rudimental vocabulary.' It explicitly contrasts itself with create_drum_fill ('short transition') and clearly states it creates a full multi-bar solo. This unambiguously differentiates the tool from similar siblings.

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 names an alternative: 'Unlike create_drum_fill (short transition), this tool creates a full multi-bar solo.' This provides clear when-to-use guidance. However, other solo-related siblings like create_solo and create_soli are not addressed, so it is not a comprehensive exclusion list.

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