StemConsole

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

Annotations already declare mutating, open-world, non-idempotent, non-destructive behavior. The description adds valuable behavioral context beyond that: account-type limits (free = 3 songs, Pro = 50), that anyone can open the link, and that output is a shareable ordered link. It doesn't cover error responses or what happens at limit overflow, but it adds substantive non-annotation 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 sentences, front-loaded with the core action and output, followed by the critical limits. No wasted words; every sentence earns its place.

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

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

For a 2-parameter creation tool with annotations and no output schema, the description covers the key concerns: what is created, who can access it, and account-tier limits. It could mention the maximum length of the title or what happens when the limit is exceeded, but it is nearly complete.

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

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

Schema coverage is 0%, so the description must compensate. It does not explain the 'title' or 'split_ids' parameters, but the schema itself documents split_ids items (a split id from split_songs or list_my_songs) despite the reported coverage metric. The description adds nothing about parameter semantics, so baseline 3 is appropriate given the schema's internal 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?

States a specific verb and resource (make a setlist) and goes further to describe the actual output: one share link that opens songs in order in the browser. This distinguishes it from siblings like list_setlists or split_songs, though it doesn't 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 implies usage (for a band or a class, with shareable links) but does not state explicit when-to-use or when-not-to-use conditions, nor does it name sibling tools as alternatives. Context is present but guidance is implicit rather than directive.

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 destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds real value beyond that: it discloses the cascade (stems are deleted too), the external side effect (the share link stops working), and irreversibility, which the boolean hints cannot convey.

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 short sentences, each earning its place: what is destroyed, the downstream consequence, and the required caution. The most important fact (permanent deletion) is front-loaded.

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

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

With no output schema, the description still tells the agent the key outcome (link stops working) and the risk profile. It omits permission/auth requirements and any error behavior, but for a single-parameter destructive tool the coverage is nearly sufficient.

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

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

