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

Annotations already characterize this as a non-readonly, non-destructive mutating operation. The description adds valuable context beyond the annotations: it targets the official Mac client and requires accessibility permissions, which informs likely failure modes. It does not detail toggle behavior or no-op conditions, but the core side effect is transparent.

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

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

One compact sentence that front-loads the action and target, then states the critical permission requirement. Every word earns its place; there is no filler or redundant restating 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 simple single-parameter control tool with annotations covering the safety profile, the description covers the target client, the available actions, and the key prerequisite. It could add a note about behavior when the client is not running, but given the low complexity, this is a minor gap rather than a serious 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 0%, so the description carries the burden of explaining the single 'action' parameter. It compensates by listing the three actions in Chinese (播放/暂停、上一首或下一首), which maps directly to the enum values play_pause, previous, and next. For a self-explanatory enum, this is sufficient.

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 (控制/control) and resource (官方 Mac 客户端 / official Mac client), and enumerates the exact actions: play/pause, previous, next. This clearly conveys what the tool does and differentiates it from most siblings like netease_launch or netease_status, though it does not explicitly contrast with the potentially overlapping netease_next_track.

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 mentions a prerequisite (macOS accessibility permission) but gives no guidance on when to use this tool versus alternatives. Since netease_next_track exists as a sibling, the absence of any exclusion or selection criterion leaves the agent to guess which one to invoke for 'next'.

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 is transparent about the platform constraint and the error condition, which is a side-effect of the tool's behavior. The annotations (readOnlyHint=false, destructiveHint=false) align with a state-changing but non-destructive launch operation; there is no contradiction.

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

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

The description is a single concise sentence that directly conveys the action, target, and platform limitation without any redundant wording. It is well-structured and easy to parse.

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

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

Given the lack of parameters and output schema, the description covers the essential context: what the tool does, on which platform, and what happens on unsupported platforms. Success behavior is implicitly understood as launching the client.

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 no parameters, so schema coverage is complete by default. The description accurately reflects this, requiring no additional parameter explanations.

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 purpose: launching the installed official NetEase Cloud Music client via the macOS adapter. It distinguishes this from sibling tools that handle playlists, song details, or playback control, making the action 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 explicitly notes that on non-macOS platforms, a clear capability error will be returned, guiding the user on platform compatibility. While it doesn't mention alternatives like netease_control for playback, the launch action is sufficiently distinct to be understood.

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 readOnlyHint annotation already signals non-mutating behavior, and the description adds value by disclosing platform-dependent behavior: the macOS adapter can open invites, while interactive capabilities depend on the official mobile client. This goes beyond the structured 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?

Two short, front-loaded sentences deliver the essential purpose and platform nuance 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?

For a zero-parameter read-only capability check, the description is mostly complete: it states what is checked and notes platform constraints. It stops short of describing the return value or result format, but the tool is simple enough that this is a minor gap.

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

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

The tool has zero parameters, so the schema leaves nothing for the description to clarify. The description appropriately focuses on what the tool checks rather than parameter details.

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 '检查' with a clear resource '当前设备的一起听能力', making the tool's purpose unambiguous. It also implies a distinction from the sibling 'netease_listen_together_invite' by focusing on capability inspection rather than invitation action.

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 platform context ('macOS 适配器可打开邀请；互动能力取决于网易云官方移动端'), which implies the tool should be used to check whether an invite can be opened or interactive features are supported. However, it never explicitly tells the agent when to choose this tool over netease_listen_together_invite.

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 mark this as non-read-only, open-world, and non-idempotent. The description adds valuable context beyond annotations: it operates through a macOS adapter, requires explicit user confirmation, and leaves friend selection to the user in the client. This clarifies what the tool does and does not do, without contradicting 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?

