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

Beyond the annotations, the description discloses important behavioral traits: it refuses an existing exact name, verifies returned ID/ownership/privacy, preserves other playlists, and never retries uncertain results automatically. This gives the agent critical safety and side-effect information that annotations alone do not provide.

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 compact and front-loaded with the core purpose, then adds necessary prerequisites and behavioral caveats. Every sentence contributes useful information without redundancy or filler.

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

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

Despite leveraging an output schema, the description covers prerequisites, failure conditions, verification behavior, and side-effect expectations. For a create operation with two parameters, this is complete enough for an agent to invoke it correctly and anticipate outcomes.

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 schema has no parameter descriptions, so the description carries the burden. It adds meaning for the 'name' parameter by noting that an existing exact name is refused, and for 'isPrivate' by stating that private is the default. While it does not fully explain all boolean semantics, it compensates well for the 0% schema description coverage.

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 ('Create') and resource ('empty owned playlist') and clearly distinguishes this from sibling tools like netease_list_playlists, netease_delete_playlist, and netease_set_liked. It also includes key scoping details ('after user authorization', 'Private by default') that make the tool's purpose 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?

The description gives clear invocation context: it requires user authorization and the NETEASE_ENABLE_PLAYLIST_CREATE=1 flag, making it easy to know when this tool applies. It does not explicitly name alternatives or state when not to use it, but the sibling names and the create-vs-manage operation make the selection obvious.

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

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

The description adds substantial behavioral detail beyond the annotations: the token is consumed once, the operation rechecks account and playlist attributes, verifies removal and preservation of other playlists, never auto-retries, and backups cannot restore original IDs or followers. This is excellent disclosure for a destructive, non-idempotent 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?

The description is dense and well-structured: precondition first, then the core action, then verification and safety constraints. Every sentence adds meaningful information without fluff.

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 destructive single-use operation, the description covers authorization, token consumption, verification, non-retry behavior, and irreversibility caveats. An output schema exists, so return value documentation is not required. The only minor implicit detail is the source of the token, but the sibling list makes that clear enough.

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%, but the description compensates by explaining that the token is a deletion preview token, tied to ownership and single-use consumption. It does not explicitly state where the token comes from or its expiry, but the uuid format and pattern in the schema cover the validation aspects.

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

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

The description clearly states a specific action: consume a deletion preview token and delete an owned playlist once. It distinguishes this from siblings by emphasizing it is the final deletion step, not preparation, listing, or status checking.

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 clear usage context: use only after explicit user authorization and with a deletion preview token. It also forbids automatic retries on uncertain results. It does not explicitly name the prerequisite sibling prepare_playlist_delete, but the token language strongly implies the required flow.

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/idempotent/non-destructive behavior. The description adds valuable beyond-annotation context: null means unknown, and trackKey is a hash of visible label rather than a unique catalog ID, preventing misuse. No contradictions.

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 concise sentences front-load the core purpose and immediately add essential interpretive caveats. Every clause earns its place; no filler.

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

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

With zero parameters, rich annotations, and an output schema present, the description covers the key semantic pitfalls (null meaning and trackKey identity limits). Nothing critical is missing 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?

The tool has zero parameters, so the baseline is 4. The description appropriately focuses on output semantics rather than params, and the empty schema leaves nothing undocumented.

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

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

Description states a specific verb ('Read') and resource ('current visible song label, playback and heart state'), clearly distinguishing it from the mutation/search siblings. It also adds meaningful semantics about null and trackKey, making the tool's scope 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?

Clear context is provided: this is the read/status tool among siblings that perform search or mutations. It does not explicitly enumerate exclusions or alternatives, but the 'current visible' framing makes its intended use obvious.

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 provide readOnly/idempotent/non-destructive guarantees. The description goes beyond them by disclosing additional behavioral traits: no mouse/focus/navigation side effects and omission of account identifiers. This is valuable context for an agent controlling a desktop client.

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

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

Three short sentences, each with a distinct purpose: scope/action, UI safety guarantee, and parameter omission. The key action is front-loaded and there is no filler or redundant restatement of the tool name.

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

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

