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

Discloses a specific behavioral quirk: two same-named sets may be returned without metadata, and both are preserved to avoid data loss. Since annotations are absent, this adds valuable transparency.

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, front-loads the purpose, and includes usage guidance and return info. Slightly verbose with the 'Returns' section but focused and useful.

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 is straightforward with 2 params and high schema coverage interesting for asynchronous behavior, but the behavioral quirk is disclosed. It sufficiently covers the key decision points and usage context, though it could mention callback_url usage more explicitly.

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% for both parameters (audio_id and callback_url), so the schema already explains them. The description adds minimal extra semantics, but baseline 3 applies given high coverage.

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 specifies the exact purpose: separating audio into all individual stems (vocals, bass, drums, other instruments). It clearly differentiates from the sibling tool suno_stems_music by noting it provides more granular separation.

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 'Use this when' scenarios: full multi-track separation, remixing, needing individual instrument tracks. It also implicitly contrasts with suno_stems_music, aiding tool selection.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It does add the caveat that archiving does not guarantee capacity release, which is useful, but it omits whether archiving is reversible, whether it affects existing generations or references, and what error or failure conditions may occur.

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

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

Two short sentences with no filler. The core purpose is front-loaded, and the additional capacity caveat earns its place as an important behavioral note.

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 one-parameter tool with an output schema, the description is mostly complete: it states what happens and adds a relevant caveat. It could improve by mentioning reversibility or confirmation behavior, but the core information needed to call it correctly is present.

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 documents the single parameter with 100% coverage: 'ID of the custom music model to archive.' The description adds no further semantic detail, so the baseline score 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 a specific verb ('Archive'), a specific resource ('custom music model'), and the key effect ('can no longer be used'). This distinguishes it from sibling custom-model tools like creation, retrieval, listing, and 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 case is clear: archive an existing custom model to disable its use. It does not explicitly name alternatives or state when not to use it, but the action itself and the effect are specific enough to guide selection among the sibling tools.

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 carries full burden. It explains that the tool merges all connected segments and returns task ID and audio info, but does not disclose potential side effects, authorization needs, or rate limits. Behavior is straightforward but lacks depth.

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 three-paragraph structure: purpose, usage guidance, and return value. Every sentence adds value with no 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?

Covers main aspects: what it does, when to use, and what it returns. Has output schema, so return description is sufficient. Lacks explicit mention of async behavior (implied by callback_url) and error handling, but adequate for a simple tool.

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% with both parameters having descriptions. The tool description does not add additional parameter insights beyond the schema, meeting the baseline for high coverage but not exceeding it.

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 concatenates extended song segments into a single audio file. It specifically references the sibling tool suno_extend_music, distinguishing this tool's purpose from others.

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 describes when to use: after extending a song multiple times and wanting a single file. Includes clear use cases. No explicit when-not conditions, but the context is sufficient for a specialized utility 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?

No annotations are provided, so the description carries full burden. It describes the high-level function but omits behavioral details such as asynchronous nature (implied by callback_url parameter), idempotency, costs, or side effects. The return value is mentioned minimally.

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 at five sentences, including a structured 'Use this when:' section with three bullets and a 'Returns:' line. Every sentence adds value, and the key information is front-loaded in the first sentence.

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 moderate complexity (6 parameters, 1 required, output schema present), the description covers the main purpose, usage scenarios, and return format. It is mostly complete, though it could mention the asynchronous nature of the task for better 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?

With 100% schema description coverage, the baseline is 3. The main description adds overall context by mentioning 'core melody and lyrics' and different styles, but does not elaborate on individual parameters beyond what the schema already provides. No additional meaning is added.

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 creates a cover or remix of an existing song in a different style, with a specific verb ('Create') and resource. It distinguishes from sibling tools like suno_remaster_music and suno_generate_music by focusing on altering style while keeping melody/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?

The 'Use this when:' section with three detailed bullet points provides clear context for when to use the tool, such as wanting a different genre or acoustic version. However, it does not explicitly mention when not to use it or suggest alternatives among 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?

No annotations are provided, so the description carries the full burden of disclosure. It reveals that this is a 'paid, long-running operation' and that it requires user confirmation before invoking, which is critical behavioral context. It could add more detail about asynchronous status or cost implications, but the provided warning is substantial.

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 two short paragraphs with no filler. The core purpose is front-loaded, and the important usage warning about payment and user confirmation is placed immediately after in a compact, readable format.

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 presence of a full output schema and complete parameter descriptions, the description provides the key missing context: it is paid, long-running, and must only be invoked after explicit user confirmation. This is sufficient for an agent to decide whether and when to call this tool.

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 fully documents all four parameters. The description's mention of 'source files' and 'authorized audio examples' maps to the audio_urls parameter but adds little new information beyond what the schema already states.

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 begins with a specific verb and resource: 'Create a reusable custom music model from authorized audio examples.' This clearly distinguishes the tool from generation tools like suno_generate_music and suno_generate_with_custom_model, since it creates a reusable artifact rather than generating 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 gives an explicit precondition: 'Call it only after the user confirms the source files and the 5.6-Credit list price.' This is strong guidance on when to invoke the tool. It does not explicitly name alternatives such as suno_generate_with_custom_model or suno_get_custom_model, but the precondition is clear enough for safe usage.

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 indicates a mutation (creation) but does not disclose side effects, prerequisites (e.g., existing audio), error conditions, or limitations. Basic transparency but lacking depth.

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 purpose. The bullet list of use cases is clear and efficient, though slightly redundant with the prior sentence.

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, workflow, and return value, but lacks behavioral details, error handling, and differentiation from related tools. Given no annotations, it is adequate but has 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 baseline is 3. The description does not add significant parameter context beyond what the schema already provides; it only mentions 'vocal characteristics' generically.

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 an artist persona from existing audio's vocal style for reuse. It explains the purpose and workflow (using with suno_generate_with_persona) but does not explicitly differentiate from the similar sibling suno_create_voice.

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 use cases (love a voice, multiple songs, album consistency) and provides a clear workflow for subsequent generation. However, it lacks guidance on when not to use the tool or alternatives like suno_create_voice.

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 disclosure burden — and it handles this well by specifying hard input constraints (MP3/WAV, ≥10 seconds, single clear speaker, no background noise) and stating the output contract ('Persona ID that can be used with suno_generate_with_persona'). It does not cover failure modes or what happens when requirements are unmet, but for a persona-creation tool this is above-average 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?

