Sound Speak

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

With no annotations, the description carries the full burden. It does add real behavioral detail: platform-specific engines, voice examples, default fallback when a voice is missing, and the rate range. It omits what happens on name collisions with existing sounds, permissions, and whether the operation is reversible, so gaps remain for a mutating tool.

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?

Dense but well-packed: engine detail, fallback behavior, rate range, and downstream uses are all present in a single tight block with no filler. It leans slightly toward over-packing, but every clause carries information.

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 explained, and engine behavior is covered. For a mutation that creates named sounds, though, the description says nothing about overwrite/collision behavior or the normalize parameter, leaving meaningful gaps given the absence of annotations.

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 clarifies voice (examples, default fallback) and rate (-10..10), but leaves normalize, name, and project unexplained, so it only partially closes the coverage gap rather than fully compensating.

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+resource ('Text-to-speech into the sound bank') and the mechanism (OS engine with named voices per platform), which clearly separates it from import/synthesis siblings. It does not explicitly name an alternative tool, but the mechanism description is distinctive enough to route correctly.

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 'Use as a vocoder modulator..., a sampler source, or an audio clip' sentence tells the agent how the generated sound is consumed downstream, which is useful context. However, it never advises when to choose this tool over alternatives (e.g., sound_make, sound_import) or any prerequisites, leaving tool selection to inference.

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