Sound Make

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

With no annotations, the description carries the full burden. It does disclose meaningful behavior: a persistent artifact is written into the bank, notes follow the notes_write format at project tempo, and a timbre description is returned. It omits mutation semantics that matter here, such as what happens on a name collision, whether an existing sound is overwritten, and the cost/time of rendering.

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?

Two tight sentences, front-loaded with the action and its inputs, with the parenthetical format note earning its place. Slightly dense packaging but no 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?

An output schema exists so return values need not be described, and the core generative flow is conveyed. However, for an unannotated 8-parameter mutation tool with 0% schema coverage, the definition leaves too much open: overwrite behavior, parameter meanings, and rendering characteristics are all missing.

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% across 8 parameters, so the description must compensate. It explains the non-obvious `notes` format ('notes_write format, beats at project tempo') and names `instrument` and `fx`, but `project`, `name`, `describe`, `tail_sec`, and `normalize` receive no explanation at all, leaving most of the surface undocumented.

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?

Specific verb+resource ('Synthesize a sound into the bank') with the exact inputs named (notes on instrument through fx). The generative framing clearly separates it from siblings like sound_import (bring in external audio) or sound_extract (pull audio out), so an agent can route without opening the schema.

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 names downstream uses of the result (sampler source, wavetable, vocoder modulator, audio clip), which implies context but is about the output artifact rather than when to pick this tool over alternatives. There is no explicit when-to-use or when-not-to-use guidance, and no sibling is named.

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