Neume

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

Annotations already flag destructiveHint=true, readOnlyHint=false, but the description adds material context beyond them: it costs 1 credit, it creates a new song while keeping the original, the part is re-sung in the same voice, and MCP App hosts render a progress card that then plays the result. It also fronts the get_song_parts prerequisite and the user-consent gate.

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 long sentences that are front-loaded with the core action and then the workflow and side effects; almost every clause carries distinct information (scope, duration, credit cost, consent gate, UI behavior). Slightly dense, but nothing is padding.

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

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

An output schema exists, so return values need not be explained. The description covers cost, side effects, prerequisites, and host UI, which is sufficient for a 6-parameter mutation tool. It omits that from_line/to_line allow changing only a sub-range of a part rather than the whole part, a minor but real 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 description coverage is 100%, so all six parameters including from_line/to_line and the consent flag little_kept_ok are already documented in the schema. The description adds the workflow hint that 'part' comes from get_song_parts and the 5–30 second duration bound, but no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Change the words of one part of one of their songs') plus the scope constraint (a part 5–30 seconds long, same voice) and what is preserved (rest of the song stays as it is). An agent can distinguish this from generate_remix or reimagine_song without opening any 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 ordered workflow: call get_song_parts first to find the part, write the new lines with the user, and only invoke once they agree. It does not name the sibling alternatives (reimagine_song, generate_remix) or say when changing lyrics is the wrong choice, so it stops short of full when/when-not 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?

Annotations already flag the write/destructive profile, but the description adds material facts the annotations cannot convey: the 2-credit cost, the guarantee that the source song is preserved alongside the new one, and the social precondition of agreeing on style first. The 'keeps the original' phrasing sits in mild tension with destructiveHint=true (which likely refers to irreversible credit spend), but this is not a direct contradiction.

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?

Everything is packed into a single sentence with the routing information ('prefer reimagine_song') front-loaded where an agent will see it first. No filler sentences; only minor awkwardness from compressing four distinct facts into one line.

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

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

With an output schema present, return values need not be explained, and the description covers cost, source-song preservation, and the routing decision. It is nearly complete for a two-parameter generative tool; only the minor destructive/credit framing tension leaves a small 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 both parameters carry their own descriptions, so the schema already does the heavy lifting. The description restates that prompt holds the target style and songId identifies one of the user's songs but adds no format, constraint, or example 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 states a concrete action on a concrete resource: it makes one of the user's existing songs again in a new style, with new words, and keeps the original. It also distinguishes itself from the sibling reimagine_song by declaring the relationship. It loses a point because the purpose is partly defined by reference to another tool rather than standing on its own.

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 names the preferred alternative (reimagine_song) and the precondition ('agree the style with them first'), so an agent knows both when to pick this tool and when not to. This is exactly the when/when-not/alternative guidance the dimension asks for.

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?

Beyond the annotations, it discloses the 1-credit cost, the asynchronous nature of the job, host-dependent MCP Apps progress-card behavior, and the fallback polling path with the songId. These are exactly the operational traits an agent needs and that structured fields do not carry.

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

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

Front-loads purpose and cost, then the lyrics workflow, then polling behavior. Efficient, but the sentences are long and densely packed with conditional clauses, which slightly hurts scannability.

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

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

Covers cost, approval workflow, async progress handling and the polling fallback, and an output schema exists so return values need not be described. Nothing needed to invoke or manage the call correctly is missing.

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

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

