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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does explain that a new version is generated and mentions the return value (Task ID and cover audio info), which is helpful. However, it does not clarify asynchronous behavior, whether the original audio is left unmodified, or any callback semantics, leaving some behavioral ambiguity.

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 description is well-structured with a clear opening statement, a focused 'Use this when' list, and a brief returns note. It is slightly redundant in explaining what the generated version changes, but overall every section earns its place and the content is easy to scan.

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?

The tool has a rich schema with 100% parameter coverage, and the description covers core use cases and expected outputs. It is complete enough for an agent to understand what the tool does and when to invoke it. It could be stronger by clarifying async/callback behavior and differentiating from the variation sibling, but those are not critical gaps.

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 the parameters are already thoroughly documented. The description adds general context about cover/remix use cases and prompt examples, but it does not add substantial parameter-specific meaning beyond what the schema already provides.

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?

The description clearly states it creates a cover or remix version of an existing song in a different style, and emphasizes that the core melody and lyrics are retained. It is specific about the verb, resource, and output. However, it does not explicitly contrast itself with the similar-sounding sibling producer_variation_music, leaving some potential overlap unresolved.

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 this when' section provides concrete scenarios such as hearing a song in a different genre or creating an acoustic version of an electronic song. This gives clear usage context, but it does not state when not to use this tool or point to an alternative sibling like producer_variation_music.

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 behavioral disclosure burden. It does state that the tool returns a Task ID and extended audio information, which is useful, and it clarifies that the extension continues from a timestamp. However, it does not describe asynchronous behavior implications, whether the original audio is preserved, or what happens if no lyric/prompt is provided.

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 description is well-organized with a clear first sentence, a brief elaboration, bulleted use cases, and a returns line. It is concise and front-loaded, though the second paragraph somewhat repeats the first sentence's idea of continuing a previously generated song.

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?

Given the tool has 7 parameters, an output schema, and sibling tools like producer_replace_section, the description covers the core selection criteria and expected result well. It could be more complete by mentioning async/callback behavior or explicitly contrasting with replace_section, but the combination of description and rich schema is sufficient for an agent to invoke 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 100%, so the schema already documents all parameters including continue_at, audio_id, lyric, prompt, and async. The description adds contextual framing around 'timestamp' and 'new content' but does not materially clarify parameter semantics beyond the existing schema descriptions.

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?

The description uses a specific verb ('Extend') and resource ('an existing song from a specific timestamp'), clearly distinguishing this from generation, cover, variation, and replacement tools. It also gives concrete examples of what can be added, such as verses, a bridge, or an outro, making the purpose unmistakable.

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 this when' section provides clear, actionable conditions: too short a song, adding a bridge/outro, or building a longer song piece by piece. It does not explicitly name alternatives or state when not to use the tool, so it stops short of a 5.

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 must carry the behavioral disclosure burden. It does explain the workflow (user provides lyrics, Producer generates melody/arrangement) and the return shape (Task ID and audio info with URLs, title, lyrics, duration). However, it does not disclose async execution semantics, callback behavior, or other operational side effects, leaving the agent under-informed for a complex generation 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?

The description is well-structured with an intro, use-when bullets, an explicit alternative, and a Returns section. It is slightly redundant in phrasing—'full control' and 'complete creative control' say the same thing—but every section earns its place and the most important information is front-loaded.

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?

Given the tool's complexity (11 parameters) and lack of annotations, the description adequately covers the primary use case, return information, and routing to the sibling tool. It does not mention async/callback nuances or the instrumental flag behavior, though these are documented in the schema. Overall it is sufficient for an agent to select and invoke the tool correctly, with minor gaps.

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 the schema already documents all 11 parameters with defaults, ranges, enums, and examples. The description reinforces that lyrics use section markers and that style control exists, but it adds little beyond what the schema already conveys.

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?

The description opens with a specific action: 'Generate AI music with full control over lyrics, title, and style,' naming the resource and the key differentiator. It also explicitly contrasts with the sibling producer_generate_music, making it clear this tool is for custom lyric-driven generation.

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 this when' bullets clearly state the intended conditions: specific lyrics, precise style control, and specific song title. It gives an explicit alternative: 'For quick generation without writing lyrics, use producer_generate_music instead,' providing both when-to-use and when-not-to-use 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 full burden. It discloses output includes section markers and return fields (title, status, formatted text), but does not mention quotas, rate limits, or any non-obvious behaviors.

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 description is front-loaded with the main purpose and uses bullet points for usage scenarios. It is concise without fluff, though the 'Returns' line could be slightly more compact.

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?