Well-structured and front-loaded with a one-line purpose statement, followed by requirement clarification, sibling differentiation, a use-case bullet list, and a Returns note. Every section earns its place with no filler; only slightly longer than strictly necessary given the schema already covers parameter syntax.

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 moderate-complexity tool (3 params, 1 required, output schema present), the description is thorough: it covers purpose, input requirements, the key sibling distinction (suno_create_persona vs suno_create_voice), appropriate use cases, and the returned value's downstream usage. The main ambiguity in a 35-tool sibling space is the persona-creation path, and that is fully resolved.

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% — the audio_url parameter's schema entry already carries the detailed constraints (format, duration, single-speaker requirement). The description echoes the audio requirements but adds little beyond the schema for name and description, which are self-explanatory optional fields. Baseline 3 is appropriate; the heavy lifting is correctly done by 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?

Opens with a specific verb+resource+scope ('Create a custom voice persona from an external audio URL') and immediately distinguishes itself from the closest sibling: 'This is different from suno_create_persona which creates a persona from a previously generated Suno audio.' This explicit differentiation against the most confusable sibling makes the purpose 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?

Provides an explicit 'Use this when:' bulleted list with three concrete scenarios, and implicitly states when NOT to use it by contrasting with suno_create_persona. It names the alternative tool directly and clarifies the external-vs-Suno-seed distinction, giving the agent clear decision 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 description explicitly states 'This action cannot be undone' and 'Permanently removes', disclosing destructive behavior. Also mentions return value.

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 bullet points for usage and returns. Efficiently covers purpose, irreversibility, and output without extraneous information.

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

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

For a simple delete tool, description covers what, when, effect, and return value. Lacks prerequisites or error cases, but is adequate given low complexity and existing output schema.

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 baseline is 3. Description does not add meaning beyond schema; only restates persona_id and mentions return value, not parameter details.

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 'Delete a saved artist persona' and 'permanently removes a previously created persona'. Distinct from siblings like create and list personas.

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 three use cases (remove unused, clean up old, delete no longer needed). Does not mention alternatives or when not to use, but provides clear context for a destructive 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?

No annotations provided, so description bears full burden. It states the tool returns Task ID and audio info, and maintains style if empty, but lacks details on limitations (e.g., max extension length), side effects, or authentication needs. Adequate but could be more comprehensive.

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?

Delivers core action in the first sentence, then bullet lists usage cases, workflow hint, and return info. No unnecessary words; well organized and 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?

Covers purpose, usage, parameter hints, follow-up step (concat), and return value. Could mention output schema structure or extension length limits, but output schema exists so completeness is strong. Minor gaps prevent a 5.

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 covers all 6 parameters with descriptions. The description adds context about using section markers for lyrics and timestamp format, but does not significantly enhance understanding beyond the schema. Baseline of 3 is appropriate given high coverage.

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 the verb 'extend' and resource 'existing song from a specific timestamp with new lyrics'. Lists specific uses like adding verses, bridge, outro, and distinguishes from sibling tool suno_concat_music by mentioning it for merging segments after multiple extensions.

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 explicit when-to-use scenarios (too short, add bridge/outro, build piece by piece) and tells when to use the sibling tool suno_concat_music. The bullet list gives clear context for selection.

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 the core behavior (isolating vocals, removing instrumental background) and that it returns a Task ID and vocal info, but it does not explain the asynchronous nature, whether the original song is modified, or how the extracted audio is delivered.

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, a 'Use this when' list, and a Returns section. It is concise enough but could be tightened by merging the first two sentences.

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 exists, the description need not detail return values, but it should mention that this is an asynchronous task (Task ID implies it) and that the audio must be Suno-generated. The description covers use cases and return info but misses operational nuances.

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 does not add any parameter-specific meaning beyond the schema; it only implies time-based extraction without elaborating on the parameters.

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 extracts the vocal track from a song (stem separation), using specific verb 'Extract' and resource 'vocal track'. It distinguishes from siblings like suno_all_stems_music by specifying it isolates only vocals.

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 explicit 'Use this when' bullet points covering isolated vocals, remix/mashup needs, and persona creation. However, it does not mention when not to use it or alternatives like suno_stems_music for full stem separation.

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. It discloses return values (Task ID and generated audio info), notes vocal gender requires v4.5+, and mentions duration only works for specific model/action combos. It could add more about async behavior or errors but covers the most important operational details.

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 moderately long but well-structured: intro line, bullet-style 'Use this when' list, sibling comparison, and return info. No filler or repetition; each line contributes distinct value.

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 13 parameters, all schema-covered, and an output schema, the description covers the core decision points and key constraints. It does not enumerate every parameter (unnecessary) but gives enough context to call the tool correctly. Minor gaps remain around advanced parameters like weirdness or style_influence, but these are secondary.

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 meaningful examples for lyrics and style, but does not substantially elevate the semantics 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.

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

