audio_split_stems

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

Annotations already mark it as non-read-only, non-idempotent, closed-world, and non-destructive, but the description adds important behavior beyond them: the model downloads on first use, the call returns a job rather than finished files directly, and the job result contains four file paths. The file-access requirement is also disclosed.

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 sentences with no wasted wording. The core operation is front-loaded, followed by the return/job behavior and prerequisite 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 tool with no output schema, the description explains the return shape (a job whose result has four file paths) and the downstream audio.import step. It is nearly complete, though it could name jobs_get or jobs_wait for the job-polling workflow.

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 100%, so both parameters ('path' and 'folder') are already fully described in the input schema. The description reinforces that the input is a WAV mix and the folder is for stems, but adds no new syntax, constraints, or edge-case guidance.

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: 'Split a WAV mix into vocals, drums, bass and other with Demucs'. It also names the downstream consumer ('audio.import can load'), which helps distinguish it from siblings like audio_import and export_stems.

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?

Gives clear operational context and a prerequisite ('Needs file access (Settings, AI Create)'), and indicates that the resulting stems can be loaded with audio.import. It does not explicitly state when not to use it or compare it to export_stems, so it stops short of full routing guidance.

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