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

With no annotations, the description carries the full burden. It richly describes pattern behaviors (root, walking, pedal, etc.), default values, velocity range, octave mapping, and track index. However, it does not explicitly state side effects like whether it overwrites existing notes on the target track or if it appends to a region. Minor gap, but the level of detail is strong.

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 with a clear intro, a pattern list, parameter notes, and multiple examples. It is long but each element adds value. The examples are slightly redundant but effectively demonstrate pattern usage. 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?

Given the tool's complexity (8 params, no annotations), the description covers the main purpose, pattern options, parameter semantics, and integration with two sibling tools. It omits start_beat and unit_index, and doesn't state side effects, but output schema exists so return values need not be explained. The examples further round out the picture.

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 thoroughly explains pattern (with enum-like descriptions), bars_per_chord, octave, velocity, and track_index, and examples clarify the progression parameter. However, start_beat and unit_index are completely undocumented, leaving two of eight parameters unexplained.

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 clear verb+resource: 'Create a bass line from a chord progression string.' It also names its role within the harmonic trio (chord pads, arpeggiated progression, bass foundation), which distinguishes it from sibling tools. This is specific and actionable.

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?

It provides context that this tool is the bass foundation alongside create_chord_pads and create_arpeggiated_progression, and that all three take the same chord string. Genre examples for each pattern give implicit guidance. However, it does not explicitly exclude or compare against other bass-related tools like create_bassline or create_walking_bass, so it stops short of full when/when-not guidance.

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