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

Annotations already declare the write/non-destructive/non-idempotent profile, so the bar is lower, and the description usefully adds that the work is queued asynchronously rather than performed inline. It does not say whether the original target file is modified or a new artifact is produced, nor how completion is observed.

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 with no wasted words; the action is stated first. It is perhaps slightly too terse for the amount of workflow an agent must reconstruct.

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 the return payload is covered, and all paths are documented. What is missing is workflow context: how the queued alignment job is tracked to completion, and whether the output is a new file inside the unique run subdirectory.

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%, so the schema already documents all three paths. The description does add directional meaning — the reference defines the timeline and the target is what gets adjusted — but says nothing about output_dir beyond what the schema states.

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 two-step operation: estimate the sample offset, then write the target aligned to the reference. This distinguishes it from neighbors like matchering_inputs or time_stretch, though the term 'aligned' still requires the reader to infer that the alignment is temporal.

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 choose this over siblings such as matchering_inputs, time_stretch, or create_sample, and no prerequisites or exclusions are mentioned. The agent must infer the use case purely from the operation name.

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

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

Annotations already declare readOnly=false, idempotent=false, destructive=false, closed-world, so the safety profile is covered. The word 'Queue' usefully signals asynchronous job submission rather than a blocking call, but the description does not state that a job handle is returned or that get_job is needed to retrieve results. It adds some context but leaves the async workflow implicit.

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 with no filler; every term (full-file, each metric, BS.1770) carries meaning. It is efficient, though so terse that the async nature is only hinted at by 'Queue'.

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 and annotations covering safety, the main remaining gap is workflow: the description never says this is a queued job whose result must be fetched later. For an async, non-idempotent tool in a suite full of job-based siblings, that is a meaningful omission.

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

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

Schema description coverage is 100%, with both audio_path and output_dir documented including the overwrite-prevention behavior of output_dir. The description adds only the 'full-file' scope note and no parameter-level detail, 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 specific verb (queue) and resource (audio analysis) plus the exact metrics computed (peak, RMS, clipping, BS.1770 integrated loudness). This clearly separates it from probe_audio or verify_audio in intent, though it never names those siblings to make the distinction explicit.

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 or when-not-to-use guidance, and no mention of the closely related siblings (probe_audio, verify_audio) that an agent would need to choose between. The agent must infer selection criteria from the metric list alone.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the risk profile is covered; the description adds genuinely new context by disclosing that partial-run evidence is preserved and that the effect differs for queued vs. actively running work. It stops short of saying whether the cancellation is graceful or immediate.

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 with no filler; the action comes first and the side-effect clause follows. It is efficiently sized, though the two-branch distinction is compressed into one clause rather than 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 one-parameter destructive tool, everything an agent needs is present: annotations carry the safety profile, the schema fully documents job_id, and an output schema exists so return values need no prose. The description contributes the one non-obvious fact — that evidence survives cancellation.

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 job_id field already explains its provenance ("returned by start_separation or an audio tool"). The description adds nothing about the parameter, which is fine at baseline 3 but no better.

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 pair ("stop" / "terminate") against a specific resource (queued work / native worker), and clarifies that both a queue-level and a process-level cancellation path exist. It is clearly distinguishable from the closest siblings (get_job, list_jobs) although it does not name them 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?

The two branches (queued vs. running) imply when each behavior applies, but the description never states prerequisites, whether to check job state with get_job first, or what is not cancellable. 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 readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description contributes two useful behavioral facts beyond them: the result is capped at fifty records and only 'confirmed' changes are included, implying unconfirmed/pending entries are filtered out. It does not explain ordering (newest-first assumed but unstated) or what 'confirmed' means operationally.

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 sentence with no filler, and the key qualifiers ('latest fifty', 'confirmed') are front-loaded where an agent will see them first.

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-argument, read-only tool with an output schema already defining the return shape, the description covers what is needed. The only residual gap is the meaning of 'confirmed' and the ordering of results, which an agent may want when interpreting the journal.

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 is 4. The description correctly implies no filtering arguments by saying it always reads the latest fifty confirmed records.

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 ('read ... catalog/profile change records') plus a bounded scope ('latest fifty', 'confirmed'), so an agent can tell it returns a change log rather than model listings or pending updates. It stops short of naming how it differs from the adjacent list_updates sibling.

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 when-to-use guidance, no exclusion of alternatives such as list_updates, list_models, or verify_catalog, and no stated prerequisites. The only usage signal is implicit in 'latest fifty', which hints at recency but not at selection criteria.

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, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety and network profile. The description adds useful context about what exactly is compared (pinned UVR patch vs platform-specific upstream metadata), but does not mention side effects, caching, or what happens when offline.

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 with no wasted words. It immediately conveys the comparison being performed.

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

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

