Server Quality Checklist

Tool Scores

• producer_stems_musicA
  3.6/5.0
  Behavior2/5

  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.

  Conciseness4/5

  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.

  Completeness3/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• producer_generate_wavA
  3.8/5.0
  Behavior3/5

  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.

  Conciseness3/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• producer_extend_musicA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full responsibility. It states the return value ('Task ID and the extended audio information') and the general nature of the operation, but does not disclose whether the original song is preserved, whether the extension is non-destructive, or any limitations like maximum extension length or rate limits. This leaves important behavioral details ambiguous.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is structured with a one-sentence summary, a brief explanatory paragraph, a bulleted use-case list, and a returns section. It is slightly more verbose than necessary, but every section contributes value and it is front-loaded with the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (7 parameters, output schema, many siblings), the description provides sufficient context: when to use, what it does, and what it returns. It does not elaborate on async behavior or edge cases, but the schema and output schema cover those details, making the description adequately complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter already having a detailed description. The tool description adds a little context (e.g., 'verses, bridge, outro' mapping to the lyric parameter) but does not meaningfully enhance understanding beyond what the schema provides. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The opening sentence, 'Extend an existing song from a specific timestamp with new content,' uses a specific verb ('extend') and resource ('existing song') with a precise condition (timestamp). It clearly distinguishes from sibling tools like generate_music or cover_music by focusing on continuation rather than creation or transformation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description includes a 'Use this when:' section listing three concrete scenarios (song too short, adding bridge/outro, building piece by piece). This gives clear context for when to select this tool, though it does not explicitly name alternatives or specify when not to use it.

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

• producer_replace_sectionA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries full behavioral disclosure burden. It clearly states the core effect (re-generates a portion, keeps the rest unchanged) and the return value (Task ID and updated audio info). However, it does not clarify whether the original audio is overwritten or a new version is created, nor does it mention async behavior or other side effects despite having async and callback_url parameters.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a clear opening statement, a brief elaboration, a bulleted 'Use this when' list, and a 'Returns' section. It is compact and each sentence contributes to understanding, though the three bullets are somewhat repetitive and could be condensed.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity of 8 parameters and an output schema, the description covers the core operation and return value well. It provides sufficient context for selection among siblings. However, it omits guidance on async behavior and the interplay of parameters like style and model, which would be useful for effective invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters already have descriptive text. The tool description adds little beyond restating the 'start and end times' concept and the idea of 'new generated content,' which is already implied in the schema. It does not elaborate on how lyric, style, or model parameters influence the generated section.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Replace' and clearly identifies the resource as 'a specific time range in a song.' It distinguishes itself from sibling tools like extend_music (adds to the end) and variation_music (varies the whole track) by emphasizing section-level regeneration while keeping the rest unchanged.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The 'Use this when' list provides three explicit scenarios: improving a specific section, changing lyrics in the middle, and replacing a verse/chorus. This gives clear context for when to use the tool, but it lacks explicit 'when not to use' or direct alternatives, so it doesn't reach the highest bar.

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

• producer_cover_musicA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It explains that the tool generates a new version while retaining core melody/lyrics and states the return value (Task ID and cover audio info). However, it does not disclose details like async behavior, model impact, or potential side effects, which would be valuable context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured, with a clear opening statement, bulleted use cases, and a returns section. Every sentence adds value, and the format makes it easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the rich schema (6 params, enums, output schema) and no annotations, the description provides sufficient context: purpose, usage scenarios, and return type. It could mention that audio_id must come from a previous generation, but the schema already states that, so coverage is adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  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 much parameter-level meaning beyond reinforcing the purpose; the schema already provides comprehensive descriptions for all 6 parameters, including examples for style and prompt.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool creates a cover or remix version of an existing song in a different style, using the specific verb 'create' and resource 'existing song'. It distinguishes from sibling tools by emphasizing the transformation of an existing track while preserving melody and lyrics, which is distinct from pure generation or variation tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The 'Use this when' section provides three concrete scenarios (different genre, acoustic version, remix with different vibe), giving clear context for when to use this tool. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5 but is still strong.

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

• producer_generate_videoA
  4/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• producer_swap_vocalsA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the transparency burden. It discloses the operational logic (instrumental from base + vocal from swap) and states the return value (Task ID and swapped audio info). However, it omits side effects like whether original files are modified, permission requirements, or async behavior details, which are only partially covered by the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured with a short intro, a process explanation, a bulleted use-case list, and a returns section. It avoids redundancy and every section serves a purpose, making it efficient at roughly 70 words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity and the presence of an output schema, the description covers the core operation, use cases, and returns. The sibling tool producer_swap_instrumentals provides a nearby alternative, but the description's specificity adequately differentiates it, though it could mention prerequisites like audio uploads.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already has 100% description coverage for all four parameters, including clear definitions for audio_id and swap_audio_id. The description reinforces the parameter roles with the instrumental/vocal explanation but adds little beyond the schema, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Swap the vocals of one song with vocals from another song,' which clearly identifies the verb and resource. It further clarifies by explaining the instrumental/vocal combination, distinguishing it from sibling tool producer_swap_instrumentals.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The 'Use this when' section lists three concrete scenarios, providing clear context for when to apply the tool. It doesn't mention alternatives or exclusions, but the use cases are specific enough to guide selection.

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