For a no-parameter tool with rich annotations, an output schema, and a precise scope statement, the description covers operation, side-effect behavior, and input context. Nothing needed for correct invocation is missing, and the output schema covers return-value details.

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

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

The tool has zero parameters and the schema coverage is trivially 100%. The description adds meaning by explaining that account identifiers are omitted, which clarifies why no parameters are required and prevents the agent from attempting to pass an account ID.

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 the specific verb 'Refresh' and a concrete resource ('owned, collected and system playlists') within the desktop client. This clearly distinguishes it from sibling mutation tools like netease_create_playlist and netease_delete_playlist.

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 clear context by positioning this as the playlist-refresh operation and explicitly states it does not move the mouse, focus, or navigate, so it is safe to invoke without disrupting the UI. It does not name alternatives or exclusions, but no sibling tool covers the same list-refresh purpose, making the intended use unambiguous.

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

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

Adds meaningful behavior beyond the annotations: it refuses changed/stale rows and clarifies that success only means the UI shows the chosen title/artist playing, not audible output. This is useful context that readOnlyHint and destructiveHint do not convey.

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

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

Three sentences with no filler. The core action is front-loaded, and every sentence adds necessary information such as preconditions, stale-row behavior, and the success caveat.

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

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

Covers purpose, stale-row behavior, and the success caveat, and an output schema exists so return values needn't be described. It lacks only an explicit pointer to where the token/index originate and how to route generic playback requests to netease_set_playback.

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

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

Schema description coverage is 0%, so the description must compensate, but it only restates 'token and string index' without detailing that searchToken comes from netease_search responses or how index maps to row position. It provides some meaning but leaves parameter semantics mostly to schema names and format.

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: 'Play an exact row from the latest search.' The exact-row/latest-search qualifier distinguishes it from generic playback (netease_set_playback) and search (netease_search), so an agent can infer what this tool is for.

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 clearly sets preconditions: requires a search token and string index, and only works on the latest search by refusing changed/stale rows. It does not explicitly name when-not-to-use or alternatives, but the intended context is evident.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description adds critical behavioral details: the token is single-use and valid for two minutes, protected playlists are refused, and 'Preview is not user consent.' This prevents the agent from assuming the preview itself authorizes deletion.

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

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

Three compact sentences front-load the core action and token outcome, then add prerequisites, exclusions, and the important consent caveat. No word is wasted.

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

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

The description covers prerequisites, matching criteria, protected cases, token validity, and the non-consent warning. Since an output schema exists, describing the return shape is unnecessary, and the two required parameters are addressed sufficiently 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?

With zero schema description coverage, the description carries the burden of explaining parameters. It maps id and expectedName to 'an exact owned playlist ID and name', adding meaning beyond the bare schema. It could be more explicit that expectedName must match the current playlist name exactly, but the existing wording is a meaningful improvement.

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

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

The description clearly states the tool's verb and resource: it previews deletion of an exact owned playlist by ID and name. It adds that it returns a single-use token, which distinguishes this preparation step from the sibling netease_delete_playlist that would actually perform deletion.

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 useful usage context: it requires NETEASE_ENABLE_PLAYLIST_DELETE=1, only works on exact owned playlists, and refuses collected, system, or configured protected playlists. It does not explicitly name an alternative such as netease_delete_playlist or state 'use this before deleting', but the preview-and-token flow makes the intended usage clear.

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

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

Beyond the annotations, the description discloses that the tool changes the visible search page, returns only a partial list, and issues a token valid for two minutes in the session. It also clearly states it does not play music, adding non-obvious behavioral context. No contradiction with 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?

Three short sentences with the main action first, followed by side effects and a clarifying non-goal. Every sentence adds distinct value and there is no filler.

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

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

For a two-parameter search with an output schema, the description captures purpose, side effect, token validity, and a non-goal. The main gap is the absence of any parameter semantics, which is already penalized separately; overall it gives an agent enough to invoke and reason about results.

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

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

Schema description coverage is 0%, so the description should clarify query and limit. It mentions 'partial list' which hints at a limit, but never explains what query should contain or how limit controls results. This leaves the agent to guess parameter meaning.

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

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

