Process audio files

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false). The description usefully clarifies that 'Inputs are only read', which softens the readOnlyHint=false flag by telling the agent the source files are untouched. It stops short of explaining overwrite behavior, re-run/idempotency semantics, or failure handling for the many-file case.

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 core action is front-loaded, which is good, but the tool's identity is delivered as one very long sentence with two dense parenthetical catalogues of effects and formats. The plugin enumerations duplicate content already in the schema's plugin field, and breaking the pipeline into ordered steps would be far more scannable.

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 25-parameter tool with no output schema and 56% coverage, the description should do more. It conveys the overall pipeline shape but omits how outputs are named/located (suffix, output_dir vs output_path vs output_path), what happens with multiple inputs and multiple formats, and the default preview behavior, all of which an agent needs to call it correctly.

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 56% across 25 parameters, so the schema carries much but not all of the load. The description's capability list (trim, normalize, gain, reverse, invert, pitch shift, time stretch, varispeed, effects) maps loosely onto parameter names but adds no units, defaults, or interaction rules, so it only partially compensates for the undocumented half.

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 (run files through SoundCraft) and enumerates the concrete capability set: trim, AudioSuite processing, insert effects, fades, volume/pan, and encoding to WAV/AIFF/FLAC. It reads as a full processing pipeline rather than a tautology. However it never names or contrasts with the nearest siblings (convert_audio, run_soundcraft_commands, edit_session), so an agent must infer the boundary itself.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named despite clear overlap with convert_audio and run_soundcraft_commands. The only routing hint is the implicit 'processor, not editor' framing, which the agent has to derive from the capability list.

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