suno-mcp

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

With no annotations, the description carries the full behavioral burden. It does disclose that the tool returns a task id, status, and output URLs, which is useful since there is no output schema. But it omits critical async behavior, polling semantics (wait, timeout_ms, poll_interval_ms), callback handling, and permission or error characteristics.

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 sentences with no wasted words, and the core action is front-loaded. It is appropriately sized, though it could use slightly more specificity without becoming bloated.

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 annotations and no output schema, the description is too thin. It provides only a minimal return description and omits usage context, parameter interpretation, and behavioral details that an agent needs to 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 description coverage is 78%, which is high, so the schema already documents most parameters. The description adds no parameter meaning 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?

The description names a specific verb (Create) and resource (Suno task), with a parenthetical action label (add samples). However, it does not explain what adding samples actually does or distinguish the tool from other task-creating siblings such as convert_audio or 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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no conditions for selection. The description only states what the tool does, leaving the agent to infer usage from the tool name alone.

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 it does disclose the task-lifecycle model on return: 'task id, status, and result payload.' However, it omits material traits an agent needs for a generation call: cost/credit implications, authentication requirements, whether the task consumes quota, and how errors or terminal failures surface. Useful but incomplete.

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

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

Two short sentences, front-loaded with the primary action and followed by the return shape. Nothing is redundant, though the '(blend lyrics)' parenthetical duplicates the tool name and title 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?

There is no output schema, so the brief return-value sentence partially compensates, and the async task model is implied. But with six parameters, no annotations, and a sibling get_task that is the natural polling counterpart, the description should explain the wait/callback trade-off and terminal-status handling and does not.

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?

Six parameters with 67% schema coverage, and the description adds nothing about any of them. timeout_ms and poll_interval_ms are undocumented both in the schema and in the description, and the interaction between wait, poll_interval_ms, and callback_url is left entirely to inference.

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 Suno task that blends lyrics, and names the operation '(blend lyrics)'. This distinguishes it from create_mashup and text_to_music, which operate on audio rather than lyric text, though it does not explicitly name those siblings. The purpose is clear 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?

The description gives no when-to-use condition, no prerequisites, and no alternatives. An agent cannot tell from the text whether to prefer this over create_mashup, generate_lyrics, or inspire_music, nor when to supply a callback_url versus relying on the default wait/poll behavior.

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 behavioral burden. It mentions that the operation is synchronous and returns a result, which is useful, but it omits whether the operation mutates anything, what permissions or credits it requires, and whether it has any side effects or rate limits. For an external API operation, this is a significant gap.

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 sentences with no wasted words and is front-loaded with the operation type. However, its extreme brevity borders on under-specification rather than optimal conciseness.

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 crowded music-tool suite, no annotations, and no output schema, the description is not complete enough for reliable tool selection. It fails to explain what 'boost style' produces or how it differs from nearby tools like generate_lyrics or inspire_music. The parameter schema helps, but the overall definition leaves the agent with unresolved questions.

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 input schema already fully documents the single 'description' parameter, including its role in expanding a style into genre tags. The main description adds no additional parameter meaning beyond what the schema provides. Baseline 3 is appropriate when 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 a synchronous Suno operation called 'boost style,' but it does not explain what boosting a style actually does. The purpose is vague and does not distinguish this tool from the many other music-generation siblings. The parameter schema clarifies it expands a style description into genre tags, but the main description alone leaves the agent guessing.

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 guidance on when to use this tool versus alternatives. With 20 sibling tools for music tasks, the description provides no context, prerequisites, or routing information. It simply says to run the operation.

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 behavioral burden. 'Look up' implies a read-only, non-destructive operation, but the description does not mention permissions, rate limits, default behavior, or the kind of pricing information returned.

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. It is appropriately sized for a simple lookup tool.

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 low-complexity and the schema fully documents both optional parameters. However, with no annotations and no output schema, the description does not explain the return format or any auth requirements, leaving minor gaps for an agent invoking 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%, and both parameters are documented in the schema, including an enum for action and a default note for model. The description adds only the broad scope ('suno model line') and does not add syntax or selection guidance beyond the schema.

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

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

