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

The annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds context beyond those annotations: it says the call modifies the user's account, needs confirmation, and returns a playlist ID. It does not mention that repeated calls create duplicate playlists even though idempotentHint is false.

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

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

Three short sentences, each earning its place: purpose and return value first, then follow-up tool, then mutation warning. No repetition of the title or schema content.

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 two-parameter mutation with full schema coverage and no output schema, the description covers purpose, return value, follow-up workflow, and the confirmation requirement. The only real gap is that repeated calls create duplicates because the operation is not idempotent.

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%: the schema itself documents both `name` (minLength 1, maxLength 40) and `private` (default false). The description adds no details about these parameters, which is fine here, but it does not rise above the baseline 3.

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

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

The description states a specific verb and resource ("在当前用户账号下新建一个歌单") plus scope and return value ("返回歌单 ID"). It clearly differs from read siblings such as get_playlist and get_user_playlists, which only read data, and it names the follow-up tool update_playlist_tracks.

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 tells the agent what to do next ("之后可用 update_playlist_tracks 添加歌曲") and notes the mutation requires confirmation ("会修改用户账号，调用前请确认"). It does not state explicit exclusions, such as when to use like_song or an existing playlist instead, so it falls short of a 5.

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, so the safety profile is covered. The description adds the useful detail that a track list accompanies the album metadata, but says nothing about missing/empty albums, error behavior, or result shape beyond that phrase.

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

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

A single short sentence with no filler, front-loaded on the action and result. It is efficient, though too terse to route the agent among siblings.

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

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

For a one-parameter read-only lookup with no output schema, this is minimally adequate: the agent knows it fetches album info plus tracks. It omits sibling differentiation and any hint of return structure, which the absent output schema would otherwise require the description to supply.

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

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

Schema description coverage is 100% and the single `id` parameter is documented as '专辑 ID（数字）' with a positive-integer constraint. The description adds nothing about the ID's origin or validity, so the baseline 3 applies.

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

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

States a specific verb+resource ('获取专辑信息') and additionally names the payload ('曲目列表'), so an agent knows this is an album-detail fetch that also returns tracks. It does not differentiate from nearby siblings such as get_playlist or get_song_detail, keeping it just short of a 5.

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

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

There is no statement of when to use this tool versus get_playlist, get_artist, or get_song_detail, nor any prerequisite (e.g., where the album ID comes from). Usage is only implied by the tool name.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds nothing beyond that: no mention of album pagination behavior despite limit/offset params, no rate-limit or error context for an open-world remote API, no indication of what the payload resembles.

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 with no filler or redundancy. It is efficient, though the terseness leaves it thin rather than richly structured.

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

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

For a read-only detail tool with fully described params and no output schema, naming the three returned sections (bio, top songs, albums) is the minimum needed. It omits how album and song lists are shaped or paginated, which matters given the limit/offset parameters.

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

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

Schema description coverage is 100%, so all five parameters (including defaults, min/max bounds, and the top_songs cap of 50) are already documented. The description only echoes the include_albums toggle, adding no syntax or interaction detail beyond the schema.

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

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

Specific verb+resource: fetches artist bio, top songs, and optionally albums. The scope is clear enough to distinguish it from get_album and get_song_detail, though it never names those siblings explicitly.

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

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

No guidance on when to use this versus get_album, get_song_detail, or search, and no prerequisite noted (e.g., that an artist ID must first be obtained via search). The agent must infer all 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral detail — the first page also returns hot comments — but says nothing about pagination interaction with that extra data or about return shape.

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

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

Two short sentences, zero waste, with the scope (resource types) front-loaded before the behavioral note.

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

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

With no output schema, the description should say more about what a comment record contains and whether hot comments count toward limit. For a simple read tool with a fully documented schema this is adequate but leaves real gaps.

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

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

Schema description coverage is 100%, so all four parameters (id, limit, offset, resource_type) are already documented. The description's only additive note is that page one bundles hot comments, which hints at how offset/limit behave but stops short of explaining it.

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

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

