mcp_opendaw_create_four_on_floor

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

The description discloses the rhythmic details, velocity offsets, and the return value ('Returns notes created, floor type, and stroke breakdown'), providing some behavioral insight. However, it doesn't mention side effects like overwriting existing notes, whether it creates a new region, or how track_index/unit_index affect the project, which is uncertain given no annotations.

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 verbose, including a lengthy historical narrative on dance music that is not essential for tool invocation. While it's organized with clear sections for floor types and parameters, the extra context makes it less concise than necessary, though still readable.

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 tool has 11 parameters and no schema descriptions, so the description bears the full burden of explanation. It thoroughly covers the main pattern generation and pitch defaults, but omits three parameters and doesn't discuss side-effect behavior or track prerequisites, leaving gaps for a complete understanding.

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?

The description adds substantial meaning beyond the schema, especially for floor_type with detailed subgenre patterns, and for pitches and velocity with specific MIDI numbers and offset values. However, start_beat, unit_index, and track_index are not described in the text despite having zero schema descriptions, leaving these parameters underdocumented.

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 clearly states the tool creates a four-on-the-floor pattern and elaborates on specific floor_type options, making its purpose explicit and unique to this genre. However, it doesn't directly differentiate itself from sibling pattern-generation tools like create_drum_pattern, so it lacks explicit sibling differentiation.

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 examples of how to call the function and explains different floor_type choices, but it does not state when to use this tool versus alternatives such as create_drum_fill or create_euclidean_rhythm. The historical context is interesting but not actionable decision guidance.

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