Given the tool's simplicity (one parameter, clear output schema), the description covers purpose, usage, and output format adequately. It is complete for an agent to decide when and how to use 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?

The single parameter 'prompt' has a detailed schema description. The tool description adds value by advising to include theme, mood, genre, and giving examples. Schema coverage is 100%, so baseline 3, with extra context raising it to 4.

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?

The description clearly states 'Generate song lyrics from a text prompt' and specifies structured lyrics with proper song sections. It differentiates from sibling tools like producer_generate_music and producer_generate_custom_music.

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 includes 'Use this when:' bullet points listing appropriate scenarios. It mentions output is ready for producer_generate_custom_music, but lacks explicit exclusions or comparisons with alternatives like producer_get_lyric_format_guide.

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 provided, the description carries the full burden. It discloses that the tool automatically generates lyrics, melody, style, and arrangement, and mentions return content (Task ID, URLs, etc.). However, it does not disclose whether the request runs synchronously or asynchronously, nor how the Task ID should be used (e.g., polling with get_task), which is a significant gap for a generation 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?

The description is well-structured and front-loaded with the main purpose, followed by concise usage bullets and a clear return statement. Every sentence contributes useful information without redundancy, making it highly efficient.

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?

The description covers purpose, usage, alternatives, and return information. It lacks explicit details about async workflow (e.g., whether immediate audio URLs are returned or whether tasks must be polled), but the output schema and 100% parameter descriptions compensate for missing parameter details. Overall, it is nearly complete but could mention how to obtain results if asynchronous.

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 baseline is 3. The description only references the text prompt generically and does not add meaning beyond what the schema already provides for parameters like model, seed, or weirdness. No additional parameter context is given.

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?

The description clearly states 'Generate AI music from a text prompt' with a specific verb and resource, and explicitly differentiates from sibling tool producer_generate_custom_music by calling itself 'the simplest way' and naming the alternative for full control. This is a strong, distinct purpose.

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 provides explicit 'Use this when:' bullet points listing concrete scenarios (quick generation, no specific lyrics, AI-driven arrangement) and directly recommends producer_generate_custom_music for full control, giving clear when-to-use and when-not-to-use 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?

With no annotations provided, the description carries the full burden. It notes the tool 'creates a video with visualizations' and returns a 'Task ID', implying an asynchronous task-based flow. However, it does not disclose specifics like visual style, duration limits, or polling behavior, leaving some gaps.

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 description is well-structured and concise: a one-line summary, a brief explanation, bulleted usage scenarios, and a returns section. Every sentence adds value, and the most critical information is front-loaded.

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 single-parameter tool with a clear output schema, the description covers the essential aspects: what it does, when to use it, and what it returns. It doesn't fully explain the async nature or the content of the visualizations, but given the tool's simplicity and existing context, it is largely complete.

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 the description adds little beyond the schema. The phrase 'previously generated song' and the 'Returns' note reinforce that audio_id comes from a prior generation, but this is already stated in the schema's parameter description. Thus the baseline of 3 is appropriate.

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?

The description clearly states the tool's function: 'Generate a video for a previously generated song' with a specific verb and resource. It distinguishes this from sibling tools by focusing exclusively on video creation from existing audio, which none of the siblings target.

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 this when' list explicitly provides usage scenarios (video version, sharing on video platforms, visual representation). It lacks explicit mention of when not to use or comparison to alternatives, but the context is clear enough to apply the tool correctly among its siblings.

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 burden of behavioral disclosure. It explains the conversion action and indicates the return type ('Task ID and WAV audio information'), hinting at an asynchronous process. However, it doesn't elaborate on side effects, prerequisites, or whether the original audio is left untouched. This is adequate but not rich.

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 description is structured with a summary, WAV context, usage list, and returns section. However, the first two sentences are redundant ('Get the lossless WAV format' vs 'Converts the song to high-quality uncompressed WAV format'), making it slightly less concise than it could be.

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?

This is a simple single-parameter tool with an output schema, so the description doesn't need to detail return values. It explains the tool's purpose, usage, and provides context about WAV vs MP3. It could mention that audio_id must reference an existing generated song, but that is implied by the schema description.

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 input schema already documents audio_id with a clear description, and schema coverage is 100%. The tool description adds no additional parameter-level insights beyond what's in the schema, so it meets the baseline but doesn't enhance understanding.

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?

