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

With no annotations at all, the description carries the full burden, and it only discloses that the operation is asynchronous via the polling hint. It says nothing about cost, whether the source audio is modified or a new asset is created, or what the task handle looks like, all of which matter for a generation call with 13 parameters.

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, front-loaded with the action and followed by the polling instruction. Nothing is wasted, though the terseness leaves the parameter surface entirely unexplained.

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 13-parameter async generation tool with zero annotation coverage, the description is far too thin; an output schema exists so return values need not be explained, but the optional tuning parameters and cost/pricing implications are left completely unaddressed.

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 only 15%, so the description must compensate, and it barely does: 'selected instrument or voice stem' implies stem_type and 'existing audio' implies audio_id. The other eleven parameters (model, style, prompt, variety, max_mode, weirdness, audio_weight, callback_url, negative_tags, style_influence, title) get no mention at all.

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

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

States a specific verb and resource: generate a chosen instrument or voice stem for an existing audio. That is clear enough to act on, but it never distinguishes itself from siblings like suno_extract_stem, suno_stems_music, or suno_all_stems_music, which sound closely related.

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 'Poll suno_get_task' line gives the agent the follow-up workflow, which is genuinely useful. However, there is no guidance on when to pick this over suno_extract_stem or the all-stems variant, nor any stated prerequisites beyond needing an existing audio.

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 does disclose that the operation is asynchronous and returns a task ID requiring polling — the single most important behavioral fact. It omits whether the original asset is modified or a new one created, permission requirements, and how callback_url interacts with polling.

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 tight sentences with no filler; the core action comes first and the async polling note follows. Nothing wasted, nothing buried.

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?

An output schema exists so return values need not be described, and the polling behavior is covered. But for a 5-parameter mutation tool with zero annotations and thin schema coverage, the description leaves too much (callback behavior, audio_id expectations, whether output is a new asset) unaddressed.

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 only 20% (only title documented), so the description must compensate. 'Optionally preserving pitch' usefully explains keep_pitch, but speed_multiplier's 0.25–4 range, audio_id's role, and callback_url's semantics are left entirely to 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?

Names a specific verb+resource (adjust audio playback speed) plus a meaningful option (preserving pitch). It is clearly distinguishable from the generation-oriented siblings, though it never explicitly contrasts itself with e.g. suno_remaster_music or suno_extend_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 line 'Poll the returned task ID' gives a real procedural cue for async usage, but there is no guidance on when to choose this tool versus neighboring audio-transform tools, nor any prerequisites or 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?

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?

With no annotations, the description carries the full burden and does so well: it discloses synchronous behavior, the limited meaning of available=true, that unknown availability raises an error rather than returning false, API-token requirements, and zero current Credit cost. These are meaningful operational details 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 compact and front-loaded, moving from purpose to behavioral caveats to operational requirements without wasted text. Every sentence contributes useful 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 one-parameter availability check with a complete input schema and an output schema, the description supplies the behavioral and operational context an agent needs. Return-value details are appropriately left to 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?

The schema already fully documents the single audio_id parameter, including that it is a completed song UUID and not a task_id. The description adds no parameter-specific details, so the baseline of 3 is appropriate given 100% schema description 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 states a specific verb and resource: checking current-channel audio availability synchronously. It is clear what the tool does, though it does not explicitly differentiate itself from any sibling tool.

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

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

Usage is implied by the availability-check framing and the note that success only reports available=true, but there is no explicit when-to-use guidance or comparison to alternatives. The synchronous nature and caveat provide some context, but exclusions are absent.

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?

With no annotations provided, the description carries most of the behavioral burden. It usefully states that the tool generates a new version while keeping core melody and lyrics, and that it returns a Task ID and cover audio information. However, it does not clarify asynchronous task handling, whether the original audio is left unchanged, permission requirements, or how the task ID should be used afterward.

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 purpose and structured with a useful 'Use this when' list. It is reasonably concise, though the first two sentences overlap by both explaining the different-style cover concept.

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 full schema coverage and an existing output schema, the description provides enough context to understand the tool's intent, common use cases, and return shape. The main remaining gap is sibling differentiation, especially versus remaster, mashup, upload_cover, and other generation/editing tools.

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 all seven parameters, including audio_id, style, prompt, persona_id, and callback_url, are already well documented in the schema. The description does not add parameter-specific meaning beyond the schema and mainly describes the overall cover/remix concept.

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

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