With an output schema present and rich annotations, the description covers the core operation. The only minor gap is not clarifying how this differs from list_updates, but that is more a usage-guideline concern than a completeness failure.

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 beyond the schema. Schema description coverage is 100%, and the description does not need to compensate for any parameter ambiguity.

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 (Compare) and resources (pinned UVR patch vs current platform-specific upstream metadata). It does not explicitly distinguish itself from the sibling list_updates, leaving some ambiguity about which update-related tool to call.

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: call this to check whether the pinned patch matches upstream. There is no explicit when-to-use guidance, no mention of alternatives like list_updates, and no conditions or prerequisites 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 the safety profile (not read-only, not destructive, closed-world, not idempotent). The description adds genuine context beyond that: this is a queued/asynchronous operation, and it writes into a unique output subdirectory so prior runs are not overwritten — which aligns with idempotentHint=false. It stops short of saying how the queued work is tracked, which is the detail an agent most needs.

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 with zero padding — the action leads and the output-directory caveat follows. It is efficient, though its brevity comes partly from omission rather than discipline.

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 and annotations cover safety, so return shape is not the description's job. Still, for a job-queuing tool the description should say results are retrieved asynchronously via the job siblings; without that, an agent knows what it does but not how to finish the workflow.

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 audio_path, output_dir, offset_seconds, and duration_seconds are all documented in the schema itself. The description's only parameter-adjacent content is the "unique output directory" note, which repeats the output_dir schema text rather than extending it. 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?

"Queue a real preview clip" gives a verb (queue) and a resource (preview clip), so the basic action is inferable. But it never differentiates itself from nearby siblings such as analyze_audio, probe_audio, or start_separation, and the qualifier "real" adds no discriminating information.

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 statement of when to use this versus the many other audio-processing siblings, and no prerequisites. The word "Queue" hints at an async job, but nothing tells the agent to poll get_job or list_jobs afterwards, which is essential to using it correctly.

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, openWorldHint=true, and non-idempotent behavior, so the safety profile is largely covered. The description adds the plan-versus-execute framing, but does not disclose what downloading entails (network fetch, potentially large transfers, disk writes) beyond what annotations imply.

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 with no filler. It is efficient, though the terseness borders on under-specification for a destructive, network-facing operation.

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 no explanation, and annotations cover the safety profile. Still, for a destructive open-world tool with sibling overlap, the description omits the network-download implication and the choice against download_model.

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 'confirm' parameter description already explains plan versus execute, so the description adds nothing parameter-specific. Baseline 3 is appropriate when the schema does all the work.

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 (plan or download) and resource (missing models) scoped to one architecture, which is more than a restatement of the name. However, it does not distinguish itself from sibling tools like download_model or list_models, leaving the exact boundary of 'missing models' and 'supported architecture' ambiguous.

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

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

No indication of when to use this instead of download_model, list_models, find_model, or refresh_catalog, even though several siblings clearly overlap. There is also no stated prerequisite (e.g., network availability or a fresh catalog) for the download path.

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 disclose that this is a destructive, non-idempotent, open-world write operation. The description adds useful context that the download lands in Maestro-owned storage and covers a complete artifact set, but it does not explain overwrite behavior, confirm/plan semantics, or what happens on repeat calls.

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 with no filler. It states the action, scope, and destination 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?

Output schema and rich annotations are present, reducing the description's burden. However, for a destructive open-world download with a confirm parameter, more detail about plan mode and overwrite behavior would improve completeness, and sibling differentiation is absent.

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%, so both slug and confirm are already documented in the input schema. The description adds no additional meaning about parameter formats, aliases, or the plan-vs-execute behavior of confirm, so it meets the baseline for fully documented schemas.

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: download a complete model artifact set into Maestro-owned storage. It distinguishes itself from bulk alternatives like download_missing_models by emphasizing a 'complete' single artifact set, though it does not name 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?

There is no guidance on when to use this tool versus download_missing_models, register_model, or list_models/find_model. The description implies usage but provides no exclusions, prerequisites, or decision criteria.

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 is a safe, idempotent, read-only, non-destructive operation, so safety is covered. The description adds that models are filtered for compatibility and ranked, and that selection is task-based — useful behavioral context, though 'compatible' and the ranking method are left unexplained.

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?

It is a single sentence with no wasted preamble, which is good, but the trailing clause 'expose the task-based selection' is vague enough that it doesn't fully earn its place. Front-loading 'Rank compatible supported models' is effective.

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 tool with an output schema and full annotation coverage, the description is minimally adequate. However, it leaves important context unstated: what compatibility means, how ranking works, and why an agent would choose this over list_models.

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 single 'intent' parameter is fully described in the schema. The description's phrase 'task-based selection' loosely ties the intent parameter to the ranking behavior but adds no format or semantic detail beyond what the schema already says.

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

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