Description states a specific verb ('Generate'), resource ('AI music'), and explicit scope ('full control over lyrics, title, and style (Custom Mode)'). It clearly differentiates from sibling by naming the alternative for quick 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?

Provides an explicit 'Use this when' list enumerating concrete conditions (specific lyrics, precise style, vocal gender, etc.) and explicitly states the alternative: 'For quick generation without writing lyrics, use suno_generate_music instead.' This is exemplary routing 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, the description carries full burden. It discloses that inspo draws stylistic inspiration rather than copying, and includes a copyright tip about avoiding well-known catalog recordings. It also states the return includes Task ID and generated audio info. This provides meaningful behavioral context beyond the schema, though more details on auth or rate limits would be beneficial.

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 well-structured: first paragraph defines the tool, second gives usage scenarios, third states returns. Every sentence adds value with no redundancy. Front-loaded with the key distinction from covers.

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?

Considering the parameter count (7), full schema coverage, and presence of output schema, the description covers the essentials: purpose, usage, and return values. It could mention error handling or generation duration, but overall it is sufficiently complete for an agent to understand the tool's role and invocation.

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 each parameter is individually documented. The description adds overall context (e.g., the tip about audio_urls and copyright) but doesn't significantly enhance understanding of individual parameters beyond the schema. Baseline score of 3 is appropriate since the schema does most of the work.

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 generates brand-new music inspired by 1-4 reference audios, distinguishing it from cover tools ('Unlike a cover, inspo does not reproduce the source tracks'). It specifies the action ('Generate brand-new music') and the resource ('inspired by reference audios'), effectively differentiating it from siblings like suno_cover_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 provides explicit 'Use this when' bullet points: having reference tracks to riff on or wanting a new song 'in the style of' provided audio. While it doesn't explicitly state when not to use or list alternatives, the sibling tool list implies options like suno_cover_music or suno_generate_music, offering sufficient 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 that lyrics include section markers and are formatted for Suno's music generation, and mentions output fields (title, status, formatted text). However, it omits behavioral traits like error handling, rate limits, or cost implications, which are important 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 approximately 100 words, front-loaded with the key action, followed by usage bullets and output summary. Every sentence serves a purpose with no redundancy or filler.

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

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

The tool has only 2 parameters, and the description covers purpose, usage scenarios, and output format. Given the existence of an output schema (not shown), it appropriately defers return value details. However, it lacks information on potential errors or limits, preventing a full 5.

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 adds minimal extra semantic value beyond the schema, just confirming that the prompt is a description and that 'default' is recommended for the model parameter. It does not clarify parameter constraints or format requirements.

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 generates song lyrics from a text prompt with structured sections like Verse and Chorus. It differentiates from sibling tools by mentioning integration with suno_generate_custom_music, but does not explicitly contrast with other lyrics-related tools like suno_mashup_lyrics, hence not a full 5.

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 three bullet-point use cases ('Use this when:') covering common scenarios. However, it lacks guidance on when NOT to use this tool (e.g., if you already have lyrics or need to mashup) and does not compare against alternative sibling tools, limiting its decision-making utility.

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 discloses that it auto-generates lyrics, melody, style, and arrangement, and specifies return values (Task ID, audio info). However, it does not mention async behavior, rate limits, or potential costs, which would improve transparency.

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: a brief introductory sentence, three bullet points for usage, a sibling mention, and a return value line. No redundant or rambling content.

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 complexity (5 params, output schema exists), the description covers purpose, usage guidelines, behavior, and return format succinctly. It references the sibling tool for advanced needs, making it complete for the intended use case.

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%, with detailed descriptions, examples, and enums for each parameter. The description does not add additional meaning beyond the schema, so a baseline score 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 generates AI music from a text prompt using Suno's Inspiration Mode, and explicitly distinguishes it from sibling suno_generate_custom_music, which offers full control over lyrics and style.

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 a 'Use this when:' section with three specific scenarios (quick generation, no specific lyrics, want creative arrangement) and directs users to an alternative for full control, providing 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 present, the description carries the full burden and does disclose important behavior: the initial response is an async task, polling is required, and the operation 'never falls back to another model.' This goes beyond the schema, though the awkward 'only accepts the async task' phrasing slightly obscures the intended meaning.

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 compact and front-loaded: the first sentence states purpose, and the second provides essential async behavior. The phrasing 'only accepts the async task' is slightly confusing but the overall structure is efficient and relevant.

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 gives the core workflow—generate, poll, no fallback—but does not specify how polling should be performed or which sibling tool to use for polling. Since an output schema exists and all parameters are documented, this is adequate but has clear gaps in operational 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 parameter-level detail beyond what the input schema already documents; the schema already defines id, title, lyric, and style clearly.

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 operation: 'Generate a song using a ready custom music model.' The phrase 'ready custom music model' distinguishes this from persona-based or generic generation, but it does not explicitly differentiate from similarly named siblings like suno_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 implies the tool should be used when a ready custom music model exists, and the async behavior is stated. However, it gives no explicit when-to-use/when-not-to-use guidance or alternatives, leaving the agent to infer selection among the many generation 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?