The description states a specific verb ('Look up'), resource ('RunAPI pricing'), and scope ('for the suno model line'). It clearly distinguishes this tool from the sibling generation and task-management tools, which do not cover pricing.

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 that the tool is for checking pricing, but it provides no explicit when-to-use guidance, prerequisites, or alternatives. With no sibling pricing tool, there are also no named alternatives to route against.

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 behavioral burden. It discloses the return shape (task id, status, output URLs) but does not state whether this is async, what permissions/credits are needed, what 'convert' actually does to the audio, or how failures surface. This is a significant gap for a task-creation/mutation tool.

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

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

Two short sentences, front-loaded with the action, and no wasted wording. It earns its length but is under-specified rather than overly verbose.

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 6-parameter task-creation tool with no annotations and no output schema, the description is too thin. It should clarify what conversion does, the async/polling contract, and distinguish itself from sibling audio transforms; the return-shape sentence is the only substantive content.

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 mentions none of the 6 parameters. Schema coverage is 67%, so the schema documents most inputs (wait, callback_url, source_task_id, source_audio_id), but roughly a third are undocumented and the description compensates for nothing. It adds no meaning 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?

It states a verb ('Create') and a resource ('Suno task on RunAPI') plus a parenthetical 'convert audio'. However, 'convert' is left undefined against siblings like cover_audio, remaster_audio, and separate_audio_stems, so an agent cannot tell what transformation this performs. The purpose is identifiable but genuinely 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 versus the many sibling audio tools (cover_audio, remaster_audio, separate_audio_stems, extend_music). No prerequisites or exclusions are stated. The agent must infer usage from the name alone.

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, yet it only says it returns a task id, status and output URLs. It does not disclose the asynchronous task lifecycle, the effect of the 'wait' polling flag, cost/credit implications, or whether an existing audio asset is consumed or a new one produced.

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, correctly front-loaded with the action before the return-value note. Nothing is redundant, though the second sentence is generic.

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 18-parameter, 2-required, annotation-free music generation tool with no output schema, the description omits the async/polling behavior, credential/API-key expectations, and any hint about which optional fields are mutually exclusive (lyrics vs prompt). It is far too thin for 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 89%, so the schema already documents nearly every parameter (upload_url, vocal_mode, weights, callback_url, etc.). The description adds no parameter meaning, 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 concrete verb+resource ('Create a Suno task... cover audio'), which is better than a tautology, but it never distinguishes this from sibling cover/transform tools like convert_audio, remaster_audio, or extend_music. An agent must infer the difference from the name alone.

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 when-to-use guidance, no prerequisite (for example that an upload_url must first be obtained), and no mention of any alternative tool. Among ~20 audio siblings, this leaves routing entirely 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 carries the full burden. It implies a task/async workflow and mentions the return fields, but says nothing about permissions, whether the created task is billed, what happens on failure, or how 'wait'/'timeout_ms'/'poll_interval_ms' change behavior. For a 17-parameter mutation tool 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?

Two short, front-loaded sentences with no filler; the purpose leads and the return shape follows. It is efficiently written, if a bit spare given 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?

A 17-parameter creation tool with no annotations and no output schema deserves more than naming three return fields. Nothing explains the required upload_url_list/vocal_mode relationship, polling behavior, or side effects, leaving meaningful 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 88%, so the schema already documents nearly all 17 parameters (including vocal_mode enum values). The description adds no parameter meaning beyond that, 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?