Schema description coverage is 100%, so title, style and lyrics are already fully documented. The description restates the lyrics-omission semantics (instrumental) but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Make a new song') plus the exact inputs (title, style, lyrics) and the conditional scope (no lyrics makes an instrumental). An agent can distinguish this from generate_remix/reimagine_song without opening any 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 workflow: write the lyrics yourself with part tags unless the user supplied words or wants an instrumental, show them, and only generate once approved. It also states when to poll (get_song_details) versus when the host handles progress, so both branches are covered.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description does add meaningful context about what the balance is composed of (subscription + topup credits), but says nothing about currency units, staleness, or auth requirements, so with annotations carrying the burden a 3 is appropriate.

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 well-formed sentence with the resource and its composition front-loaded and zero filler. Nothing wasted and nothing buried.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety semantics. For a zero-parameter read tool the description is essentially sufficient; only the absence of any when-to-use framing against the neighbouring credit tools keeps it short of a 5.

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

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

The tool takes zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly adds no parameter noise.

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 (get) and resource (credit balance) and clarifies the scope by enumerating that it includes both subscription and topup credits. This partial compositeness helps distinguish it from purchase_credits, list_subscription_plans and list_topup_packages, though it never names those siblings 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?

Usage is only implied: an agent can infer this is the read tool for checking available credits, but there is no explicit when-to-use statement, no mention of prerequisites, and no routing hints toward the related siblings (list_subscription_plans, list_topup_packages, purchase_credits).

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, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds two useful traits beyond that: results are ordered newest first and paginated, plus a note about MCP Apps hosts rendering a playable list. It doesn't cover rate limits or total-count behavior, so it is a modest add rather than rich 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?

Two short sentences, zero waste, with the resource and ordering front-loaded and the UI note last. Every sentence contributes distinct 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 rich annotations and an output schema, the description only needs to orient the agent, and it does: what is listed, ordering, and pagination. The only minor gap is not clarifying what happens with out-of-range pages, which is low stakes for a read-only list.

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 both page and limit are documented in the schema with defaults and bounds. The description only signals that pagination exists without adding format or semantics beyond the schema, so baseline 3 applies.

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

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

"List the songs you have made" gives a specific verb and resource with a clear ownership scope, which separates it from detail-oriented siblings like get_song_details and from creation tools like generate_song. It stops short of explicitly naming any sibling, so it lands at 4 rather than 5.

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

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

The ownership scope ("you have made") implies when to use it, but there is no explicit guidance on when to prefer get_song_details, get_song_parts, or other retrieval siblings. Usage is inferable rather than stated.

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, destructiveHint=false, and openWorldHint=false. The description adds useful behavioral context beyond annotations: it lists what the response contains, notes the audio link is short-lived, and explains how MCP Apps hosts render the result as a card with a player and synced lyrics.

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 tight sentences, front-loads the core purpose and returned fields, and then adds the host-rendering detail without repetition or waste.

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

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

For a simple read-only retrieval tool with one required parameter, full schema coverage, annotations covering safety, and an output schema already present, the description provides enough context. It explains the returned content and host rendering behavior without needing to restate the output schema.

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

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

Schema description coverage is 100%, and the sole parameter 'songId' is clearly documented as 'Song ID to fetch details for'. The description does not add any further semantics about the ID format or source, so the schema carries the parameter explanation.

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 and resource ('Get a song') and enumerates the returned fields: status, title, cover, lyrics, and a short-lived audio link. It is clearly a detail-fetch tool, but it does not explicitly differentiate itself from siblings such as get_song_parts or get_my_songs.

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 by explaining that hosts rendering MCP Apps will show a card with a player and synced lyrics, and that the audio link need not be pasted. However, it gives no explicit guidance on when to choose this tool over alternatives like get_song_parts or get_my_songs.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine context beyond that: it discloses the shape of the returned data and, notably, that it reports whether a part's words can be changed — a mutability signal an agent needs before editing. It says nothing about pagination or failure behavior, which keeps it short of a 5.

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

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

Two dense sentences with no filler. The resource and return shape come first, and the sequencing instruction to run it before change_lyrics is placed at the end as the actionable takeaway. 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?

For a single-parameter read tool with no output schema and coverage from annotations, this is fully sufficient: it describes what is returned, the identifier format of parts, the editability flag, and the workflow context. An agent has everything needed to select and invoke it correctly.

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

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