States a specific verb (获取) and resource (评论) plus the four resource types it applies to, which lets an agent distinguish it from all siblings (none of which deal with comments). It does not explicitly name a sibling to route away from, but no confusable alternative exists.

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 resource types listed, but there is no explicit when-to-use or when-not statement, no mention of prerequisites, and no comparison to alternatives. An agent can infer the context but is not guided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the auth prerequisite, but says nothing about what happens when not logged in, how often recommendations refresh, or how many songs are returned.

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

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

A single short sentence with the resource front-loaded and the auth caveat trailing. 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?

The tool is simple and annotations carry the read-only profile, but with no output schema the description should hint at the return shape (a list of song objects) and the failure mode when unauthenticated. As written it is adequate but leaves those gaps.

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 login note is not a parameter concern.

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 ('获取...每日推荐歌曲') scoped to the current logged-in user. It implicitly distinguishes itself from sibling get_recommended_playlists (songs vs. playlists), but never names that sibling explicitly.

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

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

The parenthetical '需要登录' gives a prerequisite, which is genuine usage context. However, there is no guidance on when to prefer this over get_recommended_playlists, get_listening_history, or get_similar_songs, so the agent must infer the 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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuine value beyond that: the result is ordered identically to the app's '我喜欢的音乐' playlist (most recent first) and each item carries its liked date. Pagination/rate-limit behavior is still unstated, which holds it at 4.

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: scope first, then the ordering and date detail. Every clause (default user, ordering, liked date) earns its place. Efficient without padding.

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 3 optional params at 100% schema coverage, readOnly annotations, and no output schema, the description covers what is needed: what is returned, its ordering, and an extra returned field (the liked date). Only pagination semantics and behavior at the limit boundary are 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?

Schema description coverage is 100%, so uid, limit, and offset are already fully documented. The description only echoes the uid default ('当前登录用户'), adding no syntax or constraint information beyond the schema. Baseline 3 applies when the schema carries the parameter burden.

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 (获取/get) and resource (用户"喜欢"的歌曲), which is distinct from the sibling like_song (the write side) and from get_listening_history. The output ordering ('recently liked first') further pins down what is returned. It does not explicitly name which sibling a caller should use instead, keeping it a step short of a 5.

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

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

The '(默认当前登录用户)' note and the ordering hint give a sense of when this tool applies, but there is no explicit guidance like 'use like_song to add, get_listening_history for play history.' The usage context 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 readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds one genuinely new behavioral fact — other users' rankings may be hidden by privacy settings — but says nothing about what happens in that case (error vs empty result) or what the ranking entries contain.

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 front-loaded sentences with no filler: the first defines the resource, the second flags the privacy caveat. Efficient, though the caveat could be tagged more explicitly as a precondition.

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 read-only, zero-required-param tool with no output schema, the description covers what is fetched and one failure mode. It omits what a ranking entry actually returns (songs with play counts?) and whether a hidden ranking yields an error or an empty list, which an agent needs to interpret the 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?

Schema description coverage is 100%, so all three parameters are fully documented in the schema, including the uid default and the period enum. The description's '最近一周或所有时间' merely restates the period enum and adds no format or syntax detail.

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 (获取听歌排行) and the two time windows, which clearly distinguishes it from siblings like get_liked_songs or get_toplists. It stops short of explicitly naming the nearest alternative, so an agent must infer the boundary itself.

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

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

Usage is only implied: fetch a user's play ranking. The description never says when to pick this over get_liked_songs (liked) or get_toplists (global charts), nor that a uid may be supplied for someone else — that only appears in the schema.

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, so the safety profile is covered. The description adds that it also returns basic account information, which is useful beyond the annotations, but it says nothing about behavior when not logged in or what the account basics include.

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

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

A single compact sentence with the core purpose front-loaded and no filler. Slightly terse given the absence of an output schema, but nothing 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?

With no output schema, the description must hint at return content; it does so by naming login status plus basic account info. It could be more specific about the shape of the returned account details, but it is adequate for a no-parameter status check.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies no input is needed to query login state.

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

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