States a specific verb+resource ('Create a Suno task ... mashup') and identifies the underlying service (RunAPI), which distinguishes it from sibling audio tools like cover_audio or extend_music. It stops short of explicitly contrasting with those siblings, but 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 when-to-use guidance, no prerequisites, no exclusions, and no routing to alternatives among the many audio-mutation siblings (blend_lyrics, add_samples, stitch_audio). The agent must infer usage entirely from the name.

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 disclosure burden. It notes the return shape (task id, status, output URLs), which is useful since there is no output schema, but says nothing about asynchronous generation, the wait/polling behavior, cost, or auth, which matter for a 23-param generation task.

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, front-loaded sentences with no filler; the only weakness is that the parenthetical restates the tool name rather than adding 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 23-parameter music-generation tool with no annotations and no output schema, the description is thin: it covers the return payload but omits async/polling semantics and any usage framing. The rich schema compensates for most parameter gaps, keeping this at a minimum-viable 3.

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 91%, so the schema already documents nearly every parameter, including mutual exclusivity of prompt/lyrics and the source-vs-custom mode. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

The description states a verb and a loose resource ("Create a Suno task ... (extend music)"), but "extend music" largely restates the tool name and never explains what extending means (continuing a source track from a point) or how it differs from siblings like text_to_music or cover_audio.

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

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

There is no when-to-use guidance, no mention of choosing between source/custom parameter_mode as a decision, and no alternatives named among the many sibling generation tools. An agent must infer the entire usage context from the name and schema.

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

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

With no annotations, the description carries full burden, but it does usefully disclose the task-based async model and the return payload (task id, status, result). It says nothing about auth needs, rate limits, cost, or how the wait/poll parameters affect blocking 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?

Two short sentences, front-loaded with the action and followed by the return shape. No filler, though '(generate lyrics)' partially restates the tool name.

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?

Since there is no output schema, the description's mention of task id/status/result payload is valuable and fills that gap. However, for a 5-parameter async task tool with no annotations, it omits usage context, permissions, and behavioral details around polling/waiting.

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 60% (timeout_ms and poll_interval_ms are undocumented, prompt has only a placeholder description), and the description adds no parameter meaning whatsoever. It does not compensate for the gap as required at this coverage level.

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 (Create) and resource (Suno task for lyrics generation), so the agent knows this initiates a lyrics-generation job. It is distinguishable from sibling get_timestamped_lyrics (a fetch) and blend_lyrics (a merger), though it doesn't 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?

No when-to-use guidance is offered and no alternatives are named, despite several overlapping siblings (get_timestamped_lyrics, blend_lyrics, inspire_music). The agent is left to infer that this is the entry point for new lyrics.

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 mentions that the operation is synchronous and returns a result, but omits whether it consumes credits, requires authentication, creates persistent resources, or has other 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?

The description is two short sentences with no wasted words. It is front-loaded with the operation type, though it omits useful context that would make it more actionable.

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 generation tool with four required parameters, no annotations, and no output schema, the description is too sparse. It does not explain what the operation returns beyond 'operation result', when to choose it over siblings, or what a persona represents, leaving significant gaps for an agent.

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

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

The input schema has 100% description coverage, fully documenting all four required parameters (source_task_id, source_audio_id, name, description). The description adds no parameter details beyond what the schema already provides, 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 states a general verb and resource ('Run a synchronous Suno operation') and names the operation in parentheses, but the parenthetical merely restates the tool name. It does not explain what a 'persona' is, how it differs from siblings like generate_voice or inspire_music, or what source audio produces it.

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 given on when to use this tool versus alternatives such as generate_voice, cover_audio, or text_to_music. The description provides no prerequisites, context, or exclusions, leaving usage entirely 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 carries the full behavioral burden. It does disclose that the call is synchronous (blocking) and that it returns an operation result, which is modestly useful, but it omits auth/permission needs, latency or rate-limit expectations, and any failure behavior for a generation endpoint.

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 and free of padding, though the trailing "Returns the operation result" is near-vacuous given no output schema exists to describe.

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 no annotations and no output schema, the description should explain cloning behavior, required inputs, and expected outcome; instead it gives generic "synchronous operation" language. An agent lacks enough context to invoke this confidently versus its siblings.

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 only 2 parameters, so the schema already documents name and source_audio_url. The description adds no parameter meaning beyond that, which puts it at the baseline 3.

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

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

