create_lfo_modulation

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

Annotations declare a non-destructive, non-idempotent, closed-world write, which covers the safety profile. The description adds real behavioral context beyond that: the note is sustained for the duration, and the filter target is only valid with saw, square, pad, or pluck synths — a cross-parameter constraint found nowhere in the schema. It does not discuss what is returned or whether overlapping calls layer.

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 sentences, no filler, with the core action front-loaded and the depth semantics following as supporting detail. Every clause carries information an agent needs to set target_param and depth correctly.

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 no explanation, and the description covers the two genuinely ambiguous inputs (depth and target_param interaction) plus the synth constraint. Minor gaps remain around rate behavior and how repeated calls interact, but nothing essential to a correct call is 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?

With 67% schema coverage and three undescribed enums, the description compensates well by defining what depth actually means per target (one octave, full fade, 200 Hz–8 kHz, hard L/R) — information the schema's generic 'Modulation depth' does not convey. It also flags the synth/target dependency, though it leaves rate and waveform behavior uninterpreted.

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 concrete verb and resource: holding a note while an LFO sweeps pitch, volume, filter, or stereo position. The four target dimensions map directly to the target_param enum, so an agent can tell this apart from plain play_synth or create_layered_synth. It stops short of naming those siblings explicitly, which keeps it out of 5 territory.

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 phrase 'hold a note while...' implies the use case (sustained, evolving, modulated sound) but never says when to prefer this over play_synth or create_ambient_soundscape, nor any when-not condition. Usage is inferable but not stated.

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