mcp_opendaw_create_second_line

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

With no annotations, the description carries the full burden. It describes the instrument behaviors and style variations in detail (e.g., 'BASS DRUM — Deep boom. Plays the street beat'), which is valuable. However, it does not disclose operational side effects such as whether existing notes are overwritten, whether a target track must pre-exist, or how the tool mutates project state beyond 'Create'.

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 the purpose, followed by well-organized sections for instruments, styles, args, and return value. Though it includes a historical paragraph that may be extraneous for tool invocation, the structure is clear and every section serves a purpose.

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 an 11-parameter tool with 5 style options and an output schema, the description covers all parameters with constraints, enumerates styles with musical detail, and mentions the return value. It lacks explicit operational prerequisites or side-effect warnings, but given the available output schema and complexity, it is largely complete.

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 coverage is 0%, so the description must compensate. It adds constraints and examples: bars ('4-16, even'), velocity ('0-1'), pitches ('36 = C1'), and style values are enumerated with character descriptions. However, unit_index and track_index are only minimally described as 'AU index' and 'Note track index', which is terse but understandable.

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 New Orleans second line percussion ensemble — street parade groove.' This clearly states the tool's function and distinguishes it from sibling tools like create_drum_pattern or create_clave, which are generic or for other genres.

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 clearly implies usage context: 'Create a New Orleans second line percussion ensemble' tells the agent when to invoke it. However, it does not explicitly exclude alternatives or mention when not to use it, such as preferring a different genre tool, so it falls short of providing explicit guidance.

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