Schema description coverage is 100% and the single songId parameter is already documented in the schema, including where to obtain the id (get_my_songs or a song card). The description only refers obliquely to 'one of their songs' and adds no new syntax or constraint, so baseline 3 applies.

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

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

States a precise verb and resource ('List the parts of one of their songs') and goes further to enumerate the returned content: part ids like verse#1/chorus#2, the lines sung in each, their times, and whether the words are editable. That level of specificity lets an agent distinguish this from generic song-fetching siblings 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?

Explicitly prescribes the sequencing: 'Call it before change_lyrics to find the part they mean,' which tells the agent exactly when this tool is the right step. It stops short of any when-not guidance or differentiation from the overlapping sibling get_song_details, so it is clear context rather than a full decision rule.

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

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

The description adds substantial behavioral context beyond the read-only annotations: it explains the possible statuses, that done includes video and poster links valid for 6 hours, and that failed means credits are refunded. These are important operational details an agent would otherwise not know.

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 definition is a single, front-loaded sentence that conveys the operation, its origin, its states, and the key return semantics. Every clause earns its place with no redundant 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?

An output schema exists, so the description need not explain the full return shape. It still provides enough status and link-expiry context for an agent to understand what calling this tool yields and how to interpret making, done, and failed results.

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 the only parameter's description ('From make_video') is already documented in the schema. The tool description does not add further syntax or format details for videoId, 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 gives a specific verb and resource: get a video made with make_video. It also names the possible states, making/done/failed, which clearly distinguishes it from sibling creation tools like make_video and song-focused tools like get_song_details.

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 'made with make_video' clearly implies this is used to check the result of a prior make_video call. It does not explicitly state when not to use it or name an alternative, but the context is clear and there is no direct sibling for video status lookup.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that results include pricing and credits, but does not mention pagination, ordering, or whether unavailable plans are included.

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 communicates the core action and included data efficiently.

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, read-only listing tool with annotations covering safety and an output schema covering return structure, the description is nearly complete. The main missing context is how it relates to list_topup_packages and purchase_credits.

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?

There are zero parameters, so the baseline is 4. The description does not need to explain input semantics beyond the schema's empty object.

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: get subscription plans. It also clarifies that pricing and credits are included. It does not explicitly distinguish this from list_topup_packages, but the resource difference is reasonably 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?

Usage is implied by the read-only listing nature and the nearby purchase_credits sibling, but the description does not explicitly say when to use this tool versus list_topup_packages or purchase_credits. No exclusions or prerequisites 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that only available one-time packages are returned, but does not add further behavioral context such as authorization needs 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 a single, front-loaded sentence with no redundant or unnecessary content. It efficiently communicates the resource and scope.

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 simple zero-parameter read-only nature of the tool, the annotations, the output schema, and the concise description, an agent has all necessary information to select and invoke it correctly. Return values are covered by the output schema.

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

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

The tool has zero parameters, so there are no parameter semantics to clarify. The baseline score of 4 applies because the description does not need to compensate for missing parameter documentation.

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: get available one-time credit topup packages. It implicitly distinguishes top-up packages from subscription plans, but does not explicitly name or contrast with the sibling list_subscription_plans tool.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as list_subscription_plans or purchase_credits. The usage context is only implied by the tool name and package type.

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?