The description states a specific verb and resource: create a cover or remix version of an existing song in a different style. It also clarifies that the new version changes arrangement, genre, or mood while keeping core melody and lyrics. It does not explicitly differentiate from similar siblings such as suno_remaster_music, suno_mashup_music, or suno_upload_cover.

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?

It includes a clear 'Use this when' section with three concrete scenarios: hearing a song in a different genre, making an acoustic version, or remixing with a different vibe. This gives strong positive guidance, though it does not state when not to use it or name alternative 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 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 exist, so the description carries the full behavioral burden. It signals an async task model ('Returns: Task ID') and describes the continuation semantics as adding new sections, but omits whether the source song is preserved or altered, whether credits are consumed per attempt, and how failures surface. The callback_url async behaviour lives only in 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?

Front-loaded with the core action in the first line, then scoped by a short bullet list and a pointer to the follow-up tool. The trailing 'Returns' block is largely redundant given the output schema, which costs it a point.

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, return values need not be spelled out, and the description still covers purpose, trigger conditions, and the downstream merge step. The main remaining gap is any mention of prerequisites such as needing a previously generated unfinished or extendable audio_id.

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 lyric, model, style, audio_id, continue_at and callback_url in detail. The description restates the core idea of continuing from a timestamp but adds no format or constraint detail beyond the schema, so 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?

Names a specific verb (extend) and resource (an existing song) plus the key scoping concept — a specific timestamp — and adds new lyrics. This is clearly distinguishable from sibling operations like suno_replace_section, suno_upload_extend, and suno_concat_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 'Use this when' block gives three explicit triggering scenarios (song too short, adding bridge/outro, building a longer song piece by piece) and routes the agent forward to suno_concat_music for merging. It doesn't state when NOT to use it — e.g. versus suno_replace_section for editing existing audio or suno_upload_extend for uploaded source audio — so a sibling-boundary gap remains.

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. The only real disclosure is that two artifacts are returned and both should be kept; it says nothing about async behavior (callback_url), model selection effects, cost, or whether the source audio is modified or left intact.

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 the action front-loaded and no filler. The second sentence is a useful operating instruction rather than padding, though the terseness contributes to the under-specification elsewhere.

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 output schema exists, so return values needn't be explained, and "preserve both returned pairs" is a nice hint. But for a 5-parameter, no-annotation, job-style tool with 0% parameter documentation, the description is far too thin to let an agent invoke it confidently.

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 0% across 5 parameters, so the description must compensate and does not: audio_id, model, audio_format, and callback_url are never mentioned. Only "selected stem" loosely maps to stem_type, and even the 12 enum values are left to 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?

It states a verb ("Extract") and a resource ("a selected stem"), so the basic action is inferable. However, "its complementary remainder" and "Preserve both returned pairs" are unusual phrasings that leave the actual operation ambiguous, and nothing distinguishes this from nearby siblings like suno_extract_vocals, suno_stems_music, or suno_all_stems_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?

There is no explicit when-to-use guidance, no prerequisites (e.g. audio must already exist / be processed), and no mention of the alternative stem-extraction tools an agent must choose between. The agent must guess which of the several stem-related siblings to call.

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 must carry the full behavioral burden. It reveals that the call returns a Task ID (implying asynchronous job flow) and lists what comes back, but it says nothing about cost/pricing tiers (only the schema mentions max_mode pricing), polling, or the fact that the tool produces a new artifact with no destructive side effects.

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

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

Front-loaded purpose sentence, a tight bulleted usage list, the sibling redirect, and a return summary. Well sized for 16 parameters; the bullet list mildly duplicates the schema's own descriptions but never buries the key routing 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?

The output schema and full param coverage mean the description needn't explain fields, and it correctly covers purpose and routing. However, for a 16-param async generation tool with no annotations, it omits how to follow up on the Task ID and the lyric-vs-lyric_prompt vs instrumental precedence, which an agent needs to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents every one of the 16 parameters thoroughly. The description only restates the lyric/duration/vocal_gender behaviors that the schema spells out in more detail, adding no new semantics such as how lyric_prompt interacts with instrumental mode.

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

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