Two tight sentences: the first states the action, the second states the prerequisite and the user's role. Every sentence earns its place, with no filler or redundancy.

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 UI-launch tool with no output schema, the description provides the action, platform, precondition, and user responsibility boundaries. It doesn't mention whether a listen-together session or capability check is needed first, but that is a minor omission given the tool's simplicity.

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 zero parameters, so schema description coverage is effectively 100%. The description goes beyond the empty schema by explaining that friends and sharing method are selected by the user in the client, which tells the agent that no parameters should be supplied and why they are absent.

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 action: open the 'Listen Together' invitation interface through the macOS adapter. It is specific about the resource and effect, and it is clearly distinct from sibling tools like netease_listen_together_capabilities or netease_control, which handle different aspects.

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 an explicit precondition: only call after confirming that the user explicitly wants to initiate an invitation. It also indicates that friend selection and sharing method are chosen by the user in the client, so the agent shouldn't ask for those details. It doesn't name alternative tools, but the triggering condition is 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?

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds behavioral detail beyond the annotations by specifying that no audio is downloaded and by enumerating the returned content types (LRC, translation, romaji). It omits error/auth/rate-limit behavior, so it is not a 5, but it provides meaningful extra transparency.

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 compact clauses with no filler. It front-loads the core action and resource, and the exclusion is appended efficiently. Every word earns its place.

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

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

For a single-parameter, read-only tool with no output schema, the description covers the input (song ID), the returned content (LRC, translation, romaji), and the notable non-behavior (no audio download). It could mention error cases or response format, but those are minor gaps for such a simple 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%, so the description must compensate. '按歌曲 ID' confirms that the sole parameter songId is the lookup key for the lyrics, adding some meaning beyond the property name and regex pattern. It does not explain how to obtain a song ID or give additional guidance, which keeps it at an adequate but not rich level.

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 ('读取' / read) and a precise resource (LRC, translation, and romaji lyrics) accessed by song ID. It further distinguishes itself by explicitly noting it does not download audio, which separates it from audio-related 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 makes the target use case clear: fetch lyrics for a given song ID. It also gives a clear exclusion ('不下载音频'), but it does not name an alternative tool for downloading audio, so it stops short of full alternative routing.

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 show readOnlyHint=false and idempotentHint=false, so the agent knows this is a mutating, non-idempotent action. The description adds useful context: it is a 'direct' command to the 'current' player and does not control the screen, clarifying the mechanism and scope. It does not describe error behavior, but for this simple action the added context is meaningful.

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, both informative. The first states the action, the second defines applicability boundaries. No filler or repetition, front-loaded with the core 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?

For a zero-parameter, no-output-schema action tool, the description covers the action, the target, and the critical exclusions (screen control and listen-together). It does not state prerequisites like the player being active, but given the simplicity and the sibling context, it is largely 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?

The input schema has zero parameters, so there is nothing for the description to explain about parameters. Baseline for 0 params is 4, and the description appropriately focuses on the action and scope rather than parameter details.

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 and object: '向当前网易云播放器发送下一首命令' (send next-track command to the current NetEase player). It explicitly distinguishes itself with '不操控屏幕，也不用于一起听房间', separating it from screen-control and listen-together sibling tools.

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

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

The description clearly states when to use it: '仅用于普通播放' (only for normal playback). It gives explicit when-not conditions by excluding screen control and listen-together rooms, but it does not name the alternative sibling tools that should be used in 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?

The description adds the useful behavioral fact that only preset orpheus:// routes are allowed, which the annotations do not cover. However, it does not disclose other behavioral traits such as whether the NetEase client must already be running or what UI side effects occur. The annotations are sparse and not contradictory.

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 concise sentence with the target areas listed first and the route restriction immediately after. No filler, every clause adds useful information.

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

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