The description clearly states the tool's function with specific language: 'Get the lossless WAV format of a generated song' and 'Converts the song to high-quality uncompressed WAV format.' It distinguishes itself from sibling tools like producer_generate_music or producer_cover_music by focusing on format conversion rather than generation or editing.

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 provides explicit usage scenarios in a 'Use this when' list, covering needs like lossless audio, highest quality, and uncompressed output. However, it doesn't mention when not to use the tool (e.g., when file size is a concern) or explicitly name alternative tools, so it stops short of a full 5.

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?

Description clearly states it returns a complete guide with examples and tips. No annotations to contradict; behavioral traits are transparent for a read-only reference 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?

Three concise sentences front-loaded with purpose. Every sentence adds value with no wasted words.

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?

Complete for a simple guide with no parameters and an output schema. Could mention it is a static document but still sufficient.

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?

No parameters exist; schema coverage is 100%. Description adds value by explaining the guide content beyond the empty 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?

Description clearly states it provides guidance on formatting lyrics for Producer music generation, distinguishing it from sibling tools like producer_generate_lyrics which actually generate lyrics.

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?

Implies use before generating lyrics but does not explicitly state when to use vs. alternatives like producer_generate_lyrics. No exclusions or alternative suggestions are provided.

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 provided, the description carries the full burden and does an excellent job. It discloses task states, explicitly states that 'pending' and 'processing' require continued polling, gives the only 'done' state ('complete'), and includes a critical warning about intermediate audio URLs not being final results. This is far beyond basic disclosure.

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 description is appropriately sized and front-loaded, starting with the primary purpose. It uses clear sections (Use this when, Task states, CRITICAL) and every sentence contributes necessary information, especially the critical warning about intermediate audio URLs. No wasted words.

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?

Given the tool's complexity (polling semantics, state machine, intermediate data), the description is fully self-contained. It explains the states, the correct completion condition, the trap of intermediate audio URLs, and summarizes the output. With an output schema present, it appropriately does not enumerate return fields in detail.

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 schema already provides 100% coverage of the single parameter (task_id), including its provenance from generation tools. The description repeats this information without adding significantly new meaning beyond what the schema already documents, so the baseline of 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?

The description clearly states the tool queries the status and result of a music generation task, using a specific verb ('Query') and a specific resource ('a music generation task'). It distinguishes itself from sibling tools by focusing on polling and retrieving individual task results, with explicit use cases listed.

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 provides explicit 'Use this when' scenarios (checking completion, retrieving audio URLs, getting full details). However, it does not explicitly mention when not to use this tool or recommend alternatives like producer_get_tasks_batch for batch operations.

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 provided, so description bears full burden. It discloses critical behavior: task completion condition (state='complete', success=true) and warns that intermediate audio_url values during 'pending' are streaming previews, not final results.

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?

Well-structured with sections and front-loaded purpose. Minor redundancy between 'Efficiently check...' and 'More efficient than...' but overall efficient and easy to scan.

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?

Given simple schema (1 param with full description) and existence of output schema, the description covers functionality, usage context, critical behavioral warnings, and return description. No gaps evident.

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% for the single parameter 'task_ids', with description already stating batch size limit. The description adds no additional parameter meaning beyond the schema, so baseline 3 is appropriate.

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?

Clearly states it queries multiple music generation tasks, differentiating from sibling producer_get_task by emphasizing batch efficiency. The core action and resource are unambiguous.

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?

Explicitly lists when to use (multiple pending generations, batch tracking) and notes efficiency advantage over single-task variant. Lacks explicit 'when not to use' but positive guidance is clear.

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 full burden. It discloses it returns a 'Categorized list of all actions and their corresponding tools,' which implies read-only behavior. No contradictions or hidden effects.

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 description is concise with two sentences plus a Returns line, front-loaded with the main action. No wasted words.

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?

Given zero parameters and an output schema, the description sufficiently explains the tool's purpose and what it returns. No gaps.

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 has zero parameters, so the description adds context by mentioning 'Categorized list,' which hints at the structure of the output 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?

