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 the output ('one WAV path per candidate'), which is valuable given there is no output schema, and the mode semantics make clear the input is not destructively modified in place. But it omits side effects (files written to disk, metadata), model-loading cost/latency, and any constraints on the input clip's format or length.

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?

Three tight sentences, front-loaded with purpose and mode enumeration followed by the return contract, then a clearly-labeled tip. Nothing is redundant with the schema. The tip is slightly tangential to selection but earns its place as non-obvious expert guidance.

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 an 18-parameter tool with no output schema and no annotations, the description covers purpose, modes, and return shape, which is the essential core. It still leaves an agent without guidance on typical failure conditions, input-length limits, or the runtime cost of generating up to 4 candidates, so a caller could invoke it correctly but not confidently plan around it.

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 83%, so most parameters (mode, strength, overlap_seconds, duration_seconds, start/end_seconds, seed, title, prompt) are already documented in the schema, establishing a baseline of 3. The description adds no parameter-level detail beyond the tip's indirect hint that the inpaint region is adjustable; the genuinely undocumented params (bpm, cfg, steps, peak_ceiling_db, original_idea) are not covered here either.

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 ('Edit existing audio') and enumerates the three concrete modes (variation, inpaint, continue), which map directly to the mode enum. It also discloses the return shape ('one WAV path per candidate'). It stops short of naming generate_audio/process_audio as the alternatives, so differentiation is implied by 'existing audio' rather than stated.

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 three modes are named and each is briefly characterized, and the 'Official tip' gives real craft guidance (inpaint a large region then shrink it, keep prompts plausible). However there is no explicit when-to-use-this-versus-alternatives guidance: nothing says when to reach for edit_audio instead of generate_audio or process_audio, nor any prerequisites for the input file.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose two useful facts beyond the schema: the model runs locally and each candidate yields one WAV path. It omits meaningful traits an agent should anticipate — generation latency/cost, model loading behavior, whether files persist, and failure modes — so coverage is partial rather than thorough.

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, front-loaded with the core capability, then the return value. No filler, no restating the tool name, and every clause adds 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?

For a 16-parameter generative tool with no output schema, the description covers purpose and the return shape, and the schema documents all parameters. What is missing is operational context — expected duration/cost of a local generation run and how it relates to unload_models for memory management — which would matter for an agent planning multi-call workflows.

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 100%, so every one of the 16 parameters is already documented in the schema, including defaults per audio_type and the cfg/negative_prompt interaction. The description adds no syntax or format detail beyond what the schema already provides, so the baseline 3 applies.

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 ('Generate') plus the exact resource classes it produces (BGM, instrument loops/stems, sound effects) and the engine (Stable Audio 3), which cleanly separates it from the sibling edit_audio/process_audio tools that transform existing audio. The second sentence names the output shape (one WAV path per candidate), so an agent knows exactly what comes back.

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 only implied: the verb 'Generate ... from text' suggests this is for creating new audio rather than editing, but the description never says when to pick it over edit_audio or process_audio, nor does it state prerequisites such as model load time (a real concern given the unload_models sibling). The audio_type enum values in the schema effectively route the agent, but that is structured data, not description guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses key non-obvious behavior: the input is not modified, steps execute in a fixed order, no model is loaded, and a .json sidecar is emitted alongside the exported audio. It still does not describe error/overwrite behavior or return values, but the central behavioral traits are covered.

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?

Three tightly packed sentences with the main operation and constraints front-loaded. It avoids repetition and every sentence contributes needed context.

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 17-parameter tool with high schema coverage, it explains the overall pipeline, non-destructive behavior, output formats, and sidecar. The main remaining omission is that, with no output schema, it does not state the return value or exact output location/overwrite semantics.

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 coverage is 82%, so most parameters are already documented in structured form. The description adds useful sequencing context ('Steps run in that order') and summarizes normalize/export choices, but it does not add much per-parameter meaning beyond the schema.

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 ('post-process and export') and resource ('a clip'), and enumerates the transformations and output formats. It distinguishes itself from generation by saying it does not load a model and leaves the input unmodified, though it never names edit_audio or explicitly contrasts with it.

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 description implies use when a clip needs post-processing/export and lists supported operations, but it gives no explicit when-to-use/when-not guidance or named alternatives such as edit_audio versus process_audio. It only weakly signals that this is the final processing/export step.

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

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

No annotations are provided, so the description carries the full load; it does disclose a genuine behavioral trait — models are unloaded and must be reloaded on the next call, which signals latency cost. It does not say whether this interrupts in-flight work, what happens if nothing is loaded, or what the call returns.

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?

One sentence, action front-loaded, with the reload consequence in a parenthetical that earns its space by warning about the cost of calling it. 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?

For a zero-parameter, no-output-schema utility tool, the description covers what it does and the main side effect (reload on next call). Minor gaps remain around whether in-flight generation is affected and what the response contains.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly avoids inventing options that the empty schema does not support.

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 combination ('free the memory held by the loaded models') that an agent can map directly to a resource-management action. It reads as unambiguously distinct from the audio-processing siblings, though it never names them explicitly.

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 word 'now' and the parenthetical about reloading imply this is a memory-pressure action taken between calls, but there is no explicit when-to-use guidance, no exclusion (e.g., mid-generation), and no mention of alternatives.

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