The description largely restates the tool name ("generate voice") and adds only provider boilerplate ("Suno operation on RunAPI"). It does not distinguish this from siblings like generate_persona or text_to_music, nor does it say the operation clones a voice from a supplied recording. An agent cannot tell what specifically this tool produces beyond the name.

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 when-to-use guidance and no mention of alternatives, despite several plausible siblings (generate_persona, text_to_music, inspire_music). It does not state that a public source audio URL is a prerequisite, which is the key selection criterion for 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 carries the full burden. It usefully discloses that the tool is a read-like fetch returning status and the latest result payload, but it omits authentication requirements, rate limits, error behavior, and whether the task may still be processing.

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, well-structured sentence that front-loads the action and resource. Every word earns its place with 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?

For a two-parameter retrieval tool with no output schema, the description mentions what is returned ('status and latest result payload') but does not explain the shape or meaning of that payload, nor does it cover polling or error semantics. It is minimally adequate but leaves notable gaps.

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

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

Schema description coverage is 100%, so the schema already documents both task_id and action. The description adds no parameter-level detail beyond the phrase 'suno task', making the baseline score of 3 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 states a specific verb ('Fetch') and resource ('current status and latest result payload for a suno task'), making the tool's purpose clear. It distinguishes itself from the action-creation siblings like convert_audio and text_to_music, 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?

The description gives no explicit when-to-use guidance, prerequisites, or alternatives. It does not explain that this tool should be called after creating an asynchronous task with one of the action endpoints, nor does it mention polling frequency or failure conditions.

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 behavioral burden. It discloses that the operation is synchronous and returns a result, which is useful, but it omits permissions, side effects, error behavior, credit consumption, and what the result actually contains.

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, front-loaded, and contains no redundant filler. Its compressed structure is appropriate, though the generic wrapper sentence contributes little beyond stating that a synchronous RunAPI operation is performed.

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?

There are no annotations and no output schema, so the description should do more to explain operational context and return behavior. It only says 'Returns the operation result,' which is too vague for an agent to understand what timestamped lyrics output will look like or how to use it reliably.

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 both parameters are already well documented in the input schema. The description adds no additional parameter meaning, syntax, or constraints, making the baseline score of 3 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 states a clear verb and resource: getting timestamped lyrics via a synchronous Suno operation on RunAPI. It is understandable on its own, but it does not differentiate this tool from siblings like generate_lyrics or blend_lyrics, leaving the agent to infer the distinction from the name alone.

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 no guidance on when to use this tool versus alternatives, no prerequisites, and no conditions for selecting it over other lyric-related or audio-related siblings. It only identifies the operation type, leaving usage entirely 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 provided, so the description carries the full burden. It discloses the return shape (task id, status, output URLs), which is genuinely useful, but says nothing about mutation side effects, the async/polling nature implied by the wait, timeout_ms, and poll_interval_ms parameters, callback behavior, or auth/rate-limit 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?

Two tight sentences that are front-loaded with the action and the backend, followed by the return values. The parenthetical '(inspire music)' is redundant with the name but costs little.

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?

A six-parameter mutation tool with no annotations and no output schema should do much more: it never explains that the call is asynchronous, how 'wait' interacts with timeout_ms/poll_interval_ms and callback_url, or when this model line is appropriate. The return-value sentence is the only substantive disclosure.

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 67%; timeout_ms and poll_interval_ms have no descriptions anywhere, and the description never compensates. The mention of 'inspire music' loosely hints that audio_urls guide generation but adds no format, count, or model-selection meaning 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?

States a specific verb (Create) and names the backing service (Suno task on RunAPI), plus what is returned (task id, status, output URLs). However, 'inspire music' merely echoes the tool name and never explains that the operation generates new music guided by input audio, so with ~20 sibling music-generation tools (text_to_music, cover_audio, extend_music) an agent cannot tell what distinguishes this one.

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 indication of when to use this tool versus text_to_music, cover_audio, extend_music, or any other sibling. No prerequisites, no note that it is async or that it requires audio inputs (only inferable from the schema).

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

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