The description clearly states 'List all available Producer API actions and corresponding tools' with a specific verb and resource. It distinguishes itself from sibling action tools by being a reference guide.

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 provides context as a 'Reference guide' and 'Helpful for understanding the full capabilities.' It implies when to use it but lacks explicit alternatives or when-not-to-use 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 provided, but the description transparently states it lists models and returns a table of versions and features. Could add that it is read-only.

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?

Concise two-sentence description plus a return note, no wasted words, front-loaded with purpose.

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 simple list tool with no parameters and an output schema, the description is adequate, though it could mention output format details beyond 'table'.

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?

No parameters exist, so the schema covers 100%. Baseline of 4 applies; description adds nothing beyond 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?

The description clearly states the tool lists all available Producer/FUZZ models and their capabilities, distinguishing it from sibling tools like generation or upload tools.

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?

Explicitly advises to use this tool to understand which model to choose for music generation, providing clear usage context.

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 burden of disclosing behavior. It states the core effect (re-generates a portion between start/end and leaves the rest unchanged) and says it returns a Task ID and updated audio info, which is useful. However, it remains silent on whether the original audio is permanently mutated or a new version is produced, and gives no detail on async or callback behavior.

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 description is well-structured with a front-loaded action, a use-case bullet list, and a returns line. It is concise overall, though the first sentence and the second sentence both restate the same time-range idea, which is a minor redundancy.

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?

Given the output schema, the return-value mention is a bonus. The description covers the tool's purpose, usage triggers, and the key effect on the song. It does not explain async/callback semantics, but those are documented in the input schema by parameter descriptions.

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 the schema already documents all 8 parameters (audio_id, replace_section_start/end, prompt, model, async, callback_url). The description adds little beyond referring to the specified start and end times, 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?

The description opens with a specific verb+resource: 'Replace a specific time range in a song with new generated content,' and elaborates with 'keeping the rest of the song unchanged.' This clearly differentiates the tool from siblings like extend, cover, or variation because the unique scope is a contiguous time window within an existing track.

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?

A dedicated 'Use this when' list gives concrete triggers (fixing sections, changing lyrics, replacing a verse/chorus). It does not mention exclusions or name sibling alternatives, but the context is clear enough to select the tool.

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 burden. It mentions returning a Task ID and track URLs, hinting at asynchronous behavior, but does not explicitly disclose that this is a long-running operation requiring polling or callback handling. It also omits prerequisites, rate limits, or any caveats about output quality, leaving significant behavioral traits undisclosed.

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 description is well-organized with a summary sentence, usage bullets, and a returns section. It is not overly verbose, though the 'useful for' line is somewhat redundant. Overall, it is efficient and front-loaded with the core purpose.

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?

The description covers purpose, usage scenarios, and return types adequately. However, it misses the crucial async execution model and how the Task ID should be used (polling vs callback), which is a significant gap given the async parameter. With an output schema present, return details need not be exhaustive, but the missing workflow context reduces completeness.

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 the baseline is 3. The description does not add extra meaning beyond the schema; it doesn't explain async or callback_url behavior, but the schema already fully documents these parameters. No additional semantic value is provided.

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?

The description clearly states the tool separates a song into individual stems (vocals and instrumentals). This specific verb+resource pairing distinguishes it from sibling tools like producer_swap_vocals or producer_replace_section, which modify audio differently.

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 this when' section provides clear, contextual scenarios such as remixing, karaoke, or isolating parts. It does not explicitly state when not to use this tool or mention alternative tools, but the usage context is strong enough for an agent to choose correctly.

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?

There are no annotations, so the description carries the disclosure burden. It does frame the operation as 'Requests instrumental swapping' and states that a Task ID is returned, which tells the agent the operation is task-based rather than returning immediate audio. However, it does not disclose whether the original file is modified, how the result is eventually retrieved, or any prerequisites or limitations.

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 description is short, front-loaded, and scannable with use-case bullets and a Returns line. The second sentence, 'Requests instrumental swapping for the provided audio,' is largely redundant with the first sentence and does not fully earn its place.

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?

The central workflow is incomplete: the description says instrumentals come 'from another' song, but the schema exposes only a single audio_id plus async and callback_url, with no way to identify the other instrumental source. An agent cannot reliably determine what to pass or how the replacement source is chosen. Return values are likely covered by the output schema, but this source ambiguity is a significant functional gap.

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 input schema fully documents all three parameters, so the description does not need to add parameter-level detail; the baseline 3 applies. The phrase 'from another' is not mapped to any actual parameter, which introduces mild ambiguity about how the replacement instrumental source is selected, but the schema itself is clear about audio_id being the base audio.

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?