States a specific verb and resource ('Generate AI music') and names the distinguishing mode: full control over lyrics, title, and style (Custom Mode). The contrast with the plain generation sibling is made explicit, so an agent can route without opening the schema.

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?

An explicit 'Use this when' list enumerates the selecting conditions (own lyrics, precise style control, title, vocal gender, lyric_prompt, duration) and closes with the direct alternative: use suno_generate_music for quick generation without lyrics. When-to-use and when-not-to-use are both present.

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 and does add real behavioral context: it discloses that generation is asynchronous (returns a Task ID), and warns that well-known catalog recordings may be rejected by Suno's copyright check — a failure mode an agent could not infer from the schema. It omits cost/credit implications and processing-time expectations, keeping it short of a 5.

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?

Front-loaded with the core action, then the cover contrast, then a scannable 'Use this when' list, then returns. Slightly padded — the parenthetical dual-language name and a returns block that duplicates output-schema content are low-value — but no sentence is confusing or out of order.

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 12-param generation tool whose parameters are fully documented in schema and which has an output schema, the description supplies what structured fields cannot: the inspo-vs-cover distinction, async task semantics, and the copyright rejection caveat. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so every parameter is already documented, including the audio_urls copyright tip and audio_weight semantics. The description only echoes the 1-4 reference-audio limit and mentions prompt/style tags generically, adding no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('Generate brand-new music inspired by 1 to 4 reference audios') and immediately delimits it against the nearest sibling concept: 'Unlike a cover, inspo does not reproduce the source tracks.' An agent can distinguish this from suno_cover_music and suno_generate_music without opening either schema.

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?

An explicit 'Use this when' block names two concrete selection conditions (reference tracks to riff on; 'in the style of' requests) and the cover contrast functions as an exclusion. It does not name sibling tools directly or say when to prefer suno_generate_music / suno_upload_extend instead, so routing is clear but not exhaustive.

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?

No annotations are provided, so the description carries the full burden. It does disclose key behavior beyond the schema (Suno auto-generates lyrics, melody, style, arrangement) and that a task ID plus audio URLs are returned, but it never explains the asynchronous lifecycle (poll via suno_get_task vs. callback_url), credit cost, or failure 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?

Front-loaded with the core verb and mode, then a scannable 'Use this when' list and a single alternative pointer. The 'Returns:' block partially duplicates the existing output schema, which is minor waste.

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?

An output schema exists and parameter coverage is complete, so the description need only supply purpose, routing, and creative-behavior context, which it does. The main remaining gap is the async task/polling workflow, which an agent would need in order to act on the returned task ID.

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 all six parameters (model, prompt, variety, callback_url, instrumental, variation_category) are documented in the schema with examples and defaults. The description adds no parameter-level guidance, so the baseline 3 applies.

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

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

States a specific verb and resource ('Generate AI music from a text prompt') and names the Inspiration Mode, which distinguishes it from the custom-music path. However, the sibling suno_generate_inspo is not addressed, leaving some ambiguity about which 'inspiration' flavor this is.

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 (quick generation, no lyrics in mind, wants Suno to be creative) and routes the agent to suno_generate_custom_music for full control. This is exactly the when/when-not/alternative structure.

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 the description carries the full burden, yet it says nothing about this being an asynchronous generation job, what callback_url does, whether results must be polled via suno_get_task, cost, or rate limits. It discloses only that bpm/key are optional guides.

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, front-loaded with the core action, with no filler. Brevity comes at the cost of coverage rather than from trimming 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?

An output schema exists, so return values need not be explained, but with 7 parameters, 14% schema coverage, and no annotations, an agent still lacks guidance on model selection, output format, and asynchronous delivery. Incomplete for a tool of this complexity.

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 only 14% (just the 'sound' field), so the description must compensate. It mentions bpm, key, and the one-shot/loop choice but leaves the 10-value model enum, audio_format, and callback_url completely unexplained.

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

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