The verb 'Rank' and resource 'compatible supported models' give a rough sense of purpose, but the second clause ('expose the task-based selection') is jargon that doesn't clarify what the tool actually returns. It never names or distinguishes itself from the sibling list_models, so an agent cannot confidently tell which to pick.

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 when-to-use, when-not-to-use, or alternative named. The only hint is the word 'task-based,' which implies usage when you have a task intent, but that is inference rather than 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds the useful detail that output includes a 'durable manifest path' (persisted artifacts), but says nothing about progress semantics, terminal states, or partial results.

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 front-loaded sentence, zero filler, listing exactly what the call returns. Nothing redundant with the name or schema.

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, rich annotations, and a fully documented single parameter, the description covers what an agent needs to call it correctly. The only gap is guidance on polling cadence and relationship to list_jobs/uvr_status, which is minor at this complexity level.

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?

Single parameter with 100% schema coverage; the schema already explains job_id comes from start_separation or an audio tool. The description adds no further parameter meaning, 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?

Specific verb+resource ('Read a job's state, progress, actual outputs and durable manifest path') that clearly separates it from list_jobs (enumeration) and cancel_job (mutation). It doesn't explicitly name the sibling it contrasts with, but the scope is unambiguous.

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

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

Usage is only implied: an agent can infer this is the polling/inspection call after start_separation or separate_audio, but the description never says when to use it rather than list_jobs or uvr_status, nor whether repeated polling is expected.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context that the result is defaults overlaid by the selected persisted profile, but it does not discuss permissions, error behavior, or response structure beyond what the output schema provides.

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. Its brevity is efficient, though it is slightly cryptic because the resource noun is omitted.

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

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

The tool is simple: one optional parameter, rich annotations, and an output schema already covering return values. The description is therefore close to sufficient, but it remains vague about what 'defaults' and 'profile' refer to and does not distinguish this read operation from reset_settings or set_settings.

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 'name' parameter is already documented as a profile filename without extension where None uses the default. The description's phrase 'selected persisted profile' loosely reinforces that parameter, but it adds no format or edge-case detail 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 read operation over defaults with a persisted profile overlay, but it never explicitly names the resource as settings. It is more specific than a tautology, yet an agent must infer the object being read from the tool name rather than the description itself.

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

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

The description gives no guidance on when to use this tool versus set_settings or reset_settings. It implies a read-only settings lookup, but it does not state exclusions, prerequisites, or when a profile should be selected.

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 read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful scoping context: results are capped at the latest hundred and include both persisted and active jobs. It does not describe ordering, pagination, or return format, though an 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 front-loaded sentence with no wasted words. It states the action, resource, cap, and job states 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 list tool with annotations and an output schema, the description is nearly complete. It conveys the result cap and included job states, but could clarify ordering or what 'persisted' means relative to 'active'.

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 parameter semantics baseline at 4. The description correctly implies no filtering options are accepted.

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 ('List') and resource ('jobs') with a clear scope: the latest hundred persisted and active jobs. It implicitly distinguishes a list operation from the sibling get_job, but does not explicitly name 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?

Usage is implied by the scope 'latest hundred persisted and active jobs', which suggests browsing recent jobs rather than fetching a specific one. However, there is no explicit guidance about when to use this versus get_job or other job-management 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, idempotentHint, non-destructive behavior, and closed-world access. The description adds useful context that the read is offline and does not trigger downloads, clarifying there is no network side effect, though it does not elaborate on how catalog and disk state are merged.

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 immediately communicates the operation and the key no-download constraint.

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 a full input schema, an output schema, and strong read-only annotations, the description covers the essential behavior an agent needs: it reads local catalog/disk state without downloading. The main remaining gap is sibling routing guidance rather than call-correctness 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?

Schema description coverage is 100%, so all five parameters are already documented in the input schema. The description adds no additional parameter semantics, which is acceptable given the schema coverage but means it only meets the baseline.

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

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

The description states a specific read operation over the offline catalog and current disk state, which aligns with the list_models name. It also distinguishes itself from downloading workflows by saying 'without downloading,' though it does not explicitly differentiate from siblings like find_model or refresh_catalog.

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 'without downloading' implies this is for browsing local catalog/disk state without network activity. However, it does not explicitly say when to use this versus find_model, refresh_catalog, or download_model, leaving alternatives 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 already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral note: it does not trigger an installer download. It says nothing about scope, freshness, or whether the URLs are fetched remotely.

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 short sentence with no filler, and the 'without downloading an installer' qualifier lands early. It is efficient, though the phrasing 'patch source' is terse enough to be slightly cryptic.

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 params, full annotation coverage and an output schema, most structured context is already provided. What remains missing is how this relates to 'check_update' and what 'patch source' refers to, which is exactly the gap the description should close and does not.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. No parameter-level detail is needed here.

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 an action (read full-installer URLs and patch source) but never plainly says what the tool lists or returns, so the name 'list_updates' does much of the work. It also fails to differentiate from the sibling 'check_update', leaving an agent unsure which one surfaces update information.

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 when-to-use guidance, no when-not-to-use, and no named alternative. The phrase 'without downloading an installer' implies a non-destructive lookup scenario, but the agent must infer that versus 'check_update' or 'download_model'.

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 state readOnly=false, idempotent=false, destructive=false, and openWorld=false. The description adds useful context that this queues asynchronous mastering and guarantees a verified 24-bit WAV output, but it omits whether a job ID is returned or how completion is tracked.

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 with no filler. It efficiently packs the action, the Matchering system, and the resulting output quality.

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 and parameter coverage is complete, so return-value details are not required in the description. However, for a queued asynchronous operation, the description should signal job tracking or handoff to status tools such as get_job; that remains implicit.

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

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

Schema description coverage is 100%, so all three path parameters are already documented in the schema. The description adds no parameter-level meaning beyond what the structured schema provides, making the baseline 3 appropriate.

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

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

States a specific action (queue reference mastering with Matchering) and a concrete output (verified 24-bit WAV). The resource and operation are distinct from the separation/model-management siblings, though no sibling is explicitly named for differentiation.

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

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

The description gives no explicit when-to-use or when-not guidance, and it does not name any alternative or related job-tracking tool. The queueing context is only inferable from the verb 'Queue'.

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 annotations already declare this is a non-read-only, non-idempotent, non-destructive operation. The description adds useful context by saying it queues work and preserves duration, but it does not explain job status behavior, output directory semantics, or whether existing files are overwritten.

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 filler. It is appropriately sized, though it could be slightly more informative without becoming verbose.

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

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

An output schema exists and parameter documentation is complete, so the remaining gap is mainly routing guidance versus sibling tools. The description is adequate for basic invocation but not fully complete for agent tool selection.

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%, so all three parameters are already documented in the input schema. The description adds no parameter-specific meaning beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description states a specific action (pitch shifting) and a key behavior (preserving duration), which distinguishes it conceptually from a time-stretch operation. It does not explicitly name the sibling `time_stretch` or clarify scope relative to it, 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?

No guidance is given on when to use this tool versus alternatives such as `time_stretch` or `separate_audio`. The description implies it is for pitch shifting, but provides no conditions, exclusions, or prerequisites.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds one genuine behavioral trait beyond that: it avoids full decode, which signals speed and low resource cost. It does not say what happens on an unreadable/corrupt file or what metadata is returned, so the added value is modest.

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 with the verb first and zero filler. Nothing in it is redundant against the name or the schema.

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 no explanation, and the safety annotations cover the rest. However, for a tool whose whole value is 'what metadata do I get', the description never hints at the fields produced (duration, sample rate, channels, format), leaving the agent to open the output schema to judge fitness.

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 exists and the schema documents it fully (100% coverage), including the absolute-vs-relative path distinction. The description adds nothing about audio_path, so the baseline 3 applies since the schema does all the work.

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 ('Read file metadata') plus a scoping qualifier ('without decoding the whole recording') that implicitly separates it from decoding-heavy siblings like analyze_audio or verify_audio. It does not name any sibling explicitly, so it lands at clear-but-undifferentiated rather than 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?

The phrase 'without decoding the whole recording' implies this is the cheap, lightweight inspection step, but the description never says when to pick it over verify_audio or analyze_audio, nor any precondition (e.g., file must exist locally). Usage must be inferred.

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 destructive=true, idempotent=false, and openWorldHint=true, so the description earns credit for what it adds: the replacement is *atomic* (all-or-nothing, no partial snapshot) and the incoming metadata is *validated* before swapping. It still doesn't say what happens when validation fails or whether the prior snapshot survives a failure.

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 sentence with no filler, front-loading the fetch step before the mutation. Every clause (upstream, atomically, validated, offline) carries distinct meaning.

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 and annotations cover the safety profile, so much of the burden is lifted. However, for a destructive, network-dependent operation, the description omits failure behavior (validation rejection, upstream unavailable) and whether the old snapshot is recoverable — clear gaps even if the agent can still 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?

The single parameter is fully documented in the schema (coverage 100%), including the plan-versus-execute semantics of confirm. The description adds nothing about confirm, so baseline 3 applies — the schema is doing all the parameter work.

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 concrete two-step action (fetch upstream metadata, then replace the offline snapshot), which is far more specific than the tool name alone. It implicitly distinguishes itself from read-only siblings like verify_catalog or check_update, but never names an alternative 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?

The description explains what happens but not when to call it: no mention of when a refresh is needed versus verify_catalog, check_update, or list_updates, and no prerequisites such as network availability. The only usage signal comes from the structured fields (openWorldHint, destructiveHint), not the prose.

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=false, and the description adds genuinely useful scope: 'replace' signals overwrite semantics, while 'without moving its artifacts or refreshing upstream' bounds the blast radius the destructive hint leaves ambiguous. It does not mention the confirm/plan preview behavior, which would be the final piece.

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 tightly-written sentence with the action and its two key exclusions front-loaded; 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?

With a full output schema and rich annotations, the description covers the essential action and its non-effects. The only gap is not mentioning the dry-run/confirm path, which schema carries but a caller scanning descriptions might miss for a destructive operation.

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 are documented in-schema, including the important 'confirm=false returns its plan' semantics. The description adds no parameter-level meaning 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?

States a specific verb pair (register/replace) and resource (a local model), and carves out scope with 'without moving its artifacts or refreshing upstream', which distinguishes it from download_model and refresh_catalog. No sibling is named explicitly, 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?

'Register or replace a local model' implies the precondition that the weights already exist locally, and the negations hint at what this tool deliberately does not do. However, no alternative tool is named and there is no explicit when-not guidance (e.g. 'use download_model if the weights are not on disk').

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, readOnlyHint=false and non-idempotence, so the safety profile is covered. The description adds genuinely new behavioral context by disclosing what survives deletion (reused files, shared checkpoints), which is exactly the non-obvious fact an agent needs before invoking a destructive tool.

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

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

A single front-loaded sentence with zero filler; the scope limitation is stated before any caveat. Nothing in it could be cut without losing meaning.

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?

Safety annotations, a 100%-covered schema and an output schema carry most of the load, and the description covers the preservation behavior. But for an irreversible destructive operation it omits both the rerouting to unregister_model and any caution about the confirm/plan flow or what deletion does to dependents.

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

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

Schema description coverage is 100%, so both `slug` (catalog ID/filename/alias from list_models) and `confirm` (true executes, false returns the plan) are already fully documented. The description adds nothing about either parameter, 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 ("Remove") and a scoped resource ("owned artifacts"), and adds a distinguishing qualifier that reused files and shared checkpoints survive. That partially separates it from siblings like unregister_model (catalog-only removal), but it never names that sibling, so an agent comparing the two must still infer the boundary.

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 when-to-use guidance, no prerequisite, and no named alternative. The phrase "owned artifacts" implies a condition, but the agent is left to infer why it would pick remove_model over unregister_model — a directly adjacent sibling that removes a catalog entry rather than files.

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 destructiveHint=true, so the description's value-add is disclosing the dry-run path ('Plan or delete') and what the deletion achieves (fallback to bundled defaults). It still doesn't say whether the deletion is reversible or which profiles/settings are affected beyond the named one.

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 front-loaded sentence with no filler; the effect on future runs comes before any optional detail. Slightly compressed wording ('Plan or delete') costs a bit of clarity for its brevity.

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 no explanation, and the destructive nature plus dry-run mode are covered. What's missing is scope: whether only the named profile is deleted, where profiles live, and whether non-profile settings survive a reset.

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 are documented inline, including that name=None uses the default and confirm=false returns a plan. The description's 'Plan or delete' reinforces the confirm semantics but adds no new syntax or constraint beyond the schema.

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

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

States a concrete verb and resource ('delete a Maestro profile') plus the outcome ('future runs use bundled defaults'), which separates it from get_settings/set_settings. The phrasing 'Plan or delete' is slightly ambiguous about whether two operations exist, but the intent is recoverable.

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 stated effect ('future runs use bundled defaults') implies when to reach for it, but no alternative is named and no exclusion is given (e.g., use set_settings to change individual values instead of resetting). An agent must infer the boundary with set_settings.

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 cover readOnly=false, destructive=false, idempotent=false, and openWorld=false. The description adds useful behavior beyond the annotations: it awaits verified outputs and warns that long work should use start_separation; it does not detail timeout behavior or filesystem side effects, though output schema and schema descriptions carry some of that 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 primary action and immediately followed by the alternative. There is no wasted text.

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

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

The tool is complex with many nested options and writes outputs, but the description supplies the key selection and synchronous-await context. Input schema and output schema carry the detailed parameter and return semantics; the main minor gap is that 'verified outputs' is not further explained.

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 every parameter is documented in the input schema. The description adds no parameter-specific syntax, defaults, or selection advice beyond the start_separation routing hint, 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 pairs a specific verb ('Run') with a bounded resource ('one separation') and distinguishes single synchronous work from start_separation. It does not explicitly say 'audio' or call out every specialized separation sibling, but the scope is clear enough to select the 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?

The second sentence explicitly routes long work to start_separation, which implies this tool is for shorter or blocking runs. It lacks explicit exclusions against separate_ensemble, separate_chain, or separate_batch, but the 'one separation' framing distinguishes those cases.

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 readOnlyHint=false, so the safety profile is known. The description adds that results are aggregated and cancellation is supported, but it omits important behavioral context such as what files are written or that confirm=false returns a plan without side effects.

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

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

The single sentence is front-loaded and wastes no words. It is perhaps too terse for the tool's complexity, but it is structurally efficient.

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

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

Given a destructive batch operation with six top-level parameters and a large nested options object, a single sentence is insufficient. It should clarify batch scope, confirm semantics, and differentiation from single-file separation siblings even though schema and output schema carry much of the detail.

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 top-level parameters and the nested options are already documented in the schema. The description adds no parameter-specific meaning beyond the schema, which is acceptable at baseline 3.

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

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

The description states the verb and resource ('per-file separation') and mentions planning/queueing, so the basic purpose is inferable. However, it does not clarify how this differs from siblings like start_separation, separate_audio, or separate_ensemble, leaving the batch semantics vague.

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

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

There is no explicit guidance on when to use this tool versus the many sibling separation tools. The phrase 'Plan or queue' hints at confirm behavior, but no when-to-use, prerequisites, or exclusions are given.

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 is non-read-only, non-idempotent, non-destructive, and closed-world. The description adds useful operational context by saying the tool queues a chain and routes each step's output into the next, but it does not explain job behavior, async tracking, failure handling, or what 'queue' concretely means.

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

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

The description is a single front-loaded sentence with no wasted words. It is efficient, though its brevity contributes to gaps in routing and behavioral context.

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 complex multi-step mutation tool with up to eight chain steps, rich separation options, and several separation siblings, the description is too thin. The output schema and detailed input schema reduce the burden, but the definition still omits when to use this tool versus related separation tools and how queued chains are observed.

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

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

Schema description coverage is 100%, so the schema already documents audio_path, steps, output_dir, profile, keep_intermediates, and the nested options. The description adds nothing parameter-specific, which meets the baseline when the schema carries the parameter semantics.

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

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

The description uses a specific verb, 'Queue,' and a clear resource, 'cleanup/separation chain,' and explains that each declared source becomes the next input. It does not, however, distinguish this chain tool from siblings such as separate_ensemble or start_separation.

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 choose separate_chain over alternatives like separate_ensemble, start_separation, separate_audio, or separate_batch. The only implied usage is the chain shape itself, which is not enough to route an agent among siblings.

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 non-readonly, non-idempotent, non-destructive, and closed-world behavior. The description adds that the tool queues a job and must be polled, which is meaningful context beyond annotations, but it does not mention file writes, overwrite protection, or ensemble compatibility constraints that an agent might need to know before invoking it.

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

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

The description is two short sentences with no filler, and the purpose is front-loaded before the polling instruction. The word 'actual' is slightly awkward but does not meaningfully waste space.

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?

Because the input schema is richly documented and an output schema exists, the description does not need to explain return values. It does convey asynchronous queueing and polling, but for a complex ensemble tool it omits key context about compatible entries and algorithm selection, leaving it only minimally adequate.

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

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

Schema description coverage is 100%, so the schema itself documents all eight parameters thoroughly. The description adds no parameter-level meaning for entries, algorithm, options, or output_dir, 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 uses the verbs 'Queue' and 'combine' with the resources 'model runs' and 'matching sources', but 'matching sources' is vague and it never explicitly says this is audio source separation. It also does not distinguish the tool from siblings such as separate_audio, start_separation, or separate_chain, so the agent must infer ensemble behavior from the name alone.

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

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

'Poll get_job' gives a clear post-call step and implies asynchronous execution, which is useful. However, there is no explicit guidance on when to use this ensemble tool versus single-model separation siblings, and no when-not-to-use or alternative routing is 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 the safety profile (non-read-only, non-idempotent, non-destructive, closed-world), so the description need not repeat that. It adds useful information by saying the operation is queued and depends on vocal/BVE models, but it omits what queuing means operationally, such as job tracking or output side effects.

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

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

The description is a single front-loaded sentence with no extraneous text. Every phrase contributes to identifying the action and model roles.

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

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

The output schema and annotations carry much of the missing context, and the schema fully describes parameters. However, in a crowded sibling set of separation tools, the description leaves out routing guidance and useful job-lifecycle context, making it only minimally adequate.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description only gestures at the two model parameters and does not add format or selection guidance beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb and resource: 'Queue UVR's lead/backing vocal splitter.' It names the two model roles involved, making the split type discernible, but does not explicitly distinguish it from sibling separation tools such as separate_ensemble or separate_audio.

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

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

The description provides no guidance on when to prefer this tool over separate_ensemble, separate_audio, start_separation, or other separation siblings. It implies usage from the tool name and model mentions but includes no explicit alternatives or exclusions.

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

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

Annotations already declare destructive=true, idempotent=false, and readOnly=false. The description adds meaningful behavioral context beyond those flags: it validates and merges changes, and refuses to write without confirmation. It still does not specify merge depth, overwrite behavior for omitted keys, or validation failure behavior, so it is not 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?

A single front-loaded sentence with no wasted words. The key action and safety gate are stated immediately.

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, full parameter descriptions, and annotations covering the destructive profile, the description is complete enough for an agent to call the tool correctly. It still leaves the relationship to get_settings/reset_settings and merge semantics implicit, so it is not fully 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 description coverage is 100%, and the schema already documents name, values, and confirm in detail. The description adds only the concepts of profile changes and confirmation gating, which aligns with confirm but does not add syntax or format details beyond the schema. 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 specific verbs ('validate and merge') and a resource ('profile changes'), which distinguishes this mutation from sibling tools like get_settings and reset_settings. It does not explicitly name those alternatives, 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?

The description implies use when applying profile changes and notes a confirmation gate, but it does not explicitly say when to use this versus get_settings or reset_settings, nor does it state the prerequisite of retrieving values first. Usage is therefore implied rather than fully 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 declare non-readOnly, non-idempotent and closed-world, so safety is largely covered. The description adds the key trait annotations cannot express: execution is asynchronous and returns a queued job rather than results, with get_job as the completion path. It omits whether repeated identical calls create duplicate runs or how output_dir subdirectories are chosen.

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 filler. The async/queued outcome is front-loaded and the follow-up action is stated immediately after.

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

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

For a 6-parameter tool with a large nested options object and an output schema present, the essentials an agent needs before calling are only partly covered: the async job model is clear, but model/profile selection and output-directory semantics are left entirely to the schema and sibling list_models.

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%, including detailed descriptions for audio_path, model, profile, output_dir and every nested option, so the schema carries parameter meaning fully. The description adds nothing about parameters beyond the schema baseline.

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

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

States a specific verb and resource: 'Start one separation and return a queued job.' The word 'one' hints at the single-run scope versus siblings like separate_batch, separate_ensemble and separate_chain, though those siblings are never 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?

It gives a downstream workflow ('Poll get_job for verified files'), which is useful routing. However, it never says when to pick this over separate_audio, separate_ensemble or separate_batch, nor what prerequisites (model catalog, profile) are needed.

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 is not read-only, not idempotent, and non-destructive. The description adds useful behavioral context beyond annotations by saying the operation is queued and uses the Rubber Band algorithm while preserving pitch. It does not discuss job handling or failure modes, but the key async and pitch-preservation traits are disclosed.

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 filler. Every word contributes to conveying the operation, algorithm, and pitch-preservation behavior.

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 full schema descriptions, an output schema, and annotations covering safety traits, the description supplies the missing high-level context: queued processing and pitch preservation. It is nearly complete for this tool, though a brief note about it producing an asynchronous job could make the workflow clearer.

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

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

Schema description coverage is 100%, so the schema already documents rate, audio_path, and output_dir in detail. The description adds no parameter-specific information beyond the schema baseline, so a 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 specific verb and resource: queuing Rubber Band time stretching with pitch preservation. It is clear enough to distinguish from pitch_shift, though it does not explicitly name that sibling or other alternatives.

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

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

The phrase 'preserving pitch' implies the tool is appropriate when tempo should change without altering pitch, which contrasts with pitch_shift. However, there is no explicit guidance about when to use this rather than siblings like pitch_shift or separate_audio, and no when-not conditions are 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 destructiveHint=true and readOnlyHint=false; the description earns credit for clarifying what is NOT destroyed (weights and configuration remain on disk), which meaningfully bounds the destruction. It stops short of saying whether the action is reversible or that unregistering requires re-registration to restore catalog visibility.

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 with no filler; the key preservation guarantee is stated immediately after the action.

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, full schema coverage, and rich annotations, the description covers the essential risk profile. It could do slightly more by pointing at how to restore a registration or clarifying that reassembly of state is possible via register_model.

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

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

Schema description coverage is 100%, with both 'slug' and 'confirm' fully documented including the plan-vs-execute semantics. The description adds nothing about parameters, 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 ('Remove a local registration') and adds a scoping contrast ('preserving all original weights and configuration') that implicitly separates it from remove_model. It does not name the sibling explicitly, so the differentiation requires 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?

Usage is only implied: the preservation clause hints this is the non-destructive to the catalog option versus remove_model, but the description never states when to choose this over the alternatives or any prerequisites.

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, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds useful context that this is a listing of client-neutral workflow guidance accessible via uvr://skill/{name}, though it does not describe list behavior such as pagination or ordering.

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 sentence with no wasted words, and the key information 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?

Given zero parameters, complete annotations, and an output schema, the description is largely complete for a read-only list tool. It identifies the resource and URI pattern, though a bit more context about what a 'skill' represents could improve clarity.

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 the baseline is 4. The description does not need to explain parameter semantics beyond the URI template pattern, which it already mentions.

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

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

The description uses a clear verb ('List') and specific resource ('client-neutral workflow guidance available through uvr://skill/{name}'). It tells the agent what the tool returns at a high level, though it does not differentiate this tool from any sibling.

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

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

The description provides no explicit guidance on when to use this tool, when not to use it, or which sibling tools are alternatives. Usage is only implied by the word 'List' and the URI pattern.

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, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is fully covered. The description adds that results reflect 'last measured' backend support, hinting at cached rather than freshly probed data, but it doesn't state whether the call triggers any live measurement or how current the data is.

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 short sentence with the key subjects front-loaded and no filler. It is efficient, though the compressed noun phrasing ('last measured backend support') costs a little interpretability.

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 the zero-parameter schema imposes no burden. The remaining gap is modest: vague domain terms ('engine readiness', 'backend support') would benefit from a phrase of clarification for an agent unfamiliar with the tooling.

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 is 4 — there is no parameter meaning to supplement and nothing is missing on that axis.

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?

A specific verb (Report) with three named subjects: engine readiness, model roots, and last measured backend support. That clearly marks this as a diagnostic/status tool, distinguishing it from list_models or get_settings, though the terms 'engine readiness' and 'backend support' are left undefined.

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 a pre-flight or troubleshooting check, but the description never says when to call it versus get_settings, list_models, or verify_catalog. No exclusions or alternative routing are given.

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 cover safety (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the failure condition — empty or non-finite samples cause rejection — plus the cost signal that the entire file is decoded in blocks. That is meaningful behavioral context beyond the structured fields, though it says nothing about what a partial/failed decode returns.

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 no filler, and the primary action (decode the complete file) is front-loaded ahead of the rejection rule. It is arguably too terse rather than padded, which is a different problem than verbosity.

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, full parameter coverage, and annotations present, the description carries a lighter burden and does cover the core action and one failure mode. What is missing is the routing information an agent needs among the several audio-inspection siblings (probe_audio, analyze_audio), leaving a real gap for a one-param tool in a crowded namespace.

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 is one parameter with 100% schema description coverage, so the schema already explains that audio_path is an absolute or caller-relative local file path. The description adds nothing about the parameter, which is acceptable at this coverage level but earns only the baseline.

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

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

The description gives concrete mechanics (decode the complete file in blocks, reject empty or non-finite samples) from which an agent can infer this validates audio decodability, but it never states the purpose directly as "verify an audio file decodes cleanly." It also does nothing to distinguish itself from close siblings like probe_audio or analyze_audio, so the agent must guess which validation tool applies.

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 (e.g., file must exist locally), and no mention of alternatives such as probe_audio or analyze_audio. The agent is left to infer the selection criteria 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 already declare readOnly/idempotent/non-destructive with a closed world, so safety is covered. The description adds the substance of the checks (trusted hashes, orphan weights), though the word 'refresh' sits awkwardly against readOnlyHint and could make an agent wonder whether it mutates the installation record.

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 tight sentence with the actions front-loaded and no filler. It is perhaps too compressed — three distinct checks crammed into a clause list with no grouping or outcome framing.

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 no explanation, and there are no parameters to document. What is missing is the relationship to siblings and the failure semantics (what 'orphan weights' means for the caller, whether remediation is expected).

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 schema has nothing to explain and the description need not compensate. The baseline of 4 applies; the description correctly implies a whole-catalog, no-argument operation.

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

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

The description names three concrete activities (refresh installation state, check trusted hashes, report orphan weights), which is more specific than the tool name alone. But 'verify_catalog' versus the sibling 'refresh_catalog' is not distinguished, and 'refresh installation state' duplicates what a sibling name suggests, leaving the actual verification scope ambiguous.

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

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

There is no indication of when to call this versus refresh_catalog, verify_audio, or check_update — all plausible neighbors in the sibling list. The agent has to guess whether this is a pre-download integrity check, a post-install validation, or a maintenance sweep.

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