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

No annotations exist, so the description carries the behavioral disclosure burden. It adds two useful facts: 'Costs credits' (financial/monetary consequence) and 'Returns task_id' (implies asynchronous execution). However, it stops short of telling the agent what to do with the task_id (e.g., poll suno_wait/suno_poll), and it does not disclose failure/refund behavior or that credits are consumed even on failure. It adds some value but leaves the async contract half-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?

Four terse sentences, each adding a distinct fact (purpose, personaId, credits, return type). The structure is efficient and front-loaded. However, for a 14-parameter tool with no annotations, this level of brevity crosses from conciseness into under-specification; important workflow and parameter information is omitted in the name of shortness.

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 high complexity (14 params, 1 required, no output schema, no annotations), the description is materially incomplete. It explains the purpose and the task_id return but does not establish the end-to-end flow (upload → cover → poll → download), document the meaning of most parameters, or clarify credit consumption semantics. An agent would need to consult sibling schemas or guess to invoke 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?

With schema description coverage at only 21% (only audioWeight, styleWeight, and weirdnessConstraint are described), the description must compensate for 11 undocumented parameters. It only adds meaning for personaId ('supports personaId') and loosely maps 'uploaded source' to uploadUrl. The semantics of model, customMode, negativeTags, vocalGender, instrumental, and personaModel are left entirely unexplained, so agents will have to guess at their values.

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 ('cover generation from an uploaded source') that distinguishes it from siblings like suno_generate (text-to-music) and suno_extend (extending existing audio). The term 'cover' plus 'uploaded source' gives agents enough to select it over alternatives. It could be slightly more explicit about what 'cover' means, but it is not tautological or vague.

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 on when to use this tool versus alternatives is provided. The description does not mention the prerequisite that uploadUrl must be obtained from suno_upload, nor does it route the agent to suno_poll/suno_tasks after receiving the task_id. The schema hints at the suno_upload dependency, but the description itself offers no usage context, leaving the agent to infer the workflow.

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 discloses that the operation is free and does not consume credits, which is important for cost-sensitive selection. It could mention output format or auth, but the zero-parameter, read-only nature keeps the need 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 two short phrases with no wasted words. It front-loads the core meaning ('Current credit balance') and then adds the valuable triage context in the second phrase.

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 zero-parameter, no-output-schema tool, the description is nearly complete: it states what the tool reports and why it should be used. The only minor gap is not specifying the return type or format, but that is low risk for a simple balance check.

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 and the description adds no parameter details, which is appropriate. With zero parameters, the description cannot be expected to explain parameter behavior, so a baseline of 4 is fair.

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 resource ('credit balance') and the purpose ('402/433 triage'), which separates it from generation and upload siblings. It lacks an explicit verb like 'get' or 'check', but the meaning 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?

The description gives a specific when-to-use context: free, no-credit check for triaging 402/433 errors. It does not explicitly name alternatives or exclusions, but the use case is clear enough for an agent to select it appropriately.

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

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

With no annotations provided, the description carries the full burden and does meaningful work: it warns about browser-UA usage to avoid Cloudflare 403s and describes a sha256 collision check tied to a CDN race. It does not disclose return format or file destination, but the disclosed behaviors go well beyond a generic 'downloads a task' statement.

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 a single dense sentence that front-loads the core purpose before adding the two most important caveats. It contains no filler; every clause adds 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 description covers purpose, timing, cost, and defensive behavior, but leaves parameter meanings and return/output details unexplained. Without an output schema or annotations, an agent may know why to call it but not fully know what it receives back or how destination handling works.

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%, so the description needed to compensate, but it never names or explains taskId, hint, or destDir. The only implicit hint is that 'task' corresponds to taskId; hint and destDir are entirely absent from the description.

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

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

The description clearly states a specific action ('Download all takes of a finished task') and names the resource (takes from a Suno task). It is distinct from generation/upload/task-listing siblings, though it does not explicitly differentiate itself from suno_download_url.

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 clear temporal condition ('finished task') and notes the operation is free, but it does not say when to use this tool instead of suno_download_url or other download-related alternatives. The guidance is present but mostly implicit.

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

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

