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

No annotations are provided, so the description carries the full burden. It discloses the pattern options (contrary, oblique, parallel_third, parallel_sixth, call_response) and default values for octave, velocity, and track_index, which gives insight into the generated output. However, it does not mention side effects such as whether existing notes on the target track are overwritten, what exactly is created (e.g., a MIDI region), or any prerequisites beyond having a progression. This is adequate but not exhaustive.

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 well-structured: a definition, context about the harmonic quintet, a bulleted list of pattern options, a parameter list, and three examples. It is longer than the minimum but every section adds value—the pattern explanations are particularly useful. It could be slightly trimmed (e.g., the example code block is long), but it remains efficient and front-loaded with the core 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 a tool with 8 parameters and moderate complexity, the description covers most key aspects: purpose, patterns, defaults, track placement, and examples. It is incomplete regarding start_beat and unit_index, and it does not specify the expected format of the progression string beyond the example 'Am-F-C-G'. Since an output schema exists, the lack of return-value documentation is acceptable. Overall, it is a thorough description with minor gaps.

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 no parameter descriptions (0% coverage), so the description must compensate. It explains pattern, bars_per_chord, octave, velocity, and track_index, including detailed sub-values for pattern. The examples also demonstrate parameter usage. However, two parameters—start_beat and unit_index—are not mentioned at all, leaving them unexplained. This is a significant but not total gap, so a 4 is appropriate.

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 'Create a counter-melody (second melodic line) from a chord progression,' which clearly names the verb and resource. It further distinguishes this tool from the related melody_from_progression by emphasizing it is the secondary line, and explicitly places it in the harmonic quintet alongside chord_pads, arpeggiated_progression, bass_from_progression, and melody_from_progression.

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 clear usage context: it should be used to add a second melodic line over an existing progression/melody, and it is the final piece of the harmonic quintet. It also advises placing it on track 4 to avoid clashing with the melody on track 3. However, it does not explicitly name alternative tools or say when not to use it, so it falls short of a 5.

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