No annotations are provided, so the description carries the full burden. It mentions the return value (Task ID and generated audio information) but does not disclose other behavioral traits such as whether the operation is synchronous or asynchronous, rate limits, or if it has any side effects. The callback_url parameter suggests async support, but the description does not elaborate.

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 sentence and bullet-style use cases. It is not overly verbose but could be slightly more concise. However, it effectively communicates the key points without unnecessary detail.

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 presence of an output schema, the description appropriately mentions the return value. All parameters are covered by the schema, and the description explains the tool's niche relative to sibling tools. The context is complete for an agent to understand when and how to use this tool.

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 (e.g., 'use its ID here' for persona_id) but does not significantly enhance understanding beyond what is in the schema. Baseline for high coverage is 3.

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 purpose: to generate music using a saved persona for consistent vocal style. It distinguishes from sibling tools like suno_generate_music by emphasizing persona reuse, and mentions the prerequisite of using suno_create_persona.

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 explicitly lists when to use this tool (multiple songs with same style, album/series, reusing a voice) and provides a clear prerequisite: create a persona first with suno_create_persona. This gives definitive guidance on when this tool is appropriate and how to prepare.

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 full burden. It explains the tool uses a VOX action for vocal consistency and returns Task ID and audio info. While it doesn't cover auth or rate limits, the behavioral description is adequate 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 with clear sections: main action, similarity, usage conditions, prerequisite, and returns. Every sentence is necessary 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?

Given the tool has 5 parameters and an output schema, the description covers the key aspects: action, when to use, prerequisite, and return type. It could mention any limitations or queuing behavior, but 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 baseline is 3. The description adds value by explaining how persona_id relates to other tools and that the prompt's voice will be applied, going beyond the 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 clearly states the tool generates music using a saved artist persona with VOX-specific consistency, and explicitly distinguishes it from the sibling suno_generate_with_persona by noting it uses the artist_consistency_vox action.

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 explicit usage conditions in a 'Use this when:' list, including three specific scenarios and a prerequisite (create persona first). This gives 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, the description is the sole source of behavioral information. 'Retrieve' clearly communicates a read-only operation with no mutation side effects, which is the main behavioral concern for a get-by-ID tool. It does not go further into error or auth behavior, but the operation itself is transparent.

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?

A single front-loaded sentence with no filler. The scope constraint ('single', 'by ID') appears immediately, and every word contributes to operational clarity.

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 one-parameter get-by-ID tool with an output schema available, the description is sufficient for an agent to select and invoke it correctly. No additional return-format or side-effect details are necessary.

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 covers 100% of the parameter: id is already documented as 'ID of the custom music model to retrieve.' The description only restates this as 'by ID' and adds no new semantic detail, 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?

The description names a specific verb (Retrieve), a concrete resource (custom music model), and a precise scope (a single one, by ID). This makes it easy to distinguish from sibling tools like suno_list_custom_models (many models) or suno_create_custom_model/suno_delete_custom_model.

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 by-ID phrasing implies the right usage context: you have an ID and want one model. However, the description gives no explicit guidance about when to choose this over list_custom_models or other siblings, and it does not state exclusions.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It describes the tool as returning a guide, which implies a safe, read-only operation, but does not explicitly state it has no side effects or is idempotent.

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 four sentences including the Returns line. It is front-loaded and clear, though it could be slightly more efficient without losing clarity.

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 simplicity of the tool (no parameters, has output schema), the description completely covers its purpose and return value. It explains the output format and benefits.

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 has zero parameters, so no parameter explanations are needed. The description adds value by explaining the return value: 'Complete guide with section markers, examples, and tips.' Baseline 4 is appropriate for a no-parameter tool.

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 provides guidance on formatting lyrics for Suno music generation, specifically with section markers. It is distinct from sibling tools like suno_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?

The description does not explicitly state when to use this tool versus alternatives. It is implied that it should be used before generating lyrics or custom music, but no explicit when-not-to-use or alternative guidance is 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?

No annotations are provided, so the description carries the full burden. It mentions the return type ('Task ID and MIDI data information'), but does not disclose whether the operation is synchronous or asynchronous, how long it might take, or any side effects. The callback_url parameter suggests async behavior, but this is not explained.

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 one-liner, an explanatory paragraph, a bullet list for usage, and a returns line. It is relatively concise, but the explanatory paragraph could be merged with the usage list. Every sentence earns its place, but some redundancy exists (e.g., converting to MIDI for DAWs is stated twice).

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 low complexity (2 params, no enums, simple return) and the presence of an output schema, the description is fairly complete. It covers purpose, usage scenarios, and return type. Minor gaps include lack of error/async handling details, but for a retrieval tool this is acceptable.

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 both parameters. The description adds 'song ID' for audio_id and 'MIDI data information' for the return, but does not meaningfully extend understanding beyond the schema's 'The song ID' and 'Webhook callback URL for asynchronous notifications.' 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?

The description clearly states 'Get MIDI data extracted from a generated song.' The verb 'Get' and resource 'MIDI data' are specific. Among 32 sibling tools, none duplicate this exact function (e.g., suno_get_wav, suno_get_mp4 are different formats), so it distinguishes well.

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 three explicit scenarios (editing melody in DAW, need note-level data, recreate with different instruments). It gives clear context for when to use, though it does not explicitly state when not to use or mention alternatives.

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 behavioral burden. It discloses that conversion to MP3 occurs and that a Task ID plus MP3 audio info are returned, but it does not explain asynchronous behavior or callback semantics despite callback_url being a parameter.

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?

Compact and well-organized with clear sections: what it does, when to use it, and what it returns. The wording is efficient and front-loaded with no filler.

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

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

With an output schema present and full parameter documentation, the description provides enough context for basic invocation and selection. The main missing element is an explicit note about the asynchronous task lifecycle, though 'Task ID' implicitly hints at it.

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

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

Schema description coverage is 100%, with both audio_id and callback_url already documented. The description adds no parameter-level meaning beyond the schema, 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?