For a simple one-enum navigation tool, the description plus schema cover target selection and the core restriction. The lack of an output schema is acceptable for a UI-navigation action. A note on whether the client must be launched first would be a minor improvement.

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 bears the semantic burden. It maps the enum values to understandable targets: private FM, downloads, and song recognition. This helps an agent select the correct 'area' value, though it does not document the exact orpheus:// URI mapping.

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 '打开' with a clear resource: the NetEase function page, listing the exact areas (private FM, downloads, song recognition). It distinguishes itself from content/control siblings through the 'orpheus:// route' constraint, but does not explicitly name any sibling tool for contrast.

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 about when to use this tool versus netease_launch or netease_open_entity. The description states a route restriction, which is a constraint, not usage direction. An agent must infer from the area names and sibling names when this tool is the right choice.

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 indicate the tool is not read-only, opens the external world, and is non-destructive. The description adds a useful technical detail about the macOS adapter, which implies platform-specific behavior not covered by annotations, but does not disclose side effects like client focus changes or failure behavior if the client is not running. This is adequate given annotation coverage.

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, concise sentence that front-loads the primary action and resource types, with zero waste. It efficiently conveys the core functionality without redundancy.

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 open action with only two parameters and no output schema, the description is adequate. It specifies what is opened and the mechanism (macOS adapter). While it could mention prerequisites like client installation, the simplicity of the tool means the description is sufficiently complete for an agent to call it correctly.

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

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

Schema coverage is 0%, but the description explicitly lists the allowed types (song, playlist, album, artist), which partially maps to the type parameter enum. It does not explain the id parameter beyond being an identifier, but for a simple two-parameter tool, the description provides enough context to infer usage without fully compensating 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?

Description clearly states the action (open) and the specific entity types (song, playlist, album, artist) via the official client, which distinguishes it from sibling tools like netease_open_area (which opens a different area) and netease_launch (which launches the app). The verb and resource are explicit and 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?

No guidance is provided on when to use this tool versus alternatives such as netease_song_detail or netease_search. There is no mention of prerequisites or exclusions, leaving the agent to infer that this is for opening pages without any comparative context.

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 and destructiveHint=false. The description adds a safety-relevant behavior: '修改前会再次校验歌单归属' (re-validates playlist ownership before modifying). This is useful but does not disclose other behaviors such as duplicate handling, rate limits, or partial success behavior. It does not contradict 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?

One concise sentence that states the core action, quantity range, ownership constraint, and a behavioral safeguard. 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?

For a mutation tool with no output schema, the description covers the essential context: what it does, range, and ownership validation. It does not explain failure modes or duplicate behavior, but for a simple add-to-playlist operation this is reasonably complete.

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

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

