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

Annotations already establish readOnly/non-destructive/local scope, so the bar is lower; the description still adds real value by bounding the claim — it explicitly does not start recording and does not verify that live call audio is connected. That caveat prevents an agent from over-trusting the result as proof of a working audio path.

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 that packs scope, coverage, and explicit limitations with no filler. 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 zero parameters and an output schema present, the description need not explain return values, and its scope/limitation statement is sufficient. It is complete enough for correct invocation, though a hint about what '阻塞原因' surfaces in the response would add marginal value.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4; the description correctly adds no bogus parameter guidance and instead frames the call as a parameterless status probe.

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

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

Names a specific verb (检查/check) and enumerates the concrete resources inspected: local RVC engine, models, audio configuration, and blocking reasons. The negative clause (不启动录音) distinguishes it from start_voice_audio, so an agent can separate it from siblings without opening schemas.

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 as a diagnostic pre-check (it reports blocking reasons before audio starts), and the exclusion of recording is stated. However, it never says when to prefer this over siblings like list_local_models or list_voice_models, nor 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, openWorldHint=false. The description goes beyond that by bounding side effects: it does not deserialize weights, does not auto-import, and does not judge compatibility. That clarifies the tool is a pure filesystem listing, which is genuinely useful context an agent could not derive from the annotations.

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 semicolon-delimited sentence: the positive scope first, then the negative boundaries. Zero filler and fully front-loaded.

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

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

With an output schema present, return values need no explanation, and zero parameters means no input documentation is required. The description covers scope and side-effect boundaries adequately; only the relationship to sibling model-selection tools is left 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to clarify. The description instead documents what the listing covers, which is the closest analogue to parameter semantics for a no-arg tool.

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 (配置目录里的 .pth 和候选 .index 路径), so an agent immediately knows this enumerates local model artifacts rather than voice state. It does not explicitly distinguish itself from sibling tools like list_voice_models or select_voice_model, which is the only gap.

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 discover local .pth/.index files before selecting or loading a model. There is no explicit when-to-use statement, no named alternative, and no exclusion, so an agent must infer the discovery-then-select workflow from context 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?

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that only slots that are imported and compatible with the engine are returned, which is useful scoping. Even so, it says nothing about ordering, whether empty results are possible, or how the slots relate to the pitch and index controls.

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 and has no wasted text. It front-loads what the tool returns, then gives the action the agent should take next.

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, and an output schema exists, so the description does not need to enumerate the return values. What it covers (what the list contains and its intended downstream use) is enough to call the tool correctly. The only minor gap is the absence of stated ordering or emptiness behavior.

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 behavior for the description to explain. The description correctly does not claim any input, and instead focuses on what the returned slots are for.

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

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

The description gives a specific verb and resource: it lists RVC model slots imported by the compatible engine, and it states the scope in a way that separates the tool from sibling list_local_models. It doesn't name the sibling, so an agent has to infer the difference from the 'RVC model slots' phrasing, but the purpose is nonetheless clear.

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

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

The second sentence, “请用返回的槽位选择角色,” implies that the returned values are meant to feed a selection step, most likely select_voice_model. It never explicitly names the follow-up tool, nor does it state when to prefer this tool over list_local_models, leaving the routing implicit.

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

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

Annotations cover the safety profile (readOnly=false, idempotent=true, destructive=false), so the bar is lower, and the description still adds a real side-effect disclosure: audio routed to the virtual line is silenced. It does not mention permissions, latency, or state-checking, but the effect on the user's audio is the key behavioral fact and it is present.

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 states the action and its effect, followed by the recovery path. No filler, though the packed second clause about bypass/headphone output is slightly dense and could be split for readability.

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 mutation with an output schema present, the description supplies what the schema cannot: the audible consequence and how to revert. It omits any notion of error conditions or whether the pause persists across sessions, but is otherwise 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate — baseline 4 applies. The description correctly avoids inventing 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?

States a specific verb+resource (pause the engine audio) and describes the concrete effect — Dots routed to the virtual line go silent. It references sibling tools for the reverse operation, giving useful contrast, though it never explicitly frames itself against start_voice_audio as the direct pair.

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

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

Gives guidance for undoing the action ('use bypass and start, or manually switch back to headphone output'), which names alternatives, but provides no guidance on when to choose pause over set_voice_bypass in the first place. Usage is implied 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 non-readonly, idempotent, non-destructive, closed-world behavior; the description usefully adds that the selection state is read back and that warm-up success is not guaranteed. That is genuine behavioral context beyond the annotations.

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

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

A single compact sentence that front-loads the action and the precondition, then lists the two non-guarantees. No filler.

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

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

An output schema exists, so return values need no explanation, and the description covers the precondition and behavioral limits well. The only real gap is the meaning of 'slot'.

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 'slot' parameter has 0% schema description coverage, and the description never explains what a slot is (index into the imported model list? a fixed channel?). With one undocumented required parameter, the description does not compensate for the schema gap.

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

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

States a specific verb+resource: selecting an already-imported RVC model, with the added constraint that the engine audio must be paused. It is distinguishable from siblings like list_voice_models and start_voice_audio, though it does not name 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?