States a specific verb and resource ('Create a ... sound effect') and immediately scopes it to the two sound types. It is clearly distinct from the many music-generation siblings, though it does not explicitly name them.

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 never says when to pick this over suno_generate_music, suno_generate_inspo, or suno_generate_custom_music, nor any prerequisites. The only implied guidance is the one-shot vs loop distinction, which is already the sound_type enum.

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 genuinely carries the load: it discloses that the call is asynchronous and returns a task ID, that completion must be polled via suno_get_task, that success must be checked via response.success, and that there is no fallback to another model. It omits cost/credit or permission implications of a generation call, which keeps it short of a 5.

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 compact sentences, each front-loaded with an actionable fact: what it does, how to confirm the async result, and the no-fallback constraint. No filler and nothing buried.

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 12-parameter generation tool with an output schema and high schema coverage, the description supplies what structured fields cannot: the async task lifecycle and the no-fallback trait. It stops short only on prerequisites for obtaining a 'ready' model ID and any cost implication.

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 high (83%), so the schema already documents id, lyric, instrumental, callback_url, lyric_prompt and others, making a baseline of 3 appropriate. The description's only added meaning is the instrumental/automatic-lyrics dichotomy; the undocumented params (weirdness, style_influence) are left unexplained in both places.

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

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

The description states a specific verb and resource: generate audio using a ready custom model, with instrumental or automatic lyrics. This is clear but does not explicitly distinguish itself from the similarly named siblings suno_generate_custom_music and suno_generate_music, so the reader must infer that 'custom model' means a model object rather than 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?

It gives a concrete post-call workflow (poll suno_get_task until finished_at is set, inspect response.success) and a useful non-behavior ('never falls back to another model'). However, it never states when to prefer this over suno_generate_music or suno_generate_custom_music, or what prerequisite produces a 'ready' model ID.

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 declared, so the description carries the full burden of behavioral disclosure. It does reveal that the operation is an async-style generation that returns a Task ID and applies the persona's voice, and that it re-uses a previously created persona. It omits behavior details such as credit usage, how long tasks run, failure modes if the persona is invalid, or whether the reference audio is mixed -- are significant gaps for a music generation API with zero annotation support.

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 purpose is front-loaded and the 'Use this when' lists plus the prerequisite note come early, so an agent gets the gist quickly. Only minor redundancy: the second paragraph ('This allows you to maintain a consistent voice...') restates the lead sentence about consistent vocal style. The overall length is still justifiable and well-bulleted.

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 stipulates the workflow, the intended use, and the async Task/audio return, while an output schema exists to cover return values in a structured way. The noteworthy missing part is distinguishing this from the nearest sibling, suno_generate_with_persona_vox, and no mention of authenticity or quota effects. Since no annotations are present, the description should have compensated for these gaps a bit more sharply.

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 even with no additional parameter description. The text does add a workflow note ('use its ID from suno_create_persona') but that is already present in the schema's persona_id description. It adds no semantic value beyond the structured input.

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 lead sentence names a specific verb ('Generate music'), a specific resource ('a saved artist persona'), and the benefit ('consistent vocal style'). It clearly differentiates this generation-flavored tool from the many non-generative siblings while establishing how it relates to the prerequisite suno_create_persona. Distinguishes the intended flow with confidence.

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' bulleted list covering the three main use cases, plus a clear upstream instruction to create the persona first with suno_create_persona. It does not spell out when NOT to use this tool still, e.g., choosing suno_generate_music awkward or persona_vox, so some guidance left is to inference.

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 the underlying action (artist_consistency_vox), its optimization for vocal consistency, that it is stricter than the sibling, and that it returns a Task ID and generated audio information. This gives the agent a solid understanding of behavior and expected output.

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

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

The description is well-structured with a front-loaded purpose, clear bullet points for usage, and a brief returns note. Every sentence earns its place without redundancy.

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

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

Given 5 parameters, an output schema, and no annotations, the description covers purpose, usage conditions, prerequisites, and return type comprehensively. It provides everything an agent needs to decide when to call it and what to expect.

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 schema already documents every parameter. The description adds value by explaining the persona_id prerequisite (create persona via suno_create_persona or suno_create_voice) and by implying the vocal consistency context, but it does not add meaning to audio_id, model, or callback_url 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?