No annotations are present, so the description carries the full burden. It only adds 'browser-UA' which is ambiguous and doesn't disclose permissions, rate limits, side effects, or whether the action is read-only. For a download operation, the description gives almost no behavioral insight beyond the action itself.

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 very short and front-loaded, which is good, but it is under-specified for a tool with three parameters and several siblings. It is not bloated, but it omits critical details, so while concise, it is not appropriately sized for the tool's complexity.

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 3 parameters, no annotations, no output schema, and a large sibling set, the description is incomplete. It doesn't explain return values, file destinations, or how this tool differs from suno_download. An agent would need to inspect the schema or guess to use it effectively.

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%, and the description says nothing about url, hint, or destDir. Although the parameter names are self-explanatory, the description adds zero semantic value over the schema. The malformed schema types ('single asset URL to download') are not reliable descriptions, so this falls to the description, which fails.

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 clear action (Download) and resource (single asset URL), with a hint about browser-UA. It is not a tautology and gives a basic sense of what the tool does, though the 'browser-UA' fragment is cryptic. It doesn't explicitly contrast with suno_download, but 'single' suggests this tool is scoped to one asset.

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 instead of siblings like suno_download, suno_tasks, or suno_generate. There are no preconditions, no exclusions, and no hints about selectability. The agent must infer usage from the name and the single sentence.

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 of behavioral disclosure. It states that the operation costs credits, returns a task_id, and imposes constraints (model must match source version, all custom fields required in custom mode). It also reveals the inheritance behavior when custom fields are omitted. This covers the most consequential behaviors, though it does not describe failure modes or whether the original take is modified.

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 dense sentences with no filler. It front-loads the purpose and then packs mode rules, requirements, and cost into the second sentence. While not formatted as bullet points, it is efficient and every clause adds value.

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

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

For a tool with 16 parameters and two modes, the description covers the essential usage context: purpose, mode selection, required parameters per mode, cost, and return value. It does not explain every parameter's meaning, but that is partially the schema's role (though schema is weak). The description provides enough for an agent to call the tool correctly in most scenarios.

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

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

Schema description coverage is only 19%, so the description must compensate for undocumented parameters. It explains the critical mode logic (inherit vs. custom) and the relationship between prompt/style/title/continueAt, and clarifies that audioId and model are the minimum for inherit mode. However, many parameters (personaId, vocalGender, negativeTags, etc.) remain unexplained in both the description and schema, leaving gaps for an agent.

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 'Extend an existing Suno task's take (generate/extend)', which identifies the verb, resource, and operation. It distinguishes from siblings like suno_generate (new generation) and suno_cover (cover) by specifying it operates on an existing task's take, and the phrase 'generate/extend' clarifies the action.

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

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

The description gives explicit instructions on when to use the tool and how to configure it: omitting custom fields inherits source parameters, while custom mode requires all of prompt+style+title+continueAt. It also notes the model must match the source model version in custom mode. While it doesn't explicitly name alternative tools for non-extend use cases, the context is clear enough for an agent to decide when to use this vs. other Suno 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 provided, the description carries the full burden of behavioral disclosure. It transparently states that credits are charged immediately (~12 for V6), that a task_id is returned, that one task produces 2 takes, and that downstream polling handles two different result shapes. This is strong behavioral coverage, though it omits details like failure modes or rate limits.

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 three dense, purposeful sentences with no filler. It front-loads the main action, then provides cost, return value, a critical usage warning, and downstream integration guidance. Every clause earns its place.

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

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

Given 13 optional parameters, no output schema, and no annotations, the description is not complete enough. It explains the task_id and polling workflow, but an agent still lacks guidance on how to fill the many generation parameters, what combinations are valid, and what a successful response looks like beyond the 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 only 23%, so the description must compensate by explaining parameters. It does not: it only mentions 'V6' as a model context, but does not clarify how to use prompt, style, title, personaId, customMode, audioWeight, or the other 13 parameters. Almost no parameter-level guidance is added beyond the schema.

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

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