States a specific verb and resource: check whether the user is logged in to NetEase Cloud Music and return basic account info. It is clearly a read-only status probe, though it does not explicitly distinguish itself from the nearby login_qr_check sibling, which also assesses login state.

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

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

Usage is only implied: an agent can infer this is the pre-flight check before actions needing auth. There is no explicit statement of when to prefer it over login_qr_check or logout, nor any exclusion.

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, so the description's added value is in disclosing the return payload (原文、翻译、罗马音) and the conditional nature of the translation/romaji via '（如果有）'. It doesn't cover failure cases (e.g., missing lyrics, region-locked songs), which keeps it below a 5.

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

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

A single compact sentence with the resource and returned fields front-loaded. No filler or repetition of the 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 simple two-parameter read tool with full schema coverage and readOnly annotations, the description compensates for the absent output schema by listing return fields. Only edge behavior (empty result, timestamp format interaction) is left unaddressed.

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

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

Schema description coverage is 100%, and the description adds nothing about the 'id' or 'with_timestamps' parameters. The default 3 baseline is appropriate when the schema alone carries parameter semantics.

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

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

The description names a specific verb ('获取') and resource ('歌曲歌词') and enumerates the returned content (原文、中文翻译、罗马音), so an agent can tell it apart from get_song_detail. It stops short of explicitly naming a sibling to differentiate itself from, so it falls just under a 5.

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

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

Usage is only implied: you call it with a song id when you need lyrics. There is no statement of when to prefer this over get_song_detail, no mention of prerequisites (login/region), and no 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?

注解已声明 readOnlyHint=true 和 openWorldHint=true，因此安全概况已覆盖。描述只补充了分页能力，没有补充鉴权需求、私有歌单是否可见，或返回结构。

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?

结合完整参数文档和 readOnly/openWorld 注解，描述已足以用于正常路径。但排行榜使用场景、私有歌单的鉴权需求，以及它与 get_toplists 如何分工，都未说明。

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%，且已说明全部三个参数，包括 limit 默认值 50、最大值 500 以及 offset 默认值。描述只表达了“支持分页”，没有增加超出 schema 的内容，因此 3 分是合适的基线。

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

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

明确的动词+资源组合（“获取歌单信息和其中的歌曲”），并说明支持分页，因此无需打开 schema 就能知道它返回什么。额外提到排行榜可以用这个工具查看，合理扩大了范围，但模糊了它与同类工具 get_toplists 的边界，而不是划清边界。

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?

提到排行榜也可以用这个工具查看，这暗示了一种次要用途；但没有说明何时应改用 get_toplists、当两者都适用时该选哪个，也没有说明账号或可见性前提条件。

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, so safety and variability are covered. The description's added value is the login requirement, which is real but thin; it says nothing about how many playlists come back, whether results change over time, or whether an anonymous call fails or returns empty.

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

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

A single front-loaded sentence with no filler; the resource and the login constraint both appear before any clause could be cut.

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?

There is no output schema and no parameters, so the description is the only place to learn what a result contains. It never says the return is a list of playlists (with names, covers, IDs), nor how to move from a returned playlist to its tracks, which the sibling get_playlist would provide.

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

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

The tool takes zero parameters, so the baseline is 4. The description introduces no parameter claims that could mislead and correctly signals that user context comes from the session rather than from arguments.

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 ('获取…推荐的歌单') scoped to the current logged-in user, which distinguishes it from general retrieval tools like get_playlist and get_toplists. It does not, however, explicitly differentiate itself from the closely related sibling get_daily_recommendations.

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 parenthetical '(需要登录)' tells the agent a prerequisite, which is useful context for selection. It does not say when to prefer this over get_daily_recommendations or get_toplists, leaving the alternative choice 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 readOnlyHint=true and openWorldHint=true, so the safety profile is covered; the description adds only that results come from NetEase's algorithmic recommendation service. It says nothing about whether results can be empty, how they are ranked, or how the fixed limit behaves.

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

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