Only one parameter (split_id), and the schema already documents it fully with a pattern and a pointer to split_songs/list_my_songs. The description adds nothing about the identifier format or source, so the schema does all the work — 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 (permanently delete), the exact resource (the connected account's song and its stems), and scope. It is clearly distinguishable from siblings like rename_song, split_songs, and list_my_songs 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?

"Confirm with the user first" gives a clear precondition for invoking it, and the irreversibility note implies when not to reach for it casually. However, it names no alternative (e.g., rename_song) for users who want to modify rather than remove a song, so routing guidance is only implied.

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 this as a safe read-only operation, so the bar is lower. The description adds meaningful return-value context by listing the per-song statuses and split id, which is especially valuable since no output schema exists.

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?

One compact sentence that front-loads the resource and immediately describes the return payload. Every phrase contributes to identifying the tool or its output.

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 tool with annotations covering safety, the description gives the essential output shape (statuses and split id). It remains slightly incomplete because it does not explain the batch_id format or how to obtain a batch id.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented batch_id parameter. It does not mention the parameter name, expected format, or the 16-character hex pattern, adding no semantic 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?

The description states a specific resource (a batch's progress) and ties it to split_songs, making it distinguishable from siblings like get_split or get_split_result. It is clear, though it uses a noun phrase rather than an explicit verb and does not name alternative tools.

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

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

The phrase 'from split_songs' implies this should be used to monitor a batch created by split_songs, which gives useful context. However, there is no explicit when-to-use instruction, no when-not guidance, and no mention of alternative status-checking tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered structurally. The description adds genuinely useful behavioral context by disclosing the scope of what is returned (capabilities, stem list, pricing tiers including trial and single-song credits) and that no input is required.

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

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

A single front-loaded sentence carries the payload, with a short second sentence confirming no input. The closing sentence is mildly redundant given the empty input schema, but it is a harmless and common clarification rather than 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 no output schema, the description must describe return content, and it does enumerate the main payloads (capabilities, stems, pricing tiers, trial, credits). It stops short of describing structure or format, but for a no-argument informational tool this is close to complete.

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

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

Zero parameters, so the baseline is 4. The description correctly notes 'No input required', which is consistent with the empty schema and adds no conflicting meaning.

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 ('Describe') and enumerates the exact resource content: what StemConsole can do, available stems, and pricing tiers. This is clearly distinguishable from every sibling, which deal with songs, splits, setlists, and tasks.

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 would infer it should call this to learn about the service, stems, and pricing before other operations. There is no explicit when-to-use statement, no prerequisites, and no named alternative, though none of the siblings cover this ground.

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, openWorldHint=false, so safety is covered. The description adds genuine value beyond that: it names the auth prerequisite and lists the concrete content of the response (plan, usage counters, credits, rate limits), which the annotations cannot convey.

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, front-loaded with the payload contents and ending with the one prerequisite. No filler, no restatement of 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?

With no output schema, the description carries the return-value burden and does enumerate the main fields, which is adequate for a zero-argument read tool. Minor gap: it doesn't describe the response shape or units (e.g. credit or reset semantics), but nothing essential 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?

Zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly introduces no argument concepts, matching the empty 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+resource (the connected account's plan and usage) and enumerates the exact fields returned: plan tier, splits used/left, credits, and API rate limits. This clearly separates it from song/split/setlist siblings, none of which read account-level data.

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

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

The description gives a precondition ('Needs a connected StemConsole account'), which is useful operational context, but it never says when to call this instead of the related get_capabilities tool, nor any when-not conditions. Usage is implied rather than guided.

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 establish read-only and non-destructive behavior, but the description goes further by disclosing gating rules: WAV links and the ZIP exist only on Pro or on a song split with a credit, and links appear only after the split finishes. That is genuinely useful context not present in the annotations, though return-status values and polling cadence remain unspecified.

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?

One sentence, appropriately sized, and front-loaded with the primary purpose (status) before the payoff links. The nesting of qualifiers inside parentheses is dense and slightly hard to parse, but no clause is 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 no output schema, the description carries the return-value burden and does list the payload (status, stem MP3s, preview links, WAV links, ZIP, practice-room link) along with tier gating. It falls short only on what status values to expect and whether repeated polling is intended.

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 split_id parameter already documents its pattern and its source (split_songs or list_my_songs). The description adds no further meaning about the parameter, 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 specific verb and resource: the status of one split plus, once complete, each stem's MP3/preview links, WAV links, ZIP bundle and a practice-room link. The scope is concrete, but the description never distinguishes this from the sibling get_split_result, which an agent could easily confuse with 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?

The phrase 'once done' implies a polling pattern (call for status, call again for links), so usage is implied rather than stated. There is no explicit guidance on when to prefer this over get_split_result, split_audio, or split_songs, and no note that the id must come from a prior split call.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds the useful behavioral fact that stem download URLs are returned once status is 'done', which matters because there is no output schema to convey 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?

Two short sentences, zero waste, with the core purpose front-loaded and the return condition following. Nothing redundant with the title or annotations.

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 does carry the return-value burden and handles it adequately by noting the done-state URLs. Minor gaps remain, such as what status values exist or how to poll, but the essentials for calling correctly are present.

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

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

Schema description coverage is 100%; both job_id and download_key are documented in the schema, including that download_key is required for full-quality URLs. The description adds no parameter meaning beyond that, 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 states a specific verb and resource: checking the status of a split job, naming split_audio as the originating tool. It is clearly distinguishable from the generic get_split only by implication, but the status-check framing is specific enough for correct selection.

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 establishes the workflow context (pairs with split_audio, implies polling until done) but does not state when to prefer this over siblings like get_split or get_task_url, nor any exclusion. Usage is implied rather than prescribed.

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 only that the return is a user-facing link, and says nothing about behavior for unrecognized task values or whether the URL is stable/authenticated. Adequate but thin against the lower annotation 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?

One sentence, front-loaded with the verb and resource, with zero filler. Every clause earns its place by naming the output and its intended use.

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

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

For a one-parameter read-only lookup with no output schema, the description covers what the tool returns and why. It could have noted the URL format or behavior on invalid task values, but nothing essential for correct invocation 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 coverage is 100% with a single enum parameter whose 21 values are self-describing, so the baseline of 3 applies. The description adds no syntax, default, or selection guidance beyond 'a specific audio task.'

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: 'Return the StemConsole page URL for a specific audio task.' An agent can tell this is a URL-lookup helper rather than an audio-processing tool. It does not name or contrast with any sibling (e.g., get_split, get_capabilities), so it falls short of the top score.

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?

'so you can hand the user a direct link' implies the use case (surfacing a shareable link to the user), which is useful but implicit. There is no statement of when not to use it, no prerequisites, and no reference to alternative tools for retrieving task info.

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 establish readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description usefully adds ordering ('newest first') and the fields carried in each item (split ids, practice-room links), but says nothing about how many songs 'most recent' means, whether results are paginated, or what happens when the account has none.

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?

One sentence, front-loaded with the resource and scope; no filler. The parenthetical '(My songs)' adds little beyond the title, and the trailing field list makes the sentence slightly dense, keeping it off 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?

With zero parameters and no output schema, the description is the only place a caller can learn the return shape, and it does partially cover this (ordering, split ids, practice-room links). It omits result limits/pagination and empty-result behavior, which for a listing tool with no schema of its own is a 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?

The tool takes zero parameters, so the description has nothing to disambiguate; the 4 baseline applies. The mention of split ids and practice-room links is result-shape information rather than parameter information.

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

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

Names a specific resource (the connected account's songs, 'My songs') and adds scope details — most recent, newest first — that a reader can use to distinguish it from list_setlists or get_split. It never explicitly contrasts itself with those siblings, so it stops 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?

There is no when-to-use statement, no condition under which another sibling (e.g. split_songs, get_split) is preferable, and no exclusions. The agent can infer the intent from the resource scope but is given no routing guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and a closed-world scope, so safety is covered. The description adds a useful behavioral detail beyond the annotations by stating that each setlist comes with its songs and a share link, which is the sole signal about the shape of the response since no output schema exists.

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 compact sentence with no filler, and the payload detail is front-loaded rather than buried. It is perhaps slightly terse for a tool with no other documentation, but nothing in it 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 no-parameter, read-only list tool whose annotations cover safety and which has no output schema, the description supplies the essential resource and return-content context. Missing only secondary details such as ordering, pagination or result limits.

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 for the description to disambiguate; the baseline for a 0-parameter tool is 4. No syntax or format concerns apply.

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 resource (setlists belonging to the connected account) and even characterizes the payload (songs + share link), so an agent knows exactly what it returns. It lacks an explicit verb, but the title 'List my setlists' supplies that. It is distinguishable from list_my_songs via the 'setlists' resource, though it never says so directly.

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 call this versus siblings such as list_my_songs or get_my_account, nor any prerequisite or exclusion. The only implied usage cue is the 'connected account' scoping, which an agent must infer.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety semantics are covered elsewhere. The description adds essentially nothing beyond the name/title, e.g. no failure modes for a malformed split_id, name-collision behavior, or confirmation that renames are reversible.

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?

One sentence with zero filler and the resource scope front-loaded. It is efficient, though the terseness means it is closer to under-specified than optimally structured.

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

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

For a 2-parameter mutation with no output schema, annotations already cover the mutation and idempotency profile, so the description only needs to add the name-parameter meaning and any nesting/format rules. It does not, leaving a modest 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 50%: split_id is documented in the schema ("A split id from split_songs or list_my_songs") while the name parameter carries only type/length constraints, with no meaning explained anywhere. The description supplies no parameter guidance at all, so it does not compensate for the gap.

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

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

States a specific verb+resource ("Rename ... songs in its library") that is clearly distinguishable from siblings such as delete_song or create_setlist. It stops short of naming an alternative or the return/scope boundary, so it is clear but not sibling-differentiated.

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 when the tool applies (you have a song in the connected account's library that needs a new name) but gives no when-not guidance and names no alternative. Nothing tells the agent how to pick between this and, say, delete_song or split_songs when reorganizing a library.

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 declare readOnly=false, destructive=false and openWorld=true; the description goes well beyond them by disclosing the payment rail (USDC on Base Sepolia testnet), the exact two-call handshake, the error behavior when the endpoint is switched off, and the asynchronous job_id return. That is precisely the kind of behavioral context structured fields cannot 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?

Four dense sentences with the core action front-loaded, followed by the payment handshake, the result-handoff, and the failure/fallback case. Every sentence contributes decision-relevant information and none is redundant.

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 tool with no output schema, the description covers the full lifecycle: how to obtain payment requirements, how to submit payment, that the immediate return is only a job_id, where the stem URLs come from, and what happens on failure. An agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so the model enum and the `payment`/`filename`/`audio_url` semantics are already fully documented in the schema. The description reinforces the payment parameter's omit-first-call pattern but adds no syntax or format detail the schema lacks; 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 verb and resource ('Separate a song at a public URL into stems') and adds the scope constraint that input comes from a public URL rather than an upload. The paid x402 framing further distinguishes it from free sibling tools like split_songs, so an agent can tell what this call is for at a glance.

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 two-step invocation protocol (call without `payment` to get requirements, call again with the x402 receipt), names the sibling to poll for results (get_split_result), and provides a when-not path via the browser fallback if the paid endpoint is disabled. Nothing about when to use this versus alternatives is left to inference.

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

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

Annotations cover only the safety profile (non-read-only, open-world, non-idempotent); the description adds substantial behavior beyond that: it consumes the account's plan and allowance, batch concurrency of two, asynchronous completion requiring polling, and that the full model needs Pro or a credit. That is exactly the kind of context the annotations cannot convey.

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?

Dense but front-loaded: the core action and scope come first, then input format, then async lifecycle, then model options. Every clause carries operational information with no filler.

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

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

With no output schema, the description still tells the agent what happens after the call (immediate return for one song, queued batch otherwise) and how to retrieve results via get_split/get_batch. Nothing needed to invoke and complete the workflow 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?

Top-level parameters have 0% schema description coverage, and the description compensates fully: it defines each model enum value by the stems it produces (vocals/instrumental, drums/bass/other, guitar+piano) plus its plan requirement, and specifies the audio_url contract (public direct file link, Dropbox/Google Drive share links acceptable). This is meaning well beyond the raw 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 (split), resource (songs into stems), scope (1 to 10), and execution context (connected StemConsole account, same as the website). It is clearly distinguishable from the single-file sibling split_audio by its explicit 1-10 batch range.

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 strong conditional guidance: one song runs immediately and returns its split, 2-10 are queued two at a time, and the agent is told to poll get_split or get_batch until status is done. It does not explicitly contrast against the split_audio sibling, so the routing is slightly incomplete.

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