Gives clear when-to-use context ('while engine audio is paused') and negative scope ('does not start audio', 'does not guarantee warm-up success'), which steers the agent away from expecting playback. It stops short of naming which sibling to call instead for those goals.

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 (readOnlyHint=false, idempotentHint=true, destructiveHint=false). The description adds genuinely non-obvious side-effect context: the engine start/stop state is preserved and Windows audio routing is untouched. That is real behavioral value beyond structured fields.

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

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

A single dense sentence with the action front-loaded and the two constraints (engine state, routing) appended. No filler, though the semicolon-clause structure is slightly packed.

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 described. Given it is a non-destructive, idempotent toggle whose side effects and state preservation are disclosed, the definition is complete enough for correct invocation.

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

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

Schema coverage is 0% and the single boolean is documented only as 'Enabled'. The description compensates by defining the polarity semantically: true = original-voice bypass, false = use RVC. That maps the boolean to real behavior, which the schema alone does not.

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

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

States a specific verb+resource ('set voice bypass') and explains the two directions: enabling routes the original voice through, disabling routes through RVC voice conversion. This distinguishes it from the audio/model siblings, though it doesn't name a specific alternative 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 two-state behavior implies when each mode applies, but there is no explicit when-to-use guidance versus siblings like start_voice_audio or select_voice_model, and no prerequisites stated. 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 this is a non-readonly, idempotent, non-destructive write, and the description is consistent with that (idempotent 'set', no destruction). It adds one behavioral constraint (the 0-only case without an index file) but does not explain persistence, latency, what the ratio actually affects, or side effects on voice behavior. Adds some value beyond annotations but not rich context.

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

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

A single front-loaded clause carries the action and its constraint with zero filler. Every element earns its place and the key rule is stated before the edge case.

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 description need not explain return values, and it does supply the value constraint. But it gives no context on what the retrieval ratio governs, why it is bounded at 1, or how it interacts with the voice/index subsystem, leaving meaningful gaps for a mutation tool.

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

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

Schema description coverage is 0% and the single 'ratio' parameter has no schema-level documentation, so the description carries the burden. It compensates by stating the valid range (0–1) and a conditional validity rule tied to the presence of an index file, which is genuine semantic content. It still doesn't define the unit or the underlying meaning of the ratio, so it is good but not complete.

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 (set) and resource (the current character retrieval ratio) with a clear value range of 0–1, so an agent knows exactly what the tool configures. It does not distinguish itself from any sibling, but the siblings cover unrelated operations (pitch, bypass, model selection), so differentiation is implicit rather than stated.

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

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

Provides a real conditional rule — when no index file exists only 0 is permitted — which is meaningful when-to-use guidance for the value. However it offers no comparison to alternatives and no broader context on when this setting should be changed versus left alone, leaving usage largely implied.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false. The description's 'absolute, not cumulative' note reinforces idempotency and is genuinely useful, but it says nothing about out-of-range handling (error vs. clamp) or whether the change applies live to running audio.

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

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

One compact sentence separated by a semicolon: the core action and range come first, the absolute-vs-cumulative clarification second. No filler.

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

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

An output schema exists, so return values need no explanation, and the sole parameter's range and semantics are covered. The only meaningful omission is what happens when a value outside -24..24 is supplied.

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

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

Schema coverage is 0% and the single required parameter is undocumented in the schema, so the description must carry the burden. It supplies the unit (semitones) and the valid range (-24 to 24), which is exactly what's needed; only the out-of-range behavior remains unspecified.

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

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

States a precise verb (set) plus the exact resource (the current RVC character's pitch offset) and its valid domain (-24 to 24 semitones). No sibling (set_voice_index_ratio, set_voice_bypass, etc.) could be confused with this operation.

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 imperative 'set' against a clearly scoped resource, and the note that it is absolute rather than cumulative helps disambiguate behavior. However, it never states when to call this versus other voice-setting siblings or any preconditions (e.g., a model must 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 cover the safety profile (non-readonly, idempotent, non-destructive), so the bar is lower. The description still adds real behavioral value by disclosing that the result merely confirms configuration rather than verifying audible playback, and that CABLE Output must be pre-configured.

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

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

Two short sentences with the action stated first and the prerequisite/caveat second; no filler. Slight redundancy in repeating '已配置' for both input and output, but otherwise tight.

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 description's note that the result only confirms configuration is a helpful complement. What remains missing is the sequencing relative to sibling tools (model selection, routing setup), but for a zero-parameter start call the coverage is largely sufficient.

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

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

With zero parameters the baseline is 4; the schema has nothing to document. The description usefully notes that the required inputs (model and routing) are not passed here but must already be configured elsewhere, which is meaningful context given the empty schema.

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

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

States a specific verb (start/play) plus the resource (the voice audio engine reading CABLE Output and playing to the configured output), which is clear enough to distinguish from the inverse sibling pause_voice_audio. It stops short of naming siblings, but the action 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?

It gives a prerequisite ('needs a model and full routing configuration'), which is useful context for when the call will succeed, but it never states when to prefer this over pause_voice_audio or what to do first (e.g., select_voice_model). Usage is implied rather than spelled out.

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