Clearly states it gets/converts a generated song to MP3 format, with explicit compression and portability rationale. The format-specific focus distinguishes it from sibling tools like suno_get_wav, suno_get_mp4, and suno_get_midi.

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 concrete 'Use this when' list covering compressed audio needs, sharing, and smaller file sizes. It does not explicitly name sibling alternatives or exclusion cases, which is the only gap preventing 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 provided, so the description carries full burden. It explains the conversion to video and mentions the return type (Task ID and MP4 info). However, it does not disclose potential asynchronous behavior, processing time, or failure conditions, leaving some behavioral 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 concise, with a clear opening sentence, followed by bullet points for usage scenarios. Every sentence adds value, and the structure is front-loaded with the core action.

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 tool with one parameter and an output schema, the description adequately covers purpose, usage, and return type. It lacks details on potential constraints or async processing, but these are minor given the tool's simplicity.

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_id is already well-documented in the input schema, including its source. The description adds no additional semantic meaning beyond the schema, so a baseline score of 3 is appropriate given 100% schema coverage.

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 verb 'Get' and the resource 'MP4 video version of a generated song'. It differentiates from siblings like suno_get_wav and suno_get_midi by specifying the MP4 format, making the purpose 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?

Provides explicit 'Use this when:' bullet points listing three usage scenarios. Does not include when not to use or directly name alternatives, but the context is clear enough for an AI to select this tool for video needs.

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 excels: it documents task states, clarifies polling behavior, and explains the MCP's normalization of omitted success fields. This gives agents a detailed model of the tool's runtime behavior beyond the basic read/edit nature.

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 leading purpose sentence, 'Use this when' bullets, task state definitions, and a returns summary. It is front-loaded, scannable, and every sentence contributes value without 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 tool's simple polling nature and the presence of an output schema, the description covers all necessary context: when to use, states to expect, normalization behavior, and what results are returned. It fully equips an agent to correctly invoke and interpret the tool.

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 provides 100% parameter coverage and a detailed description of task_id, including its source from generation tools. The description adds minimal extra parameter nuance, mostly reiterating 'previous generation' and 'task_id' provenance, so it meets the baseline without significantly enhancing schema semantics.

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 ('Query') and resource ('a music generation task'), and clearly distinguishes it from sibling generation/composition tools by focusing on status polling and result retrieval. The opening line and subsequent details unambiguously identify the tool's function.

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 explicit 'Use this when' bullets covering polling and result retrieval, which gives clear contextual signals. However, it does not mention when not to use it or alternative tools (e.g., suno_get_tasks_batch for batch queries), so it lacks exclusionary guidance.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It adds meaningful context about how the MCP interprets response.success=true as complete and response.success=false as failed when the API omits its top-level state, which is useful beyond 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.

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

The description is well-structured with a purpose statement, usage bullets, a behavioral note, and a returns summary. However, the opening phrases are somewhat redundant: 'Query multiple...', 'Efficiently check...', and 'More efficient than...' all convey similar information.

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

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

This is a simple one-parameter query tool with an output schema, and the description covers the purpose, batching context, special status interpretation, and return content. It provides enough information for an agent to select and invoke the tool 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 coverage is 100% and the only parameter, task_ids, is already described with its purpose and maximum recommended batch size. The description adds little beyond what the schema provides, 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?

Description uses a specific verb and resource ('Query multiple music generation tasks') and clearly distinguishes this tool from the sibling suno_get_task by noting it is more efficient than calling the single-task version multiple times.

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 an explicit 'Use this when' section with concrete scenarios (multiple pending generations, several songs at once, tracking a batch) and names suno_get_task as the less efficient alternative. It does not explicitly state when not to use it, such as for a single task.

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 exist, so description carries full burden. Discloses that it returns word-level timing data, but does not specify the structure or format of the output. For a read-only tool, this is adequate but not thorough.

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

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

Concise, well-structured with a purpose statement, return description, bulleted use cases, and a 'Returns:' line. Every sentence is necessary and 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 simplicity (1 parameter, no nested objects, output schema present), the description covers purpose, usage, and return type adequately. Could mention prerequisites (song must be generated) but overall complete enough for an agent to decide.

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% (only audio_id). The description merely echoes the schema's parameter definition ('The song ID to get timing/subtitle data for.'), adding no additional semantic value beyond what's already documented.

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 'Get timing and subtitle data for a generated song.' Differentiates from siblings like suno_get_midi or suno_get_wav by focusing on timing/subtitle info.

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 explicit 'Use this when:' list (synchronized lyrics, karaoke, video editing), giving clear context. Lacks explicit when-not-to-use or alternative tool references, but the guidance is sufficient.

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 description carries full burden. It mentions conversion to WAV and file size/quality trade-off, but lacks details on prerequisites (e.g., song must be generated), whether the tool is asynchronous, or authentication requirements.

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?

Description is concise with a few sentences and bullet points. Every sentence adds value: main purpose, quality comparison, use cases, and return type. No fluff.

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 (2 params, output schema exists), the description is mostly complete. It explains return type and provides usage context. Could mention that the task might be asynchronous or require prior generation, but overall adequate.

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 baseline is 3. Description does not add meaning beyond the schema; it only mentions 'song ID' and 'webhook callback' which are already described in 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?

Description starts with 'Get the lossless WAV format of a generated song', specifying verb and resource. It clearly distinguishes from sibling tools like suno_get_midi and suno_get_mp4 by focusing on WAV format.

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?

Includes a 'Use this when:' list with three bullet points (lossless, highest quality, production processing), providing clear context. However, it does not explicitly exclude alternatives or mention when not to use this 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 provided, the description carries full transparency burden. The verb 'list' implies a safe, read-only operation, but the description does not explicitly state lack of side effects or dependencies. Adequate but not explicit.

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

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

Three sentences, front-loaded with purpose, followed by usage context and return description. 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?