With no annotations, the description carries the behavioral burden. It discloses the interactive browser flow and the file write side effect (config.json). However, it does not mention that it may overwrite existing credentials or that it could block waiting for user input, though these are implied.

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, well-structured sentence that front-loads the action ('Authenticate RunAPI') and provides necessary details 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 login tool with one optional parameter and no output schema, the description covers the core purpose and side effect. It lacks an explicit statement that this is a prerequisite for other tools, but that is implied.

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 only parameter 'force' has a description). The tool description adds no additional meaning about parameters beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states the tool's purpose with a specific verb ('Authenticate'), target resource ('RunAPI'), method ('browser PKCE login flow'), and side effect (saving to config.json). It is distinct from sibling tools, none of which relate to authentication.

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 usage (to authenticate RunAPI) but does not explicitly say when to run it (e.g., before other RunAPI tools) or when to use the 'force' parameter. Since there are no alternative auth tools among siblings, 'vs alternatives' is not applicable.

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 response shape (task id, status, output URLs), which is useful, but says nothing about the asynchronous task lifecycle implied by the 'wait' flag, polling defaults, timeouts, cost, or failure behavior for a mutation-style operation.

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

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

Two short, front-loaded sentences with zero filler. It is efficient, though the brevity comes at the cost of substantive guidance rather than being an example of tight writing about a complex tool.

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 8-parameter task-creation tool with no annotations and no output schema deserves more: async/polling behavior, timeout semantics, cost implications, and any source-task requirements are all absent. The description covers only the return fields.

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 75%, so most parameters are documented in the schema itself, and the description adds no parameter-level detail. Baseline 3 applies for a schema that largely 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 a specific verb and resource: create a remaster task on RunAPI for audio. 'Remaster' distinguishes it from siblings like convert_audio, cover_audio, and extend_music, though it never explicitly contrasts with them or with boost_style.

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

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

No when-to-use guidance is given. It never explains when remastering is preferable to convert_audio, cover_audio, or extend_music, nor does it mention preconditions such as the source task needing to be completed (that detail lives only in the schema).

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 states the tool returns a task id, status, and output URLs, which is useful, but omits that this is an async task-creation call, how polling/`wait` behaves, whether it costs credits, or any auth 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?

Two short sentences with the action and the return shape front-loaded; there is no filler. It is efficient, though terse to the point of under-informing.

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

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