Schema coverage is only 33%, so the description must compensate. It explains that songIds must be 1–100 song IDs and that the operation applies to the current account's owned playlist. The confirm parameter's purpose is partly in the schema, but the description's mention of validation before modifying gives it practical context.

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 verb (add), the resource (songs to a playlist), the range (1–100), and the account-ownership constraint (current account's owned playlist). It distinguishes this from siblings like netease_playlist_remove_songs and netease_playlist_create.

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

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

Explicitly says 'current account's owned playlist', informing when this tool is appropriate. It does not explicitly name alternatives, but the sibling list makes the distinction clear. The ownership check is a use-condition that helps an agent avoid attempting to add to playlists the user does not own.

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?

注解已声明 readOnlyHint=true，描述在此基础上补充了具体检查项和“不返回任何 Cookie 值”的敏感信息边界，增强了行为透明度；但未说明返回值结构或可能的状态枚举。

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?

描述仅用一句话完成，前段说明核心检查动作，分号后明确否定边界，信息密度高且无冗余。

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?

对于零参数、只读的状态检查工具，描述已覆盖检查范围和敏感信息排除项；但缺少输出 schema，且未说明返回值的具体格式或语义，存在轻微信息缺口。

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

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

工具没有参数，输入 schema 覆盖率为 100%，描述无需补充参数含义；按 0 参数基线评为 4。

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?

描述使用明确的动词“检查”和具体对象“账号写入功能是否已启用、是否配置会话文件”，清楚指明了工具的作用范围，并且通过“只检查”和“不返回任何 Cookie 值”与歌单写入、状态查询等兄弟工具区分开。

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?

描述暗示该工具用于确认账号写入能力和会话配置状态，但没有明确说明在什么场景下应使用它而非其他状态类或写操作类工具，也未给出排除条件或前置流程指引。

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 signal a non-read-only, non-idempotent write. The description adds useful context: the playlist is created under the current logged-in account and requires explicit user confirmation. It does not explain duplicate-creation behavior or failure modes, but those are partially anticipated by idempotentHint=false and the creation scope.

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 no filler: the action is front-loaded and the critical confirmation rule is separated into its own sentence. Every phrase 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 creation tool with no output schema, the core invocation requirements—name, confirmation, and optional privacy—are discoverable from the description plus input schema. Missing error/return details are minor because the user-facing confirmation condition is clearly stated and defaults are provided by the schema.

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

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

Schema description coverage is only 33%, so the description must compensate. It does this by mapping 'public or private' to the isPrivate parameter and restating the confirmation requirement for the confirm parameter. The name parameter is self-evident from the schema constraints, so the overall parameter meaning is adequately conveyed.

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 (create) on a specific resource (Netease playlist) with scope ('under current logged-in account') and visibility ('public or private'). This operationally distinguishes it from sibling tools like netease_playlist_add_songs, netease_playlist_get_songs, and netease_playlist_list, so an agent can select it without opening the schema.

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

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

Contains a clear invocation condition: call only after the user explicitly confirms this creation, which is essential for a mutation tool. It does not explicitly name alternatives or when-not-to-use cases, but sibling tools are operationally distinct enough that the intended use is 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?

Annotations already declare readOnly and non-destructive, so safety is covered. The description adds beyond annotations by disclosing the ownership requirement, which is an access/auth condition, and by summarizing the returned fields. It does not mention pagination or error behavior, but these are less critical for a simple read 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 that states operation, object, constraint, and output in compact form. No waste.

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

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

For a simple read-only tool with 2 params and annotations covering safety, the description covers scope, ownership requirement, and output fields. It lacks an explicit note on how pagination/limit works in practice, but the schema documents the limit, so the definition is nearly complete.

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

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

Schema description coverage is 100%, so both playlistId and limit are already documented. The description does not add parameter semantics beyond the schema; it focuses on the output content, which is acceptable given the schema 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 uses a specific verb ('读取') and resource ('指定歌单'), and clearly states it returns song information including ID, name, artist, and album. The ownership constraint ('必须是当前账号拥有的') helps differentiate it from playlist-level or song-detail tools.

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

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

It explicitly states the prerequisite that the playlist must be owned by the current account, which is clear usage context. It does not name alternatives or exclusions, but the condition is enough to route an agent correctly for most 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 readOnlyHint=true, so the safety profile is covered. The description adds useful auth and scope context ('使用本机登录会话', '当前账号拥有'), but it does not address failure modes such as missing login session or the exact return structure.

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 carries the action, scope, auth context, and downstream purpose. There is no filler or repetition of the name/title.

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 parameterless read-only list tool, the description gives essential context: auth session, account scope, and downstream purpose. The only missing piece is a precise description of the return structure, but '列出' makes a list of playlists the obvious result.

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 schema description coverage is 100%, so the schema fully defines the input surface. No parameter elaboration is needed from the description.

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 uses specific verb '列出' with clear resource '当前账号拥有的歌单', and the title further says '我创建的网易云歌单'. The phrase '供后续添加或移除歌曲' signals it is a listing/preparation tool, distinguishing it from modification/song-detail 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 explicitly frames the tool as a prerequisite for '后续添加或移除歌曲', giving a concrete when-to-use signal. It does not name alternatives or exclusions, but for this simple list operation the intended context is 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?

Annotations already mark the tool as destructive and non-read-only. The description adds useful behavioral context: explicit user confirmation is required, playlist ownership is validated, and the operation is scoped to the current account's playlist. It does not contradict 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?

The description is a single compact sentence that front-loads the action and scope, then states the constraints. Every part adds necessary information and there is no redundancy.

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 three-parameter tool with no output schema, the description covers what is removed, the target playlist, the quantity limit, the confirmation requirement, and the ownership check. An agent has enough information to select and invoke the tool correctly.

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

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

Schema description coverage is low (33%), but the description maps to all three parameters: playlistId ('specified playlist'), songIds ('1–100 songs'), and confirm ('must explicitly confirm'). It also adds the ownership-verification behavior for playlistId, going beyond the bare schema patterns.

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 action ('移除' / remove), the resource ('songs from a specified playlist owned by the current account'), and the 1–100 count limit. This makes it immediately distinguishable from sibling tools such as add_songs or get_songs.

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

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

The description provides a clear context: use this when removing songs from an owned playlist, and it highlights the ownership and confirmation preconditions. It does not explicitly name alternative tools or state when not to use it, so it stops short of full routing guidance.

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

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

Description explicitly mentions 'anonymous read-only interface' and 'does not read account cookies', reinforcing the readOnlyHint annotation with additional privacy 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 concise sentence covers purpose and key behavioral constraints without unnecessary 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?

Missing return format or result description, no pagination explanation beyond parameters, and no error or rate-limit context. The absence of an output schema makes this gap more significant.

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 the query parameter is described ('song, artist or keyword'), while limit and offset lack descriptions. Schema coverage is 33%, and the description does not compensate for the missing 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?

Description clearly states the tool searches songs via a specific interface, with a specific verb 'search' and resource 'songs', distinguishing it from sibling tools like detail or lyrics.

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 explicit guidance on when to use this tool versus alternative tools. It implies anonymous/read-only usage but does not state when to prefer search over song_detail or playlist operations.

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, so the read-only nature is covered. The description adds value by listing the concrete output fields (name, artist, album, duration, official page link), which is especially useful because no output schema exists. It doesn't discuss error behavior or availability, but for a read-only metadata lookup this is adequate.

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, front-loaded with the input mode and output fields, with no filler or repetition. Every part carries meaningful information.

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

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

This is a simple one-parameter read-only lookup with annotations and no output schema. The description covers the required input (song IDs) and the output fields, giving an agent enough to select and invoke it correctly. No critical missing context, such as destructive effects or authentication requirements, is relevant given readOnlyHint.

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 clarify the parameter. It does: songIds are NetEase Cloud song IDs used to fetch details. Format and size limits are left to the schema pattern and maxItems, which is acceptable.

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 ('读取' / read) and a precise resource: NetEase Cloud song details by song ID, enumerating the returned fields (name, artist, album, duration, official page link). This clearly separates it from siblings such as netease_lyrics (lyrics) and netease_search (search).

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 '按网易云歌曲 ID' implies the tool is for when the agent already has song IDs and needs metadata. However, it does not explicitly say when to prefer this over netease_search or netease_lyrics, nor does it name 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?

The description explicitly frames the tool as a read-only check ('检查' / '读取'), and the readOnlyHint annotation confirms no side effects. The macOS-specific behavior is also disclosed, adding useful transparency beyond the annotation.

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. The primary scope is stated first, and the platform-specific detail is added concisely.

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 low-complexity, parameterless status tool, the description provides enough context to understand what is being checked. It covers platform, remote capabilities, adapters, and the macOS exception, which is sufficient even without an output schema.

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

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

The input schema has no parameters, so there is no parameter documentation gap. The description does not need to explain parameters that do not exist.

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 ('检查' / checks) and names concrete resources: current platform, remote capabilities, local player adapters, and macOS client status. This clearly distinguishes it from sibling tools like playlist auth or playlist management.

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 makes it clear the tool is for checking runtime status and capabilities, which implies when it should be used. It does not explicitly mention alternatives, but the scope is distinct enough from siblings that usage context is clear.

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