The description clearly states the tool's verb ('Generate music'), resource ('saved artist persona with VOX-specific consistency'), and explicitly differentiates it from the sibling suno_generate_with_persona by mentioning the artist_consistency_vox action and stricter vocal consistency. This is specific and 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' bullets listing concrete conditions (multiple songs, stricter vocal consistency, specific voice persona), names the alternative (suno_generate_with_persona), and gives a prerequisite (create persona first). This is thorough guidance that leaves no ambiguity about when to select 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, 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 are provided, so the description carries the full burden. It discloses the return format (a table) and the scope (all available models). It also lists model comparisons with limits and durations, which is useful context for agent behavior. Does not mention any side effects (it's a read operation), but since nothing suggests otherwiseton, it's adequately 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?

The description is structured with a clear intro, a list of model comparisons, and a return-value note. It is front-loaded with the purpose and includes a helpful bulleted list. It is a bit longer than necessary, but every part contributes to decision-making. No filler or 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 (zero params), the description covers everything an agent needs: what it does, what it returns, and model-specific details to aid selection. The output schema exists, which further covers returns. No missing critical information.

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

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

The tool has zero parameters, so the description doesn't need to explain params. The baseline for zero params is 4, and the description exceeds the baseline by adding useful model details that an agent might need. Schema coverage is 100% trivially, but the description adds value by providing model-specific context.

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 lists all available Suno models and their capabilities, which distinguishes it from generation and other tools. It provides a specific verb and resource, making the purpose unmistakable.

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

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

The description says 'Use this to understand which model to choose for your music generation,' giving clear context but not explicit when-not-to-use or alternatives. It implies usage before generation tasks but doesn't mention alternative info sources like suno_list_custom_models.

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?

With no annotations, the description carries the full burden and does well: it discloses async task semantics (accepted task_id, finished_at, response.success), the candidate-vs-committed distinction, stale-version conflict detection, and the idempotency/duplicate-billing risk of changing keys. It stops short of stating which actions are destructive (remove_track, replace_section, render) or what permissions are needed, so it is not fully complete.

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 action inventory is front-loaded in the first sentence and the remaining sentences each carry a distinct operational rule (units, candidate/commit, ID preservation, polling, timeout). It is dense but earns its length for a ten-action tool, with only minor redundancy between the version_id rule here and in the schema.

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?

An output schema exists, so return values need not be explained, and the description covers the async polling loop, candidate lifecycle, and retry policy that the schema cannot express. What remains missing is a per-action indication of destructive versus read-only behavior and any mention of prerequisites such as required audio/render IDs before generate_track, which matters for a tool spanning this many mutations.

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?

At 50% schema coverage the description must compensate, and it adds real meaning: seconds describe source audio while beats describe the project timeline, and version_id must be the latest from retrieve. The nested action-specific fields (model enums, stem_control_tags, render_audio_id) are documented in the schema but not reinforced in the description, leaving partial reliance on 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 opens with a concrete enumeration of the ten operations this tool performs (create, retrieve, save, upload, add/generate/replace tracks, commit, remove, render), so the agent knows exactly what resource and verb set it covers. However, it never distinguishes itself from siblings that overlap, notably suno_replace_section and suno_add_stem, which an agent could easily confuse with this tool's replace_section and add_track actions.

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?

Strong workflow guidance: use the latest version_id for mutations, generation only produces candidates while commit_candidate adds one, poll accepted task_id with suno_get_task until finished_at, and on timeout retry the SAME request/key rather than regenerating. The one gap is that it never states when to choose this tool over the similarly-named sibling suno_replace_section, so sibling-level routing is left to inference.

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?

Since no annotations are provided, the description must carry the full burden of behavioral disclosure. It mentions it returns a Task ID and mashup audio information, which is useful. However, it does not disclose that the operation creates new audio (a creative generation action), whether it consumes credits, or any other behavioral traits. The asynchronous nature is implied by Task ID but not fully explained. The description is adequate but not rich.

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

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

The description is relatively concise, using bullet points and a short returns section. The main purpose is front-loaded. However, the 'Returns' section is redundant with the output schema (which exists per context signals), and the 'Use this when' section could be more compact. Still, it is efficient and easy to scan.

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

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

Given the tool's moderate complexity (7 parameters, but only 2 required) and the presence of an output schema, the description covers the essential purpose and usage scenarios. The required parameter 'mashup_audio_ids' is clearly constrained to exactly two audios in the schema, and the description mentions 'multiple songs'. The only missing element is a mention of any prerequisites (e.g., the audio IDs must come from previously generated songs), but this is not critical.

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%, meaning every parameter is described in the schema. The tool description adds some context for the 'prompt' parameter by describing it as 'creative direction for blending the tracks', which adds meaning beyond the schema's generic description. However, most parameters like 'model', 'style', 'title', 'instrumental', and 'callback_url' are already well-documented in the schema, so the description adds limited additional value.

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

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

The description clearly states the tool's function: creating a musical mashup by blending multiple songs together. It explicitly distinguishes itself from 'lyrics mashup' by specifying it blends the actual audio, which is crucial given the sibling tool suno_mashup_lyrics. The use of specific verb 'create', resource (musical mashup), and clear distinction from alternatives makes the purpose highly clear.

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 'Use this when' list with three specific scenarios: blending two or more songs musically, creating DJ-style mashups, and combining melodies from different songs. It also implicitly differentiates from lyrics mashup by mentioning the difference. However, it does not explicitly state when NOT to use it or directly reference the alternative suno_mashup_lyrics by name, which would be more complete.

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 are provided, so the description carries the burden. It discloses that the tool is asynchronous (returns a Task ID) and that it modifies/creates audio with vocals. However, it doesn't mention that the operation is non-destructive to the original upload, whether it consumes credits, or any rate limits. The async nature is disclosed via 'Returns: Task ID', which is useful but minimal.

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 summary, use-case bullets, and a returns section. It's slightly longer than necessary—the 'overpainting = painting vocals over the music' parenthetical is helpful but could be trimmed. Overall, every section earns its place and the key info is front-loaded.

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

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

The description covers the core purpose, use cases, and return value (Task ID). It doesn't explain polling or callback behavior in detail, but the output schema and parameter descriptions cover the mechanics. For a tool with 5 params and an output schema, this is reasonably complete, though it could mention that the result is delivered asynchronously via task polling.

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 5 parameters. The description adds context for audio_id ('uploaded instrumental track') and explains the overpainting concept, but doesn't add detail beyond the schema for model, callback_url, or the start/end times. Baseline 3 is appropriate since 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 clearly states the tool's function: adding AI-generated vocals to an uploaded instrumental track. It uses a specific verb ('add'), names the resource ('uploaded instrumental audio'), and explains the metaphor ('overpainting = painting vocals over the music'). This distinguishes it from siblings like suno_underpainting and suno_extract_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?

The description provides explicit use cases ('when you have an instrumental track and want to add vocals', 'want to give background music a singing voice', 'need to add vocal melody to existing music'). It doesn't explicitly state when NOT to use it or name alternative tools, but the use-case list gives clear context for when this tool is 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?

With no annotations, the description is the sole source of behavioral context. It discloses that existing audio is remastered and the result is a Task ID and remastered audio info, hinting at async behavior. However, it omits whether the original audio is preserved, permission/rate-limiting implications, or mechanism for retrieving the result, so transparency is partial.

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

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

The description is well-structured with an opening statement, explicit use-case bullets, and a return-format note. However, the first two sentences are slightly redundant ('Remaster... to improve audio quality' vs 'Takes... applies... to enhance clarity, dynamics, and overall sound quality'), which prevents a perfect score.

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

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

Given the full schema coverage, an output schema, and a moderately simple operation, this description is complete for an agent to decide when to use it and what to expect. It covers the purpose, variants/by-products, and indicates an asynchronous task flow via the returned Task ID; no critical context is missing.

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 4 parameters are fully described in the schema (100% coverage), including the enum values and the meaning of audio_id. The description adds no new parameter-level meaning; it only reinforces the existing schema, so the baseline of 3 is appropriate.

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

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

The description uses the specific verb 'Remaster' with resource 'an existing song' and clearly states the purpose: improving audio quality. It distinguishes the tool from siblings like suno_generate_music or suno_cover_music by scoping it to a previously generated song, leaving no ambiguity about what action it performs.