For an 8-parameter, async task-creation tool with no annotations and no output schema, the description is thin. It never explains the relationship between task_id/audio_id inputs, the wait/callback_url/poll_interval_ms control trio, or what the returned task id is used for.

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 75%, so the schema already documents most parameters (including the large enum of stem_name values), making 3 the baseline. The description itself adds no parameter meaning; timeout_ms and poll_interval_ms remain undocumented 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 names a specific verb and resource ('Create a Suno task ... separate audio stems'), so an agent knows this initiates stem separation rather than conversion or remastering. It is clear but does not explicitly contrast itself with siblings like convert_audio or remaster_audio.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no routing to alternatives among the many audio siblings. The agent must infer that it needs an existing source task and audio to operate on.

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 says a task is created and returns task id, status, and output URLs, but omits side effects, authentication needs, async/polling behavior (wait, callback_url), cost, and reversibility.

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 sentences with purpose front-loaded and return values second. There is no filler, though the parenthetical phrasing is slightly terse.

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 7-parameter task-creation tool with no annotations and no output schema, the description is not complete enough. It mentions return fields but omits async behavior, parameter roles, and usage context.

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 71%, and the description adds no parameter meaning. It does not explain source_task_id, audio_id, model, timeout_ms, poll_interval_ms, or the wait/callback_url semantics beyond what the schema already says.

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 the verb 'Create' and resource 'Suno task' with the parenthetical '(stitch audio)', so the core operation is identifiable. It does not differentiate from siblings like convert_audio or create_mashup, leaving the intended scope somewhat ambiguous.

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 no when-to-use guidance, prerequisites, or alternatives. Usage is only implied by the tool name and the required source_task_id/audio_id parameters.

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 disclosure burden. It hints at an async task model by naming a returned task id and status, but never explains that wait defaults to true and triggers polling to a terminal state, nor describes timeout/poll_interval behavior, cost implications, or failure modes for what is clearly a long-running job.

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 the operation front-loaded and return values trailing, and every clause carries information. It is appropriately short, though given the tool's complexity the brevity edges toward under-specification rather than pure efficiency.

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 20-parameter, no-annotation, no-output-schema generation tool with an implicit async lifecycle. The description gives a one-line return summary but omits polling/wait semantics and any selection logic for the many mutually-influential fields (lyrics vs prompt vs vocal_mode), leaving meaningful gaps for an agent to fill.

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 90% across 20 parameters, so the schema already documents nearly everything, and per the rubric that establishes a baseline of 3. The description adds no parameter-level meaning beyond the schema (e.g., how lyrics conflicts with prompt under each vocal_mode), so it does not rise above baseline.

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 (Create) and resource (Suno task on RunAPI), plus a parenthetical that pins the modality (text to music), which distinguishes it from siblings like text_to_sound, cover_audio, or extend_music. It stops short of explicitly naming the sibling it should be chosen over, so it lands just below the top band.

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 guidance on when to use this versus text_to_sound, inspire_music, extend_music, or the other generation siblings, and no mention of prerequisites such as auth or how vocal_mode drives the request. The agent must infer routing entirely from the tool name.

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 behavioral burden. It discloses the return shape (task id, status, output URLs) but says nothing about credit/cost implications, whether the call blocks, failure behavior, or what the required prompt must contain beyond the schema's 500-char note.

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 compact sentences with the action front-loaded and zero filler. It is arguably too spare for a 10-parameter generation tool, but nothing is wasted.

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 10-param tool with no annotations and no output schema, the description is thin. It partially covers returns, but leaves async/sync behavior (wait, poll_interval_ms, timeout_ms), model selection, and the text_to_music distinction entirely to inference.

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 80%, so the schema already documents prompt, sound_key, sound_loop, tempo, callback_url, wait, and polling. The description adds no parameter meaning beyond that, so the 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 gives a specific verb+resource ('Create a Suno task ... text to sound') and even names the backend, so the basic action is unambiguous. However, it does nothing to distinguish this from the near-identical sibling 'text_to_music' (nor 'inspire_music'), leaving an agent without a rule for choosing between 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. Given a sibling named text_to_music, the absence of any disambiguation is a conspicuous gap.

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 correctly signals an async task model by saying it returns a task id and status, but it omits cost/credit implications, whether the operation is idempotent or destructive, and how the wait/callback mechanisms interact. For an 8-parameter async generation tool 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?

Two compact sentences with the action front-loaded and no filler. Minor redundancy in 'on RunAPI (visualize music)', but overall efficient.

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

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

With 8 parameters, no annotations, and no output schema, the description should explain the async lifecycle and the source_audio_id/source_task_id pairing. It partially compensates by naming return fields (task id, status, output URLs), but leaves too much of the calling contract implicit.

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 75%, so the schema documents most parameters itself. The description adds nothing beyond the schema about wait, timeout_ms, poll_interval_ms, callback_url, or the source_task_id/source_audio_id relationship, 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?

States a verb ('Create') and names the operation ('visualize music') plus the provider (Suno on RunAPI), but 'visualize music' is opaque about what actually gets produced — a music video from source audio? The description does not differentiate this from siblings like cover_audio, remaster_audio, or text_to_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 when-to-use guidance, no statement of prerequisites (e.g., that a source_audio_id from a prior task is required), and no mention of alternatives among the ~20 sibling music tools. The agent must infer placement from the name alone.

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