music_generate_bass

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

With no annotations, the description carries the burden and does well: it states the default is non-mutating, that apply creates one clip plus its notes in a single undo step, and that without apply it does not touch Live. It omits permission/auth requirements and any pagination-style concerns, so it is strong 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?

Front-loads purpose, then side effects, example, and edge cases in clearly labeled blocks. Mostly efficient, though the example and edge-case lines are somewhat loosely worded and the example sentence is broken across lines.

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 7-param tool with no annotations and no output schema, the description covers the core behavior, side effect, and a return example. Delegating 'traits' semantics to a sibling tool and leaving clip_index/track_index undocumented are the main remaining 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?

Schema description coverage is 0%, so the description must compensate across 7 parameters. It gives meaning to bars, seed, root_midi, apply, and traits (delegated to the drum-groove tool), but clip_index and track_index are never explained, and 'weirdness' is referenced without clarifying that it is a trait key rather than a parameter.

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?

States a specific verb and resource ('Generate a deterministic root-only bass line') and clarifies the optional clip-writing mode. It does not explicitly name or distinguish itself from likely siblings like music_generate_drum_groove or groove_generate, though the 'root-only bass' qualifier is distinctive.

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?

Usage is implied rather than stated: the agent can infer the preview-vs-apply distinction from 'optionally into a clip' and the apply side-effect note. There is no explicit when-to-use or when-not-to-use guidance relative to the other generative siblings such as music_generate_drum_groove or groove_generate.

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