For a simple listing tool, the description fully conveys purpose, usage, and output structure (categorized list). Given an output schema exists, further detail is unnecessary.

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 has no parameters (100% coverage). Description adds no parameter details, but baseline for zero parameters is 4. No additional meaning needed.

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 Suno API actions and corresponding tools. It distinguishes itself from sibling tools (specific action tools) by being a meta-level 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 positions the tool as a 'reference guide for understanding the full capabilities,' implying use for exploration. However, it does not explicitly state when to use it vs alternatives, though context makes it 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'List custom music models' and reveals nothing about pagination behavior, default sorting, whether archived or failed models are included by default, or the read-only nature of the operation. A tool with pagination parameters (limit/offset) and a status filter should at least mention how defaults behave.

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?

A single, front-loaded sentence with no filler. It states the action, resource, and scope efficiently. There is no redundant information, and the structure is appropriate for a simple list operation.

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 low complexity and the presence of an output schema, the description covers the core purpose, and the schema covers parameters. However, the complete absence of usage guidelines and behavioral context leaves the agent without enough information to decide when to invoke this tool over alternatives or to anticipate default filtering/pagination behavior. It is minimally viable but not 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 description coverage is 100%, with each parameter (limit, offset, status) already documented in the input schema. The tool description adds no additional parameter context, so the baseline of 3 applies. The schema adequately explains the parameters, but the description does not enhance them further.

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 identifies the verb ('List'), the resource ('custom music models'), and the scope ('for the current Suno application'). This distinguishes it from sibling tools like suno_list_models (which likely lists base models) and suno_get_custom_model (which retrieves a single model). The purpose is 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?

No guidance is provided on when to use this tool versus alternatives such as suno_get_custom_model, suno_list_models, or suno_generate_with_custom_model. The description simply states what it does without any context about prerequisites, selection criteria, or when another tool would be more appropriate.

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 carries full burden. Describes return as a table with version, limits, features. No hidden behaviors or side effects mentioned. Could clarify if results are cached, but still transparent.

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?

Starts with purpose, then provides a well-organized model comparison in bullet points. Informative without being verbose. 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 no parameters and output schema exists, the description fully covers what the tool does, what it returns (table of models), and why to use it. Complete for a list tool.

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?

Input schema has 0 parameters (100% schema coverage), so baseline is 4. Description adds no parameter info because none exist, which 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 'List all available Suno models and their capabilities,' with a specific verb and resource. It distinguishes from siblings like music generation tools by focusing on model listing.

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 states 'Use this to understand which model to choose for your music generation.' Provides a model comparison table with use case recommendations. Lacks explicit exclusion criteria, but not critical for a listing 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?

No annotations are provided, so the description must cover behavioral traits. It states that it returns all personas created with specific tools, implying a read-only operation. However, it does not disclose pagination behavior beyond what is in the schema, nor does it mention auth requirements or potential side effects. The description adds moderate value beyond 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.

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

The description is efficient with a concise statement, a bulleted usage list, and a returns section. Every sentence serves a purpose with no 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 tool's simplicity (list with 3 parameters) and presence of an output schema, the description adequately covers purpose, usage, and return format. It could have added a note about read-only status, but overall it is 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?

Schema description coverage is 100%, so the schema already documents all parameters. The description mentions user_id implicitly ('for the given user') and hints at pagination via limit and offset, but adds no new semantic meaning beyond the schema. 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?

The description clearly states 'List all saved artist personas for a user.' It uses a specific verb ('list') and resource ('personas'), and distinguishes these from sibling tools like suno_create_persona (create) and suno_delete_persona (delete).

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 explicitly lists three when-to-use scenarios, such as viewing all personas or finding a persona ID. It provides clear context but does not exclude cases where other tools might be more appropriate, like suno_generate_with_persona which consumes but does not list personas.

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 fully convey behavioral traits. It uses vague language ('intelligently combines', 'cohesive mashup') without disclosing specifics such as handling of section markers, ordering, or potential failures. The return line mentions 'Combined mashup lyrics' but lacks details on format or structure.

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 about 8 sentences long with a clear structure: function statement, use cases listed with bullet points, and a return line. However, it contains repetitive wording ('combines' appears three times) and could be more succinct without losing clarity.

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 (2 string parameters, no annotations) and the existence of an output schema, the description covers the key points: inputs, use cases, and output purpose. It does not need to detail return format as the output schema provides that. Slight improvement possible by explaining mashup strategy.

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%, with each parameter described as 'first/second set of lyrics... can be full song lyrics with section markers.' The tool description adds minimal value beyond restating that it takes two lyrics and combines them. Baseline 3 is appropriate as the schema does the heavy lifting.

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 'Generate mashup lyrics by combining two sets of lyrics' with a specific verb and resource. It distinguishes from siblings like suno_mashup_music (music mashup) and suno_generate_lyrics (single lyric generation) by focusing on blending two sets of 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?

The description includes a 'Use this when:' list with three explicit scenarios: blending two songs, creating mashup/medley, and seeking creative lyrical combinations. While it lacks explicit when-not-to-use instructions or alternative tool names, the context is clear and actionable.

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 indicates it creates a new output and mentions a task ID return, implying an asynchronous operation, but does not disclose potential side effects, rate limits, or permission requirements. Since no annotations are provided, more behavioral detail would be beneficial.

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 brief and well-organized, with a clear introduction, a differentiation note, bullet points for use cases, and a concise return statement. Every sentence contributes to the tool's understanding.

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 exists and the parameters are fully described, the description sufficiently covers the tool's function and expected return. It lacks some operational context (e.g., async behavior) but is otherwise complete for an agent.

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% and all parameters have descriptive properties. The description adds no extra meaning beyond the schema—the required prompt guidance and mashup_audio_ids details are already in 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 the tool creates a musical mashup by blending multiple songs, and explicitly differentiates from lyrics mashup (suno_mashup_lyrics). It also lists concrete use cases, making its 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?