Goes well past the annotations (which only say it's a non-destructive, closed-world write): it discloses the credit cost formula (1/second + 1, 11 credits for 10s), that HD costs more, the multi-minute async latency, the exact polling tool and identifier to use, and a refund guarantee for failures. Those are the four things an agent most needs to know before spending a user's credits on 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?

Front-loaded with the purpose, then cost, then the pre-condition, then the async protocol – a sensible priority order with no filler sentences. The cost sentence is slightly dense ("1 credit a second plus 1 (11 credits for 10 seconds)") but every clause carries operational 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 paid, asynchronous, non-destructive generation tool with a full output schema, the description covers everything an agent needs: what it produces, what it costs, what to agree before calling, how long it takes, how to check status, and what happens on failure. Nothing material is left 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 description coverage is 100% and the schema already documents hd, part, prompt, songId and seconds including ranges and defaults, so the structured data carries most of the burden. The description adds real economic meaning to `seconds` and `hd` (cost per second, HD surcharge) and implicitly links "the scene" to `prompt`, but adds no new semantics for songId or part beyond the schema. Baseline 3 is right.

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 ("Make a music video for one of their songs") and immediately qualifies the output: a described scene animated to a portion of the track with the song underneath. This is unmistakably distinct from the other generation siblings (generate_song, generate_remix, reimagine_song, change_lyrics), which produce audio rather than video.

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 pre-call guidance ("Agree the scene and length with them first") and a concrete follow-up path ("poll get_video_details with the videoId"), which is exactly what an agent needs to sequence this call. It stops short of stating explicit exclusions or naming which sibling to use if the user only wants audio, but the usage context is unambiguous.

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 a non-read-only, open-world, non-destructive operation. The description adds the crucial behavior that this is a redirect-based, human-in-the-loop flow and warns autonomous agents away from it, which annotations cannot express. It stops short of saying what happens after the session is created (expiry, duplicate sessions) but the output schema covers the return shape.

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

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

Front-loaded with the core action and return value; the alternate-endpoint guidance is dense but earns its place. Slightly awkward to parse as a single long sentence at the end, but there is no filler.

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

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

With annotations covering the safety profile and an output schema covering the return, the remaining burden is usage routing, which is handled well. The one gap is that product IDs must come from a sibling listing tool, which is implied by context but not stated.

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 successUrl, cancelUrl, and productId are already fully documented with formats and constraints. The description only echoes productId inside the alternate endpoint template and adds no sourcing guidance (e.g., where to get product IDs from list_topup_packages or list_subscription_plans). 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?

States a specific verb and resource: 'Create a Stripe checkout session to purchase credits or subscribe to a plan.' It also notes the return value (a checkout URL) and distinguishes itself from the plan/package listing siblings by naming both purchasable outcomes. An agent can identify the tool 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?

Explicitly routes: this tool is for a human to open the returned URL, whereas an autonomous agent paying with an MPP wallet must use POST /v1/agents/credits/{productId} with X-API-Key. That is a clear when-to-use / when-not-to-use split naming the alternative.

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=false, destructiveHint=true, and openWorldHint=false, so the safety profile is covered. The description adds non-obvious context beyond that: the credit cost (2), that the original is preserved, and that MCP Apps hosts render a progress card then play the result. The preservation wording sits in mild tension with destructiveHint=true, but spending credits reasonably explains that flag.

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

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

Front-loads the core action, then layers cost, the style-agreement prerequisite, and the host UI behavior. Every sentence carries information and nothing is padded, though the multi-clause opening is slightly dense.

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

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

An output schema exists, so return values need not be explained. The description covers the cost, the preservation guarantee, and the progress/playback UX, which is enough for an agent to invoke it correctly; only the sibling disambiguation is missing.

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

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

Schema description coverage is 100%, so all four parameters (style, title, lyrics, songId) are already documented in the schema. The description restates the style dimensions and the 'own words unless new ones are given' default, adding little beyond the schema. 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 concrete verb and resource ('Make one of their songs again in a new style') and specifies the dimensions being transformed (genre, mood, instruments, voice). It hints at differentiation from change_lyrics via 'with its own words unless new ones are given' and 'keeps the original', but never names the close sibling generate_remix, leaving that distinction to inference.

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?

'agree the style with them first' gives a real prerequisite, and the 2-credit cost is disclosed, which is useful for deciding whether to call it. However, there is no explicit when-to-use-vs-alternative guidance against generate_remix, generate_song, or change_lyrics, so the agent must infer which tool applies.

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