Opens with a concrete verb-object statement: 'Swap the instrumental track of one song with instrumentals from another.' It names the action and resource clearly, and the instrumental-vs-vocal wording distinguishes it from the sibling swap_vocals tool without needing further explanation.

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?

Provides an explicit 'Use this when' bullet list with concrete scenarios: combining instrumentals from one song with vocals from another, testing vocals over different music, and creating an instrumental mashup. It does not mention when not to use it or directly route to alternatives, so it falls just short of full 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 present, so the description carries the full transparency burden. It mentions 'Requests' and states that a Task ID is returned, implying an asynchronous request flow. However, it does not disclose side effects, prerequisites, or how the replacement vocals are supplied, leaving important behavioral details incomplete.

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 description is concise and front-loaded with the main action. The 'Requests vocal swapping' sentence is mildly redundant with the first line, but the bullet list and Returns section are useful and economically worded.

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?

Although an output schema exists, the description omits how the second audio source is identified, which is essential for correct invocation. The mismatch between the described two-song swap and the single-audio request schema leaves the tool incomplete from an agent's perspective.

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 the baseline is 3, but the description creates confusion by referencing 'another song' with no corresponding schema parameter. The only audio-related param, audio_id, is described as the base audio whose vocals are replaced, so an agent cannot determine how to specify the replacement vocals, undermining the parameter clarity.

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: swapping the vocals between two songs. The term 'vocals' clearly distinguishes it from sibling tools like producer_swap_instrumentals. The core action is immediately recognizable even though the second-audio mechanism is not explicit.

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?

Provides a 'Use this when' list with three concrete scenarios: vocal mashups, trying different vocals over a beat, and combining vocals with another instrumental. It does not name alternative tools or explicitly say when not to use, but the context is clear.

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?

The description explains that the tool uploads audio from a URL and returns an audio_id. It mentions the URL must be directly accessible, which is a useful constraint. Without annotations, the description provides reasonable behavioral context for a simple upload operation.

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 description is relatively concise with a clear structure: main verb, explanation, use cases, and return value. It is front-loaded with the key purpose. Could be slightly tighter but overall efficient.

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?

Given the tool's simplicity (one parameter, no nested objects) and the presence of an output schema, the description covers the workflow adequately. It explains how the output (audio_id) is used with sibling tools, making it contextually complete.

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 single parameter 'audio_url' has 100% schema coverage, and the description adds extra guidance that the URL must be directly accessible. This adds semantic value beyond the schema's basic description.

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?

The description clearly states the tool uploads an external audio file for subsequent operations, and distinguishes it from sibling tools that process audio. It specifies the output (audio_id) and usage with actions like extend, cover, etc.

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 lists specific scenarios when to use the tool (e.g., when you have your own music, want to use external audio). While it doesn't explicitly state when not to use it, the context makes it clear that this is the import tool and siblings are for processing.

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 behavioral burden. It clearly states that a new version is generated and that the return includes a Task ID and variation audio information. However, it does not disclose async/callback behavior, whether the original audio is left untouched, or any side effects beyond generating a new version.

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 description is well-structured with clear sections for the main action, use cases, and return value. Some redundancy exists between the opening sentence and the second paragraph, as both describe generating a new version with modifications, which prevents a perfect score.

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?

The description covers what the tool does and when to use it, and the output schema covers return values. However, it does not clarify how async processing works, when to set callback_url, or whether the original song is preserved, which are relevant for correctly invoking this tool in different scenarios.

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 the schema already documents all parameters. The description adds some context by mentioning arrangement, melody, and style, which aligns with the prompt parameter's purpose, but it does not meaningfully explain audio_id, model, async, or callback_url beyond what the schema provides.

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?

The description states a specific verb and resource: 'Create a variation of an existing song with modifications.' It further clarifies the nature of the output as a new version with subtle changes to arrangement, melody, or style while keeping structure similar, which distinguishes it clearly from sibling tools like generate, cover, extend, or replace_section.

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 this when' section gives concrete scenarios for when the tool is appropriate, such as wanting a slightly different version or exploring interpretations. However, it does not explicitly say when not to use it or name alternative sibling tools that might be better suited for related tasks.

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