A single front-loaded sentence with zero filler; the resource and data source appear before anything else.

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 read tool this is roughly adequate, but with no output schema the description never hints at the return shape (a list of song objects with which fields), which is the main gap an agent would face.

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

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

Schema coverage is 100%: both id and limit are described in-schema including the default of 20 and maximum of 50. The description adds no extra meaning about these parameters, so baseline 3 applies.

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

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

A specific verb+resource: fetch similar songs recommended by NetEase Cloud for a given song. It is clearly distinguishable from siblings like get_song_detail or get_daily_recommendations, though it never names those alternatives.

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

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

No guidance on when to use this versus search, get_song_detail, or the recommendation tools, and no stated prerequisites beyond the implicit need for a song ID. Usage must be inferred entirely from the name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value by disclosing the concrete fields returned (name, artist, album, duration, VIP flag), which matters because there is no output schema. It stops short of covering partial-failure or invalid-ID 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?

One front-loaded sentence that names the keying input first, then the returned fields. No filler and nothing redundant with the 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 one-parameter lookup with no output schema, the description carries the important missing piece by listing what comes back per song. Only edge-case behavior (unknown or unavailable IDs, VIP-restricted tracks) is left unstated.

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

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

Schema coverage is 100% and the single parameter documents type, bounds and the 200-item cap. The description's '根据歌曲 ID 批量获取' only reinforces the array/batch nature already stated in the schema, adding no new syntax or constraint detail.

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

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

States a specific verb (批量获取) and resource (歌曲信息) scoped by song ID, and enumerates the returned fields (歌名、歌手、专辑、时长、是否 VIP). An agent can distinguish it from search, get_lyrics or get_similar_songs by the ID-keyed lookup, though no sibling is named explicitly.

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

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

Usage is implied: call it when you already hold song IDs, in batches. There is no explicit when/when-not guidance, e.g. that IDs typically come from search or a playlist listing, and no note on what to do for unknown IDs.

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, so the safety and freshness profile is covered. The description adds the scope qualifier that only official charts are returned (no user-generated lists), but says nothing about return format, chart identifiers, or whether the list is static or rotating.

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

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

Two short sentences, zero filler: the first defines what is returned, the second routes the agent to the follow-up tool. Front-loaded and appropriately sized.

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 listing tool with no output schema, the description covers what it returns and how to act on it. Slightly more detail on the shape of each chart entry (ids/names) would make it fully self-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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Schema coverage is 100% and the empty schema matches the no-argument nature described.

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: retrieve ALL official NetEase Cloud charts, with concrete examples (飙升榜、新歌榜、热歌榜、原创榜) that pin down the scope. It is clearly a chart-listing tool rather than a playlist or recommendation tool, though it does not explicitly contrast with get_recommended_playlists.

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 gives an explicit next step and names the alternative tool: use get_playlist to see the songs inside a chart. It lacks an explicit exclusion against get_recommended_playlists/get_daily_recommendations, but the 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds a real behavioral constraint not in the annotations: only public playlists of other users are reachable, and the default target is the current session's user. It omits anything about result ordering or pagination beyond the schema.

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

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

One sentence, front-loaded with the resource and scope, with the default-user and cross-user cases packed into a brief parenthetical. Nothing is redundant or padded.

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 read-only list tool with three optional, fully described parameters and no output schema, this covers what is returned (created + collected playlists), the default target, and the visibility limit for other users. A note on result ordering or expected volume would have closed the remaining gap.

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

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

Schema description coverage is 100%, and the uid/limit/offset semantics (defaults, max 100, offset paging) are fully documented there. The description only restates uid's default and adds the public-visibility note; limit and offset get no mention, so it does little beyond the schema.

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

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

States a concrete verb+resource (获取用户创建和收藏的歌单), including both the created and the collected scopes, which distinguishes it implicitly from get_playlist (single playlist) and get_recommended_playlists. It never names a sibling for contrast, so it falls short of a 5.

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

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