The description clearly states the tool's core purpose: 'Submit text-to-music (Suno)'. It names a specific verb (submit) and resource (text-to-music), and the context of Suno generation distinguishes it from siblings like suno_cover or suno_extend, though it does not explicitly name those alternatives.

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 useful usage context: it tells the agent that one task yields 2 takes, warns not to submit twice for options, and directs them to suno_poll/suno_wait for result parsing. This gives clear operational guidance, though it does not explicitly discuss when to prefer this tool over sibling generation 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 burden of behavioral disclosure. It states the tool is free and describes the informational content, but it does not explicitly confirm that it is read-only, non-destructive, or describe any limitations or failure modes. The content implies a safe query, but the disclosure is thin.

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 extremely concise and front-loaded, listing the key content fields in one compact sentence. The extra 'Free.' adds meaningful cost information without adding bulk.

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 zero-argument info tool with no output schema, the description gives a reasonable outline of what the tool returns, but it does not specify the response format, exact field names, or value types. It is adequate for a basic understanding but leaves some ambiguity about what the agent will actually receive.

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 there are no parameter semantics to explain. The baseline of 4 applies, and the input schema already confirms an empty object with additionalProperties false.

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 tool as a server self-description and lists the specific information it provides: provider, default model, download dir, and available providers. It is distinguishable from sibling action tools like suno_generate or suno_download, though it does not explicitly name an alternative.

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 guidance on when to use this tool versus sibling tools. The intended use is only implied by the term 'self-description'; no conditions, prerequisites, or alternatives are mentioned.

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 transparency burden and does so well: it discloses the non-obvious re-call behavior (same taskId+audioId returns the same personaId and overwrites name+description) and warns to always send the full intended description. It also reveals the credit cost, a side-effect an agent could otherwise miss.

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

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

Four sentences pack in the core definition, source requirement, credit cost, idempotency behavior, and a protective instruction with no filler. The critical warnings are front-loaded and every sentence earns its place.

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

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

