RaoMusic

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond the annotations — that the call is 'Free' (no credit cost) — but says nothing about auth requirements, rate limits, or freshness of the returned numbers.

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?

Extremely tight: two short fragments that front-load the 'Free' cost signal ahead of the returned-data list. Nothing is padded, though the fragmentary style offers no structural aids like a purpose clause.

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 input parameters and no output schema, the description carries the burden of explaining what comes back and does so by enumerating the four returned fields. It is complete enough for a simple status read, missing only auth/format details.

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 takes zero parameters, so the baseline of 4 applies; there are no parameter semantics to clarify. The description correctly implies a parameterless status read.

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 resource and enumerates the exact data returned: credit balance, subscription status, in-flight generations, and the key's daily credit cap. It's a specific account-status read, but it never distinguishes itself from the sibling estimate_credits, which concerns a closely related credit concept.

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 routing away from the sibling estimate_credits, which an agent could plausibly confuse with an account-credit tool. The 'Free' prefix is a cost cue, not usage guidance, so the agent is left to infer the context entirely.

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

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

Annotations only assert readOnlyHint=true, and the description meaningfully extends that: no charge occurs, parameters are validated, the exact cost is returned, and specific failure modes are surfaced (subscription required, model offline, concurrent job limit, invalid params, daily cap). This is substantive behavioral context beyond the safety hint.

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, zero filler, with the most decision-relevant fact (free, non-charging) front-loaded before the secondary benefit of rejection reporting.

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 a nested params object whose schema lives in list_models and the absence of an output schema, the description does the important work of saying what comes back (exact credit cost plus rejection reasons). It does not describe the response shape in detail, a minor gap for an estimation tool.

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

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

Schema description coverage is 100%, so model, mode, params, and version are already documented in the schema, including the pointer to list_models for mode-specific params. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb and resource (estimate credit cost) plus the crucial distinguishing trait: it is a free dry run that validates without charging. The added note about reporting rejection reasons separates it cleanly from siblings like generate_music and check_account.

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 'free dry run ... without charging' framing makes the intended pre-flight use clear, and listing rejection causes implies it precedes an actual generation. It never names generate_music as the alternative to run after a successful estimate, nor states when not to use it, so it stops short of explicit routing.

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

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

Annotations cover idempotency and open-world reach, but the description adds the crucial behavioral facts they don't: it spends credits from the wallet, requires user confirmation, and returns asynchronously with a generationId rather than the finished artifact.

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

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

Three sentences, front-loaded with the cost warning, each carrying a distinct operational fact (cost/consent, mode choice, async return). No filler.

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

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

Despite no output schema, the description explains the return shape (generationId) and the polling path via get_generation, and covers the consent/credit prerequisite — everything needed to invoke and follow through.

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

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

Schema description coverage is 100%, so all five parameters (including the mode enum and idempotencyKey semantics) are already documented. The description only echoes the sound_effect mode, adding no parameter detail beyond the schema — 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?

States a specific verb and resource ('Generates a song, or a sound effect with mode "sound_effect"') and references related siblings (estimate_credits, get_generation), so an agent can place it in the workflow 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?

Gives an explicit precondition ('State the price from estimate_credits and get the user's confirmation before calling') and the follow-up action ('poll get_generation for results'), naming both alternative tools and when they apply.

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?

readOnlyHint already declares it safe, but the description adds value beyond annotations: it is 'Free' (cost behavior), requires polling at ~10s cadence, and terminates at 'completed'/'failed'. Return format is only implied, not stated.

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 'Free' cost signal followed immediately by scope and the polling instruction. No wasted words.

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

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

For a polling tool with no output schema and a fully documented single parameter, the description covers cost, cadence and terminal states. It omits the full set of non-terminal statuses an agent might observe, which is a minor gap.

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

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

Schema coverage is 100% and the id description already explains it accepts a generationId or any song id from the batch, so the description adds no syntax or format detail. Baseline 3 applies 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?

States a specific resource ('Status and results of one generation') with clarifying scope ('all songs of the batch'), which lets an agent distinguish it from generate_music (creates) and list_songs (lists). It lacks an explicit verb and never names a sibling, so it falls short of a 5.

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

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

Gives concrete operational guidance: poll every ~10s and stop at 'completed' or 'failed'. This tells the agent how and when to call it, but there is no explicit comparison to alternatives such as list_songs for retrieving results.

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?

readOnlyHint=true already tells the agent this is a safe read with no side effects, and 'Free.' usefully adds that no credits are consumed. Beyond that the description discloses nothing about pagination, ordering, auth requirements, or result size, so it is adequate but thin for the annotation-lowered bar.

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

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

A single dense sentence with the most decision-relevant fact ('Free.') front-loaded and no wasted words. It is slightly list-like and lacks a verb, but every token carries 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?

With no output schema, the description carries the burden of explaining what comes back; it does enumerate the returned fields well, which is the strongest part of the definition. Still missing are the practicalities an agent needs before calling — result ordering/size, and how the returned model identifiers feed into generate_music.

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 takes zero parameters, so per the rubric the baseline is 4. The mention of 'per-mode parameter JSON schemas' describes returned payload structure rather than inputs, and adds no input semantics because none exist.

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 name plus the phrase 'Music engines with versions, credit prices, subscription requirements, songs per run, supported modes' makes clear this enumerates the available music models and their metadata. It is distinguishable from siblings like estimate_credits or generate_music. However, the description is a noun fragment with no explicit verb, so it relies on the tool name to signal the listing 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 only usage-oriented signal is the leading 'Free.', which implies the call costs nothing, but there is no statement of when to call this vs. estimate_credits or generate_music, and no prerequisites or exclusions. An agent must infer that this is the discovery step before generation.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds real behavioral context beyond that: the operation is free and results are ordered newest-first. It omits pagination and filtering behavior, keeping this at a solid but not rich 3.

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 telegraphic fragments with no waste; the cost attribute is front-loaded and the ordering constraint follows. Slightly clipped style costs it nothing but doesn't earn a 5.

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?

Adequate for a simple read-only list tool with no output schema, since annotations carry the safety profile and the schema carries parameter types. However, the description gives no indication that results can be filtered by generation status, which is a meaningful gap for an agent hunting pending or failed songs.

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% for two parameters, and the description never mentions 'limit' or 'status'. 'Most recent songs' only loosely gestures at the default ordering/limit behavior, so the status enum — the one parameter an agent most needs explained — is entirely undocumented.

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 clear verb-resource pair (list the user's songs) with scope qualifiers: 'most recent' and 'newest first'. That distinguishes it from generate_music and get_generation, though no sibling is named explicitly.

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 or when-not-to-use guidance; nothing tells the agent how this relates to get_generation or when the status filter should be applied. 'Free' is a cost hint but not a selection rule.

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