mcp_opendaw_classify_drum_pattern

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It details what is analyzed (drum note positions, pitches with GM mapping, velocities) and the output structure (classification, confidence, features, per-bar breakdown), which gives a thorough understanding of the operation. It does not explicitly state that the tool is read-only, but the analysis-oriented language makes this implicit.

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 organized into clear sections: a one-sentence summary, analysis method, use cases, parameters, and return value. While it is fairly long, the GM drum map list adds useful domain context for a specialized tool. Each section earns its place; no superfluous filler.

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 essential aspects for using this tool correctly: what it does, what inputs to provide (including default semantics), what it returns, and when it is valuable. Given the complexities of drum pattern classification and the existence of an output schema, the description is sufficiently complete, though it could mention edge cases such as empty regions or non-GM-mapped notes.

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 input schema has zero description coverage, so the description must compensate. It does so effectively by explaining each parameter ('unit_index: AU index (-1 = all AUs)', 'track_index: Note track index (-1 = all note tracks)', 'region_index: Region index (-1 = all regions on track)'), including the meaning of defaults. This goes well beyond the bare schema definitions.

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's purpose with a specific verb ('classify') and resource ('a drum pattern from MIDI notes in a region'). It enumerates the pattern types and explains the analysis inputs, making the tool's function unambiguous. However, it does not explicitly differentiate itself from similar drum-analysis siblings like transcribe_drums or extract_rhythm.

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 explicit use cases under 'Essential for:' (understanding existing drum patterns, matching genre expectations, verifying generated patterns, suggesting variations), giving clear context for when to invoke the tool. It does not mention exclusions or alternatives, which would earn a 5, but the stated purposes are sufficiently specific.

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