For an 11-parameter mutation tool with no annotations and no output schema, the description covers the required precondition, credit cost, and the most important side-effect (overwriting name+description). It does not explain the optional vocalStart/vocalEnd parameters or the response shape, but those gaps are minor next to the non-obvious re-call trap it exposes.

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 supplies semantics for several parameters such as audioWeight, styleWeight, and weirdnessConstraint, and the description adds crucial context about the taskId+audioId identity pair and the load-bearing description field. However, with only 27% schema description coverage, vocalStart and vocalEnd remain underdocumented and the narrative only partially compensates.

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 action ('create a persona') and the required source ('a SUCCESSFUL task's take'), making its role in the Suno workflow unambiguous. It clearly separates persona creation from the generation and cover siblings in the tool list.

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 concrete invocation constraints: only use with successful tasks, and it explicitly warns that credits are consumed. It does not name alternative tools, but no sibling provides persona creation, so the context is sufficient for selection.

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

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

With no annotations, the description discloses several useful behaviors: it parses resultJson, gates on terminal status and non-empty audio, warns instead of tempting re-submission, and is free. However, it does not state whether the call is read-only, what the return value contains, or any error/rate-limit behavior. It gives more than a bare description but leaves significant 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 three short sentences and front-loads the core purpose. However, 'V6-aware' and 'Free' are telegraphic fragments that may confuse agents. It is concise but not optimally structured.

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

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

Given the tool has one parameter, no annotations, and no output schema, the description should explain the return value and how to interpret the gate/warn behavior. It mentions 'gates' and 'warns' but does not specify what the agent receives or what to do with the result. The meaning of 'Free' is also minimal. For a simple polling tool, this is incomplete.

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 only parameter, taskId, receives no additional meaning from the description. The schema provides a malformed type string instead of a description, and context shows 0% coverage. The description merely mentions 'task' without explaining how to obtain a valid ID, its format, or its source. This fails to compensate for the schema gap.

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 ('Check') and resource ('task'), and clarifies it as 'record-info'. This distinguishes it from siblings like suno_tasks (likely listing tasks) and suno_wait (waiting). The additional behavior about parsing resultJson and gating on terminal status adds specificity, though 'V6-aware' is unexplained jargon.

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 compare to alternatives. It implies usage after a generation call ('task id from any generation call' appears in the schema property, and it mentions warning against re-submission), but never states when to use this over suno_wait or suno_info. No exclusions or conditions are provided.

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

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

No annotations are provided, so the description carries the full burden. It mentions the tool 'summarize[s] poll status' and is 'free', but does not disclose what the summary contains, whether it handles errors per task, rate limits, or the nature of the return value. For a polling tool with no annotations, this is thin.

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 a single, front-loaded sentence that states the core action and batch benefit, with 'free' as a useful extra. It is concise and efficient, though slightly terse; a bit more context on what 'summarize' returns would not hurt.

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 polling tool, the description is minimally adequate: it tells the agent what to pass and what the tool does. However, with no output schema and no annotations, it leaves the return shape and failure behavior unspecified, which an agent would need for robust use.

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%: the only parameter, task_ids, is already described as 'task ids to poll'. The description adds no new parameter-specific semantics beyond framing them as a batch ('list... in one call'), 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 clearly states a specific verb ('Summarize') and resource ('poll status for a list of task ids'), and 'in one call' distinguishes it from single-task polling. It could more explicitly contrast with siblings like suno_poll, but the intent is 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 phrase 'in one call' implies use when you have multiple task ids to batch-poll, and '(free)' hints at a cost advantage. However, there is no explicit when-to-use/when-not-to-use guidance or named alternatives, leaving the agent to infer when this beats suno_poll or suno_wait.

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

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

With no annotations provided, the description carries the full burden. It discloses the upload destination, that it is free, its prerequisite nature, and a specific failure mode for third-party URLs. It does not describe the return value or auth requirements, but covers key behavioral context.

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

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

The description is a single, front-loaded sentence with no wasted words. Every clause adds distinct value: purpose, prerequisite, sibling routing, failure mode, and cost.

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

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

For a tool with 4 parameters, no output schema, and no annotations, the description gives excellent sequencing context but omits what the upload returns and how that result should be passed to suno_cover or suno_upload_extend. It also does not clarify which input parameter to use in which scenario.

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% and the description provides no guidance on choosing between fileName, filePath, fileBase64, or uploadPath. Although the schema's type fields contain some partial information, the description does not compensate for the low coverage, leaving parameter usage ambiguous.

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 ('Upload an MP3 to the kie.ai CDN') and names its role as the required first step before suno_cover or suno_upload_extend. This clearly differentiates it from sibling tools.

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

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

It explicitly specifies when to use this tool ('Required first step before suno_cover or suno_upload_extend') and warns that third-party URLs fail with 'File fetch failed'. This gives the agent direct, actionable routing guidance.

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

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

Discloses that the operation costs credits, returns a task_id, and requires the model to match the source version. However, with no annotations, it fails to state that this is a write/mutation operation, that it is asynchronous, or any failure/side-effect 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?

Four sentences, front-loaded with the core purpose, then specific requirements. No redundancy; every sentence adds necessary detail.

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

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

For a 9-parameter tool with no output schema and no annotations, the description is incomplete: it omits async behavior, error handling, full parameter semantics, and explicit guidance on how to poll the returned task_id (e.g., via suno_tasks).

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%, so the description must compensate for all 9 parameters. It explains continueAt constraints and defaultParamFlag mode combinations, but leaves vocalGender, model, style, title, instrumental, and uploadUrl essentially unexplained beyond their raw schema types.

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 ('extend') and resource ('uploaded audio'), and the phrase 'upload-extend' differentiates it from sibling tools like suno_extend. The scope is unambiguous and immediately 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?

No mention of when to use this tool vs alternatives like suno_extend or suno_upload. The description only explains internal modes via defaultParamFlag, not selection criteria 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?

With no annotations, the description carries the burden and discloses key behaviors: it blocks, polls by default every 12s, has a 900s maximum, and returns final status plus audio URLs. It does not cover timeout-after-max or error behavior, but the core operational traits are specified.

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 blocking behavior, with no filler. Every word earns its place.

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

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

For a 3-parameter tool with no annotations or output schema, it covers action, timing, and return value, but it leaves important operational gaps: what 'terminal' statuses are allowed, what happens if the 900s max is reached, and how this relates to sibling tools like suno_poll. Overall adequate but with clear gaps.

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

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

The description adds useful timing constraints (default 12s poll, 900s max) that map to timeoutSeconds/intervalSeconds, but it never names the parameters explicitly or explains taskId beyond what the schema's weak 'task id from any generation call' hint provides. With 0% schema description coverage, this is partial compensation.

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

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

Description states a specific action ('Block until a task is terminal') and names the output, so the core purpose is unambiguous. However, it never distinguishes this from suno_poll, a likely sibling alternative, so an agent must infer the difference.

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

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

The description implies the tool is for waiting on an existing task, but it does not explicitly say when to use it versus suno_poll or other task-related tools, nor mention any exclusions or prerequisites. Usage context is only implied.

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