The parenthetical does supply usable context: omit uid for the logged-in user, supply uid for another user's public playlists. That is guidance for the uid parameter rather than a when-to-use-this-vs-alternatives statement, and no alternative tool (e.g. get_recommended_playlists, get_liked_songs) is mentioned.

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, so the mutation profile is partly free. The description still adds real value by flagging that the user's account is modified and advising confirmation before calling. It stops short of describing auth requirements or what the response returns.

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

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

Two short sentences, mutation scope first, warning second. Nothing redundant and nothing buried.

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 write tool with rich annotations and no output schema, the description covers what matters: it mutates the account and warrants confirmation. Minor gaps (response shape, whether un-liking removes the entry entirely) keep it from a 5.

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

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

Schema description coverage is 100%; both `id` and `like` are fully documented, including `like`'s true/false meaning. The description's '加入（或移出）' mirrors that toggle but adds no format, range or default detail, so it sits at the baseline.

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

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

The description names a specific verb pair and resource: add (or remove) a song from the current user's '我喜欢的音乐'. That is unambiguous and readily separable from read-only siblings like get_liked_songs. It doesn't explicitly name a sibling to avoid, so not a 5.

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

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

The only guidance is a caution ('会修改用户账号，调用前请确认'), which speaks to confirmation, not to when this tool is the right choice versus get_liked_songs or update_playlist_tracks. Usage is implied by the mutation phrasing rather than stated with conditions or exclusions.

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

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

Annotations declare readOnlyHint=false and openWorldHint=true, so the agent already knows this mutates state. The description adds genuinely new behavioral detail beyond that: the wait is implemented as a 2-second server-side poll, capped by wait_seconds, and successful login state is persisted automatically, which is consistent with the non-read-only 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?

Two tight sentences with the core purpose first and the optional waiting behavior second; nothing is redundant. It could be marginally improved by surfacing the polling interval earlier, but 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?

There is no output schema, and the description never indicates what status values come back (pending, scanned, confirmed, expired), which is exactly what a caller polling a QR login needs in order to branch. For a simple two-parameter tool it is otherwise adequate, but this return-state gap is meaningful.

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

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

Schema coverage is 100%, so both parameters are already documented, establishing a baseline of 3. The description earns above baseline by explaining that wait_seconds actually drives server-side polling at 2-second intervals rather than just being a timeout value, which is semantic information absent from the schema.

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

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

The description states a specific verb and resource: checking QR-code login status, and clarifies the server-side wait behavior. It does not distinguish itself from the sibling get_login_status or explain the handoff from login_qr_start, so an agent must infer the QR flow boundary from the names alone.

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

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

Usage is only implied: wait_seconds lets the caller block server-side instead of polling client-side, which suggests this is called after login_qr_start. There is no explicit statement of when to use this versus get_login_status, and no guidance on choosing wait_seconds values or retry behavior.

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 declare readOnlyHint=false and openWorldHint=true, so the description's added value is the interactive flow: this tool starts a session that only completes after a human scans and confirms, and a follow-up call is required. It does not mention QR expiry/timeout, behavior if already logged in, or whether repeated calls invalidate prior codes — real gaps for a stateful auth flow, but the core behavior is disclosed.

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

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

Three compact sentences: what it does, how to present the result, what to call next. Front-loaded action verb, zero filler, every clause carries operational instructions.

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

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

With no parameters and no output schema, the description usefully names the return payload (an image or qr_text) and the required follow-up call, which is exactly what the agent needs to drive the flow. Missing only failure/expiry handling and the already-authenticated case.

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

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

Zero parameters, so there is nothing to disambiguate and the baseline is 4. The description does not waste words on inputs, correctly focusing on the interaction protocol instead.

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

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

States a specific verb and resource (生成网易云音乐登录二维码) and implicitly distinguishes itself from the sibling login_qr_check by framing this tool as the generator and that one as the poller. An agent can tell these two apart without opening either 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?

Explicit sequencing: show the QR to the user (image or qr_text in a code block), have them scan and confirm in the app, then call login_qr_check. That names the exact next tool and the human-in-the-loop condition, leaving nothing to inference.

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

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

The annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is mostly given. The description still adds real value: by saying '本连接器保存的', it narrows the destructive effect to this connector's stored credentials and shows that the logout is not account-wide, which is context the annotations cannot express. It does not explain what token or cookie storage is removed or whether the user can recover the session.

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

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

The description is a single sentence with no wasted words. The scope qualifier ('本连接器保存的') appears before the object and does the most important work of preventing the agent from reading this as an account-wide logout.

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, non-open-world mutation with rich annotations and no output schema, the description covers the essentials: the scope of what is cleared and that it is idempotent. It could be slightly more complete by noting the need to re-authenticate afterwards, but nothing critical 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 tool takes zero parameters and the input schema is an empty object, so there is nothing to interpret. The description correctly implies no inputs are needed. A baseline of 4 applies to zero-parameter tools.

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 (clear) and an explicit object (the NetEase Cloud login state stored by this connector). That clearly sets it apart from read-oriented siblings such as get_login_status and login_qr_start. It does not mention any sibling by name, but the action it performs 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?

The description never says when to call this tool and when not to, or which tool to use instead. It does not mention the prerequisite of having an active session, and it does not mention that afterwards the user must run login_qr_start again. As a result, the agent must infer usage from the tool name alone.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and open-world reach are covered. The description adds nothing beyond them: no rate limits, result ordering, pagination caveats, or the fact that result shape differs per search type.

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

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

A single front-loaded sentence with zero filler, naming the platform first and the searchable entity types second. It is efficient, though the terseness leaves it close to under-specified rather than optimally sized.

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 four parameters fully covered by schema but no output schema, the description should clarify that the returned objects differ sharply by type (e.g. lyric search returns songs, user search returns profiles). That gap makes it only minimally adequate for a multi-mode search 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 100%, so every parameter (type enum, limit max 50, offset, keywords example) is already fully documented in the schema. The description's enumeration of searchable types merely restates the enum, adding no syntax or behavioral nuance, so the baseline 3 applies.

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

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

The description states a specific verb (搜索) and resource (songs, albums, artists, playlists, users, lyrics, podcasts) on a named platform. An agent can immediately tell this is the discovery/query tool. It does not explicitly contrast itself with the get_* detail siblings, so it falls short of a 5.

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

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

There is no when-to-use guidance, no prerequisite or exclusion, and no mention of alternatives such as get_song_detail or get_lyrics when an ID is already known. Usage is only inferable from the tool name and verb.

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 destructiveHint=true and readOnlyHint=false, so '会修改用户账号，调用前请确认' largely repeats that signal. The genuinely additive detail is the ownership constraint (only self-created playlists), which is a permission-like restriction that the annotations do not provide. It does not say what actually gets destroyed — the song is removed from the playlist, not from the library — and it does not mention the 500-item cap.

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 front-loaded and the scope plus caution trailing. No filler and no repetition beyond the single confirmation reminder.

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 mutation with no output schema, the description covers the action and the ownership precondition, which is adequate, but not much more. It leaves open important questions that an agent must resolve before invoking it, as with a destructive tool: whether partial failures are possible in a multi-song batch, and whether removing a song deletes it outright or just detaches it.

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%: op, song_ids and playlist_id all carry inline descriptions, including the add/remove enum values. The description does not add any parameter-level detail (for example, how duplicates are handled or whether song_ids must be unique). Baseline 3 applies when the schema does all the work.

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

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

The description names the specific verb pair (添加/移除) and the resource (歌单歌曲), and adds a meaningful scope restriction: only playlists the current user created. That scope restriction implicitly separates it from create_playlist, get_playlist, and like_song, but no sibling is named explicitly, so the differentiation is only in the description.

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 states one precondition — the playlist must be one the user created — and adds '调用前请确认', implying a confirmation step. Beyond that, it gives no guidance: no alternative for other users' playlists, no note on whether adding an already-present song is a no-op or an error, and nothing about batch-size limits that might make it necessary to split calls.

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