Provides explicit guidance on when to use (blending songs musically, DJ-style mashups, combining melodies) and distinguishes from lyrics mashup. Does not mention disambiguation from concatenation (suno_concat_music), but the core use case is well-defined.

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 bears full burden for behavioral transparency. It describes input (rough style description) and output (optimized prompt) but does not disclose any side effects, authorization needs, rate limits, or limitations. The behavior is predictable as a simple transformation, but more detail on the optimization process would improve transparency.

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 purpose. It includes bullet points for usage and a return statement. The 'Returns:' section is slightly redundant but not harmful. Overall, it is well-structured and 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, output schema present), the description is complete. It covers the input, output, and usage context. No additional information is necessary for an agent to use this tool 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 coverage is 100% with one required parameter 'prompt'. The description adds meaningful examples (e.g., 'rock guitar', 'jazz smooth') that clarify acceptable input beyond the schema's description, which only says 'Style prompt words that need to be optimized.'

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 purpose: 'Optimize a music style description for better generation results.' It identifies the specific resource (style description) and action (optimize), and distinguishes it from sibling tools like suno_generate_custom_music by noting it refines prompts for better 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 description provides explicit use cases: vague style idea, better style prompts for suno_generate_custom_music, and style term suggestions. It does not explicitly state when not to use or list alternatives, but the use cases are clear enough for selection among 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?

No annotations provided, so description must cover behavioral traits. Describes the action and return value but lacks details on permission requirements, rate limits, or potential side effects. Adequate but not comprehensive.

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?

Description is concise and front-loaded with the main action. Includes helpful bullet points for usage scenarios. Could be slightly tighter, but generally well-structured.

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

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

For a tool with 5 parameters and an output schema, the description covers the core functionality, usage context, and return format. Missing some behavioral details, but overall complete enough for an AI agent to understand and invoke 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 provides 100% coverage with descriptions for each parameter. The description adds minimal extra context (e.g., metaphor of 'painting vocals'), but the schema already sufficiently defines each parameter. Baseline score 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?

Clearly states the tool adds AI-generated vocals to an uploaded instrumental audio file. Explains the term 'overpainting' and distinguishes from other tools like suno_extract_vocals and suno_underpainting.

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 three use cases with 'Use this when:' bullet points. Does not explicitly state when not to use, but context is clear given sibling tools.

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?

Annotations are absent, so the description carries the disclosure burden. It does mention the return value: 'Task ID and the remastered audio information,' indicating asynchronous behavior. However, it does not disclose side effects, credit usage, or whether the original audio is preserved. The description adds a bit of behavioral context but lacks depth typical for a mutation 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 concise and well-structured: an opening purpose statement, a short explanatory sentence, three 'Use this when' bullets, and a 'Returns' line. Every sentence serves a purpose without redundancy. It is front-loaded with the core action 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?

The tool has 4 parameters (2 required), an output schema, and enums for complex behavior. The description covers the primary use cases and explicitly notes the return type (Task ID and remastered audio info). It could mention the asynchronous nature more explicitly or clarify that it produces a new version, but given the output schema exists and parameters are well-documented, this 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 description coverage is 100%, so the schema fully documents all parameters (model, audio_id, callback_url, variation_category). The description does not elaborate on parameters beyond what the schema already provides, so the baseline of 3 is appropriate. It adds no extra semantic value 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 the tool's purpose: 'Remaster an existing song to improve audio quality.' It explicitly notes it 'Takes a previously generated song' which distinguishes it from generation, extension, cover, or concat tools. The verb 'Remaster' is specific and resource-focused.

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 explicit 'Use this when' scenarios: improving audio quality, upgrading older models, or achieving a polished production version. While it doesn't mention when not to use it or alternative tools, the given conditions offer strong contextual guidance. No explicit exclusions are provided, but the guidelines are clear enough for most cases.

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 disclosure burden. It discloses that only the selected time range is re-generated and that output is either two full songs or two unmerged clips. However, it doesn't clarify that this is likely an asynchronous task requiring task polling, nor what happens when optional parameters like lyric or style are omitted, nor any failure/rate-limit 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 front-loaded with the core action, uses scannable bullets for usage guidance, and closes with a Returns line. At roughly 80 words, it is well-sized with no filler; each section either defines scope, usage, or output in a structured way.

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

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

For an 8-parameter tool with an output schema and no annotations, the description covers the main behavior and output shape but omits important operational context: async workflow (polling get_task), constraints on section lengths, and defaults for omitted lyric/style. The output schema exists, so return field details aren't needed, but the async nature and edge-case behavior remain unclear.

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 adds minimal semantic value—'between the specified start and end times' reinforces the time parameters and 'two unmerged clips in candidates mode' restates replace_section_result_mode, but no genuinely new parameter meaning is introduced 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 states a specific operation—'Replace a specific time range in a song with new generated content'—with a clear verb, resource, and scope. It distinguishes the tool from siblings like extend, cover, and concat by explicitly emphasizing 'keeping the rest of the song unchanged.'

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 lists concrete triggers (e.g., 'A specific section of a song needs improvement', 'You want to change lyrics in the middle of a song'), giving clear context for when to invoke this tool. It does not explicitly name sibling alternatives or negative cases, but the conditions are specific enough to guide selection among the many generation/editing 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?

No annotations are provided, so description carries full burden. It states the tool adds samples (mutation) but doesn't disclose potential side effects, limitations, or prerequisites beyond uploading audio. Minimal behavioral context.

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?