The opening 'Search songs in the desktop UI' names a specific verb and resource, and the closing 'Does not play music' explicitly delimits what the tool is not for. This is enough to set it apart from playback siblings like netease_play_result.

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 useful context: it mutates the visible search page and returns a token valid for two minutes, implying it is for initiating searches rather than playback. It never names sibling tools or conditions for choosing them; the only exclusion is the non-goal statement.

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

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

The description adds useful behavioral context beyond the annotations: visible UI verification is not server-side persistence verification, and the tool refuses stale or inconsistent state. With readOnlyHint=false and destructiveHint=true, the mutation context is already implied; the description adds meaningful caution about relying on UI feedback.

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

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

Four short, dense sentences, each earning its place. The core instruction is front-loaded, followed by prerequisites, refusal behavior, and verification caveat. No filler or redundant restatement of the tool name.

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

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

Given only 2 simple parameters, an output schema, and sibling context, the description covers purpose, usage conditions, parameter sourcing, and verification caveats. Nothing essential for an agent to invoke the tool correctly appears to be missing.

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

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

Schema description coverage is 0%, so the description carries the burden. It adds the critical semantic that trackKey must come from a fresh status result, and frames `liked` as the heart state. This is useful beyond the bare boolean/string schema, though it could explain the liked-to-heart mapping more explicitly.

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—setting the current song's heart/liked state—with a clear resource target. It is distinguishable from the sibling tools like netease_set_playback and netease_skip_track, though it does not explicitly name a sibling to differentiate against.

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 clear when-to-use guidance: only when explicitly requested, and requires a fresh status result for trackKey. It also notes refusal conditions for unknown heart state or changed labels. It stops short of naming alternative tools or contrasting them directly.

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 communicate mutation, idempotency, and openness, but the description adds valuable behavioral detail: it verifies UI state, does not blindly toggle, and refuses when the UI state is unknown. This is meaningful context beyond the structured annotations and helps the agent predict failure behavior.

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 compact and front-loaded. The first sentence states the core purpose, and the next two add important caveats without redundancy. Every sentence earns its place.

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

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

For a simple one-parameter tool with an output schema and meaningful annotations, the description is nearly complete. It covers the intended action, the refusal behavior, and the verification aspect. It could be slightly stronger by explicitly pointing to netease_get_status for checking unknown UI state before calling this tool, but the need is reasonably implied.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'play or pause,' which maps directly to the action enum, and 'does not blindly toggle' clarifies that the action values are absolute target states. However, it does not explicitly name the action parameter or explain its requiredness, leaving much to 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 clearly states the tool's function: explicitly play or pause and verify the UI state. It is specific about the verb and resource, but it does not explicitly distinguish itself from sibling tools like netease_play_result or netease_get_status, so it falls short of full sibling 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 clear context: use this tool when you need an explicit play or pause, not a blind toggle. It also implies a prerequisite—unknown UI state is refused—so the agent should confirm state first. However, it does not explicitly name an alternative or say 'use netease_get_status first'.

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

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

The description discloses meaningful behavior beyond the annotations: it performs a single skip, verifies a visible song label, reports unchanged labels as unverified, and explicitly prohibits automatic retries. These details are not captured by readOnlyHint, openWorldHint, idempotentHint, or destructiveHint.

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, no filler, and the main action is front-loaded. The second sentence adds a critical edge-case instruction without bloating the description.

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

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

For a simple one-parameter tool with an output schema and clear annotations, the description covers the action, the verification expectation, the failure/edge-case reporting behavior, and the retry policy. Nothing essential is missing.

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

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

The input schema has one enum parameter, 'direction', with no property descriptions. The description compensates by linking the direction values to the effect ('Move to next/previous track once'), giving the agent enough semantic grounding to select 'next' or 'previous' correctly.

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 ('Move to next/previous track once') and a clear resource ('track'), with an additional verification behavior that distinguishes it from broader playback tools like netease_set_playback. It is immediately obvious what the tool does and how it differs from siblings.

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 clear operational guidance: perform the skip exactly once, verify the label change, treat unchanged labels as unverified, and do not retry. It lacks an explicit comparison to alternatives such as netease_set_playback, so it stops short of full when/when-not coverage.

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