• producer_variation_musicA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses that the tool creates a 'new version' (implying non-destructive behavior) and that it returns a 'Task ID,' hinting at asynchronous processing. However, it does not disclose permissions, rate limits, or processing time expectations, which would be valuable for a generative tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured: a one-sentence summary, a second sentence elaborating on the output, a bulleted 'Use this when' list, and a 'Returns' section. Each sentence earns its place, and the content is front-loaded with the most important information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the tool's purpose, usage scenarios, and return value ('Task ID and the variation audio information'). With an output schema present, it doesn't need to detail return values further. It doesn't explicitly mention the asynchronous nature beyond the 'Task ID' hint, but given the schema's documentation of the async parameter, this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 100%, so the baseline is 3. The description itself does not add any parameter-specific information; it relies entirely on the schema to explain audio_id, model, style, prompt, async, and callback_url. This is acceptable given the schema's thoroughness.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  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 a specific verb and resource: 'Create a variation of an existing song with modifications.' It further explains that it generates a new version with 'subtle changes to the arrangement, melody, or style while keeping the overall structure similar.' This distinguishes it from sibling tools like cover_music, extend_music, and replace_section, which imply different transformations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear 'Use this when' section with three explicit scenarios: liking a song but wanting a slightly different version, exploring different interpretations, and needing multiple takes. However, it does not mention when not to use it or explicitly name alternatives, so it falls 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.

• producer_generate_lyricsA
  4.1/5.0
  Behavior3/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• producer_generate_custom_musicA
  4.2/5.0
  Behavior3/5

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

  No annotations exist, so the description carries full weight. It discloses the main workflow (user provides lyrics, Producer generates melody/arrangement) and mentions return content (Task ID and audio info). However, it does not clarify async behavior or how to retrieve results via task ID, and the phrase 'Returns Task ID and generated audio information' is ambiguous for asynchronous requests.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, front-loaded with purpose, uses bullet points for usage, includes an alternative, and ends with a clear Returns section. Every sentence earns its place without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers core purpose, usage guidance, alternatives, and return values. While it lacks explicit mention of async result retrieval, the output schema and sibling get_task tool cover that gap, making it sufficiently complete for a tool with 11 parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% with detailed parameter descriptions (e.g., lyric markers, style examples). The description adds focus on lyrics, title, and style but no new semantic information beyond the schema, meeting the baseline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description begins with 'Generate AI music with full control over lyrics, title, and style,' providing a specific verb and resource. It explicitly distinguishes from the sibling tool: 'For quick generation without writing lyrics, use producer_generate_music instead.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Clear bullet-list of when to use (specific lyrics, precise control, specific title) and explicit alternative (producer_generate_music) with rationale. This is exactly the kind of guidance needed for tool selection.

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

• producer_generate_musicA
  4.2/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.

• producer_get_lyric_format_guideA
  4.2/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines3/5

  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.

• producer_swap_instrumentalsA
  4.2/5.0
  Behavior4/5

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

  Since no annotations are provided, the description carries the full burden for behavioral transparency. It clearly states that 'Takes the vocals from the base audio and combines them with the instrumental track from the swap audio,' and it notes that it returns a Task ID and swapped audio information, implying an asynchronous, non-destructive operation. It does not mention side effects, auth, or rate limits, but the core behavior is well disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is appropriately sized and front-loaded, with the core purpose in the first sentence. The three bullet points under 'Use this when:' are direct and useful, and the 'Returns' line is concise. No filler sentences exist.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has output schema and full parameter descriptions, so the description can focus on behavior and usage. It covers the main operation, use cases, and return value. It could mention async/callback behavior more explicitly, but those are already present in the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All four parameters have schema descriptions with 100% coverage, so the baseline is 3. The description reinforces the relationship between audio_id and swap_audio_id but does not add parameter-specific meaning beyond what the schema already provides for async or callback_url.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Swap the instrumental track of one song with instrumentals from another,' which uses a specific verb and resource. It also clarifies that it keeps vocals from the base audio and uses instrumentals from the swap audio, distinguishing it from related tools like producer_swap_vocals.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description includes a 'Use this when:' section with three concrete scenarios: combining instrumentals from one song with vocals from another, hearing the same vocals over different music, and creating an instrumental mashup. It does not mention when not to use it or name alternatives, so it stops short of the highest score.

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

• producer_upload_audioA
  4.3/5.0
  Behavior4/5

  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.

  Conciseness4/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• producer_get_tasks_batchA
  4.4/5.0
  Behavior5/5

  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.

  Conciseness4/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• producer_get_taskA
  4.5/5.0
  Behavior5/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters3/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• producer_list_actionsA
  4.5/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness5/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines4/5

  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.

• producer_list_modelsA
  4.6/5.0
  Behavior4/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose5/5

  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.

  Usage Guidelines5/5

  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.