Description is concise with two paragraphs and bullet points. Front-loaded with main action. Could be slightly more compact 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 5 parameters, output schema, and sibling variety, the description provides basic overview but lacks details on task retrieval, error cases, or how output can be used. Adequate but not comprehensive.

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 adds context about the time range but mostly restates schema info. No significant additional meaning 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 adds AI-generated samples to uploaded audio, using a specific verb and resource. It distinguishes itself from siblings like generation or concatenation 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?

The 'Use this when' bullet points provide explicit guidance on when to use the tool. It lacks explicit when-not-to-use or alternatives, but the listed use cases are helpful.

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 carries full burden. It describes the action (splits audio) and return format (Task ID and stem results with URLs), but does not disclose behavior like whether it is destructive, async nature (callback_url implies async), or any prerequisites.

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?

Description is front-loaded with purpose, then explains use cases, then returns. It is reasonably concise but could be slightly more streamlined by removing the redundant 'Separate a song' line.

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 low complexity (2 params, simple action, output schema exists), the description covers purpose, usage, and return format adequately. It is complete enough for an agent to use 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 coverage is 100%, so baseline 3. Description adds minimal value: it mentions return format but not parameter details. Schema already describes both parameters clearly.

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 stems (vocals and instruments). It specifies the resource (song) and the action (separate), and distinguishes from similar sibling tools like suno_extract_vocals by emphasizing multiple stems.

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

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

Provides explicit 'Use this when' list with three clear scenarios (separating vocals, needing stems, karaoke). However, it does not explicitly state when not to use or compare to alternatives like suno_extract_vocals.

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 fully convey behavioral traits. It mentions returning a Task ID (suggesting async operation) but does not disclose whether the original audio is modified, rate limits, failure modes, or authentication needs. This is insufficient for safe agent invocation.

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 well-structured: a brief explanation of the term, a bulleted usage list, and a return value summary. No unnecessary words or repetition.

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 parameter count (5), full schema coverage, and presence of an output schema, the description adequately explains the tool's operation and parameters. It does not cover prerequisites like user authorization or detailed output, but these are partially offset by the output schema.

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 adds useful context for audio_id (must be uploaded via suno_upload_audio) and constraints for underpainting_end (must be less than total duration). These modest additions keep the score at 3.

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 adds AI-generated accompaniment to uploaded audio, using specific verbs and explaining the term 'underpainting'. It references vocals and acapella, but does not explicitly differentiate from similar siblings like overpainting, leaving some ambiguity.

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 a bulleted list of when to use the tool (vocal recording, acapella, etc.) and implies prerequisites via the parameter description for audio_id. However, it lacks explicit when-not-to-use guidance and alternatives among sibling tools.

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 does disclose that enhanced mode returns a task_id for suno_get_task and that enhanced audio IDs unlock Cover/Samples/Mashup. However, it leaves other behavioral details (standard-mode result shape, ownership/authorization checks, cost, failure behavior) to the schema rather than the description. This is adequate but not thorough.

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

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

Four short sentences, front-loaded with the core purpose and then mode guidance. Every sentence adds distinct information with no filler.

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

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

The description covers the critical decision point (standard vs enhanced), the async task_id handoff, and downstream operation support. With a full input schema and an output schema available, the remaining unspecified details are minor; still, a brief note on specialized sibling tools would round it out.

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; the description adds no per-parameter semantics beyond the schema. It reinforces the mode distinction but doesn't explain how mode relates to name, audio_url, or callback_url beyond what the schema already states.

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 precise action and object ('Upload external audio') and adds its purpose ('for use in subsequent operations'). It also calls out enhanced mode's downstream coverage of Cover, Samples, and Mashup, which separates this generic upload tool from more specialized sibling 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?

Gives explicit routing between standard and enhanced modes and an explicit condition ('only when standard upload cannot process authorized audio'). It points the agent to suno_get_task for the async enhanced result. It does not explicitly contrast with sibling upload-specific tools such as suno_upload_extend or suno_upload_cover, so it loses the top score.

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 but lacks details on side effects, authentication, rate limits, or whether the operation is synchronous. It mentions returning a Task ID, which implies asynchrony, but does not explain polling or 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 concise with a clear structure: purpose, usage bullets, return value. It front-loads the main action and is efficient, though it 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 complexity of 5 parameters and an output schema, the description covers the basic purpose and return value. However, it lacks details on asynchronous behavior, error handling, or how to use the returned Task ID, making it not fully 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 input schema has 100% description coverage, so the description adds marginal value beyond the schema. It restates that audio_id must come from suno_upload_audio, but does not provide deeper semantics for other parameters.

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 creates an AI cover of uploaded audio, distinguishing it from the sibling tool suno_cover_music by specifying it works with audio uploaded via suno_upload_audio.

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 bullet points on when to use the tool, such as uploading your own music and wanting a cover in a different style. It also mentions similarity to suno_cover_music, but does not explicitly state 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.

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

The description states the return value (Task ID and extended audio info) but does not disclose behavioral nuances such as whether the original audio is modified, required permissions, or any side effects. With no annotations, more detail is needed.

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, with bullet points for usage scenarios. Some slight redundancy ('your own music' appears twice) keeps it from 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 the tool's purpose, differentiation, usage, and return. With a rich schema and output schema, it provides sufficient context for selection, though additional details about model options are left to schema.

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?

All parameters have descriptions in the schema (100% coverage), so the description does not need to repeat them. The description does not provide additional semantic context 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 the tool extends uploaded audio with AI-generated content and distinguishes it from the similar suno_extend_music by specifying it works only with audio uploaded via suno_upload_audio.

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 ('Use this when: ...') and mentions the alternative tool suno_extend_music, giving clear guidance on when to use this tool.

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