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 non-obvious behavioral fact that login state is not obtained by this tool and that an authenticated cookie must already exist, which is exactly the kind of context annotations cannot express. It does not discuss failure modes or caching, keeping it short of 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?

Two sentences, no filler, with the return-value enumeration front-loaded and the login caveat following. Every clause earns its place and there is no redundancy with the title or annotations.

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, so the description usefully enumerates the returned fields, and it explains the unauthenticated path via the login skill. For a zero-parameter read tool this is nearly complete; only minor detail (e.g., whether values are live vs cached, error shape when unauthenticated) is absent.

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

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

The tool takes zero parameters, so the schema has nothing to misinterpret and the baseline for an argument-free tool applies. No parameter information is needed or missing.

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+resource (读取当前 B 站登录态) and enumerates exactly what it returns: 昵称、UID、硬币、等级、未读通知/私信数. That is far more specific than the title alone. It stops short of explicitly distinguishing itself from siblings like user_info or notifications, so it is clear but not fully sibling-differentiated.

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

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

It gives an explicit precondition and redirect: when not logged in, use the bilibili-login skill to inject the Cookie from the browser, and it states that the MCP itself does not perform login. That is a real when/when-not signal with a named alternative. It does not, however, say when to prefer this over user_info or notifications for overlapping data.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false. The description adds genuinely new behavioral context beyond those flags: a dry-run-by-default preview mode requiring confirm=true, and the irreversibility of coins with a warning to verify balance and quantity.

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

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

Three compact sentences front-load the action, then the preview/confirm rule, then the irreversibility warning. Every sentence carries operational weight with 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 4-parameter mutation tool with no output schema and full annotation coverage, the description supplies the key operational facts (dry-run default, confirm gate, irreversibility, balance check). Only the relationship to like_video/select_like 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%, so all four parameters (video, confirm, multiply, select_like) are already documented in the schema. The description echoes the confirm gate and the 1-2 quantity without adding syntax or edge-case semantics, so baseline 3 applies.

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

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

States a specific verb and resource: '给视频投 1-2 枚硬币' clearly names the action (coin a video) and its scope (1-2 coins). It does not, however, differentiate itself from the related sibling like_video even though the select_like parameter overlaps with that tool's purpose.

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

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

Gives a useful operating rule ('默认只预览；confirm=true 才执行') so the agent knows the default is a preview and execution is opt-in. But it offers no when-to-use-vs-alternative guidance, notably not routing the agent away from or toward like_video for the select_like case.

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 only declare readOnlyHint and openWorldHint, so the description carries the burden of return-shape disclosure and does so: it names the fields returned (author, text, media cards, interaction counts) and states the 20-items-per-page cadence. It stops short of describing error or rate-limit 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?

Two tight sentences with the purpose front-loaded and pagination mechanics following; nearly every clause earns its place. Slightly dense packing of cursor semantics at the end.

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 feed tool with annotations covering the safety profile and no output schema, the description supplies the return contents and pagination model an agent needs. It omits any statement that this is the authenticated user's following feed, which an agent would otherwise have to infer.

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

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

Schema description coverage is 100%, so the schema already documents page, type, and offset, including offset's precedence over page. The description restates that offset precedence and adds only the page-size fact (20 per page), so baseline 3 is appropriate.

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

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

States a specific verb (读取) and resource (关注动态流) and enumerates what the feed contains (author, text, images, video cards, interaction counts), which clearly separates it from sibling post_dynamic. It does not explicitly name an alternative tool, so it falls just short of full sibling differentiation.

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

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

The description explains how to paginate (reuse next_offset, or pass page) but never says when this tool should be chosen over notifications, search, or user_videos. Usage is implied by the resource name rather than stated as a when/when-not rule.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so safety is partly covered. The description adds the critical non-annotation fact that the tool is a dry run by default and only mutates when confirm=true, which materially changes how an agent should call a destructive tool.

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

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

Three short clauses, front-loaded with the action, then the safety default, then the fallback behavior. No filler and nothing misplaced.

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 4-param destructive tool with no output schema, the description covers operation, safety default, and the folder-discovery path. It omits what a preview response actually contains, a minor gap given no output schema is declared.

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

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

Schema coverage is 100%, so the parameters are documented structurally. The description still adds meaning beyond it, explaining the conditional behavior of folder_id (omission returns the folder list) and the confirm gating, which the schema does not 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 concrete verb and resource (add/remove a video to/from a favorite folder) plus the toggle semantics, so an agent can tell it apart from like_video or coin_video in the sibling set. It does not, however, name any sibling explicitly, which keeps 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?

Gives clear invocation context that most tool descriptions omit: the default is a preview only, work happens only with confirm=true, and omitting folder_id yields the list of available folders. It stops short of saying when to prefer this over like_video/coin_video or when not to use it.

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, destructiveHint=true, idempotentHint=false. The description adds two things annotations cannot convey: the default is a non-mutating preview, and the action is reversible. It omits auth requirements, rate limits, and what the preview actually returns, so not a 5.

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

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

Three short clauses, zero filler, with the action and its default-preview constraint front-loaded. Every sentence carries distinct information (action, gating, reversibility).

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 3-param mutation tool with no output schema, the description covers the critical facts: what it does, that it is preview-only by default, and that it is reversible. The remaining gap is the shape/content of the preview response, which the agent would need to interpret before confirming.

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 each of the 3 params is documented in-schema, so the baseline is 3. The prose reinforces the confirm gating semantics but adds no format or syntax detail beyond what the schema already states.

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

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

States a specific verb + resource (follow/unfollow a user), which is distinct from the read-only siblings list_followings/list_followers. However, it never names an alternative or explicitly differentiates itself from the many write siblings (like_video, coin_video, send_message), 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?

Gives the operative usage rule: the call is a preview by default and only mutates with confirm=true. That tells the agent when the tool actually does something, but there is no guidance on choosing between follow vs unfollow paths beyond the parameter, and no exclusions or alternative tools named.

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 results are scoped to the currently authenticated account, which is genuinely useful behavioral context. It says nothing about ordering, pagination beyond the ps cap, or 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?

One short front-loaded sentence with no redundancy. The parenthetical "（扩展能力）" is the only wasted token and it conveys no actionable 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 read-only listing tool with one optional parameter this is close to adequate, but there is no output schema and the description never indicates what a history entry contains or how results are ordered/limited across pages. An agent can call it, but cannot predict the response.

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

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

Schema description coverage is 100%, with ps fully documented (1-30, default 20, bounds in schema), so the schema does the heavy lifting per the baseline rule. The description adds no additional meaning about what ps controls or whether results are ordered newest-first.

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+resource (读取观看历史) scoped to the current account, so an agent can tell it apart from write-side siblings like like_video or favorite_video. The trailing "（扩展能力）" is vague filler that adds no distinguishing information, and nearby siblings such as toview (watch-later) are not explicitly contrasted.

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 alternatives; the closest sibling, toview, stores a separate watch-later list and is never mentioned. The agent must infer from the name that this returns already-watched content rather than a saved list.

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

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

Annotations already declare readOnly=false, destructive=true, idempotent=false, openWorld=true, so the safety profile is partly covered. The description still adds real value the annotations cannot: a dry-run-by-default two-step commit protocol (confirm=true) and a reversibility claim. The word 可逆 sits in tension with destructiveHint=true, which tempers the score but is not a flat polarity flip.

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 front-loaded clauses: action first, then the safety workflow, then reversibility. Nothing is padded, though the terse final claim 可逆 does little work and slightly conflicts with the destructive annotation.

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 3-parameter mutation tool with no output schema, the description covers the action, the confirm gate, and reversibility — enough to call it correctly. It does not mention what the preview mode returns or the auth prerequisite, which a preview/commit tool would ideally state.

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%: like (true=点赞/false=取消), video (BV/av/link formats) and confirm (must be true to execute) are all fully documented in the schema. The description restates the confirm semantics for emphasis but adds no format, default, or edge-case detail beyond what the schema already provides, 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?

The description names a specific verb+resource pair (点赞/取消点赞视频), so an agent immediately knows this toggles a like on a video rather than adding a coin or favorite. It stops short of explicitly differentiating itself from siblings like coin_video or favorite_video, which are the most confusable 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?

It gives workflow guidance — default is preview-only, confirm=true actually sends the request — which helps the agent pick the right call pattern. But it never says when to choose this tool over coin_video/favorite_video, nor warns that it requires authentication first, so usage context is only implied.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and scope are covered structurally. The description adds the dual-mode output behavior and pagination support, which is useful, but says nothing about authentication requirements (auth_status exists as a sibling) or what the returned items look like.

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

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

A single sentence with zero padding, front-loading the no-folder_id case before the folder_id case so the default behavior is read first.

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

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

For a 5-param read-only tool the description covers the two operating modes and pagination, which is what an agent needs to pick the right call. It omits any sense of the return shape, but with no output schema and annotation-covered safety 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?

Schema description coverage is 100%, so ps, page, order, and keyword are already documented in the schema. The description only restates the folder_id semantics (parameter-conditional mode) that the schema itself already explains; it adds no syntax, format, or default details beyond that.

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 (list/read) and two concrete resources (收藏夹 folders vs 收藏夹内的视频), and its behavior is conditional on folder_id. It is clearly distinguishable from siblings such as favorite_video (a write) or search, though it does not explicitly name any sibling.

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

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

It states the exact condition that selects each mode: without folder_id you get folders, with folder_id you get that folder's videos. This is real when-to-use guidance, but there is no explicit exclusion or pointer to an alternative tool.

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 data-scope profile is covered. The description adds no further behavioral context such as pagination behavior, rate limits, or what happens when the target user is private or inaccessible.

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, well sized for a simple list tool. It is efficient, though the extreme brevity is arguably under-specification rather than purposeful conciseness.

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, zero-required-param list tool with full schema coverage and read-only annotations, the description is minimally adequate. It omits return shape and pagination expectations, and there is no output schema to compensate.

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 ps ('每页 1-50'), mid ('用户 UID'), and page ('页码') are fully documented in the schema. The description only loosely echoes the mid parameter ('指定用户') and adds no format or constraint details beyond it, 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?

The description gives a specific verb+resource ('获取...粉丝列表') with a clear scope modifier ('当前账号或指定用户'). It distinguishes itself from the sibling list_followings implicitly through the resource name, but never explicitly names or contrasts the two, 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 and no mention of alternatives such as list_followings. The only usage hint ('或指定用户') maps to the schema's mid parameter rather than routing the agent between tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered, and the description correctly reinforces that this is a read/list operation. It adds the default-account fallback and pagination behavior, but says nothing about result ordering, page-size ceilings, or how paging terminates beyond what the schema already encodes.

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 that front-loads the resource and scope and appends the pagination note. No filler, no 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?

With no output schema, the description is expected to convey more about what comes back, yet it only mentions pagination. For a three-parameter list tool the essentials (who, how many, which page) are covered, but the sibling-relationship distinction and return shape remain 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%, so ps, mid, and page are already documented in the schema; the baseline is 3. The description reinforces the mid semantics ('不传则使用当前登录账号') and pagination, but adds no format, ordering, or boundary 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?

States a specific verb and resource ('获取...关注列表') plus scope ('当前账号（或指定用户）') and pagination support, so the operation is unambiguous. It does not explicitly distinguish itself from the sibling list_followers, which retrieves the reverse relationship, so an agent must infer '关注' vs '粉丝' from the name alone.

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

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

Implied usage: retrieve followings for the logged-in account by default, or for a given user via mid, with pagination. No explicit when-to-use or when-not-to-use guidance, and the near-identical sibling list_followers is never named as the alternative.

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 ascending-time ordering and the mode-dependent return shape, which are useful, but says nothing about pagination, cursors, rate limits, or how limit behaves per mode.

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

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

A single sentence with two balanced clauses, zero redundancy, and the conditional trigger front-loaded so an agent can branch immediately without reading the schema.

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

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

For a two-parameter read tool with full schema coverage and safety annotations, the definition covers what it needs: both modes and the ordering of results. It stops short of describing pagination or the fields present in each return shape, which matters slightly since there is no 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?

Schema description coverage is 100% and the schema already documents both parameters, including talker_id's '不传则列出会话' semantics. The description largely restates that behavior; the only extra signal is the ascending order of the message mode, so baseline 3 is appropriate.

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

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

The description states a specific verb+resource pair (list DM conversations / read chat history) and makes the two operating modes explicit via the talker_id condition. It is clear but never distinguishes itself from the sibling write tool send_message, which sits right next to it in the toolset.

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

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

It gives clear, actionable context: use without talker_id to list conversations, with talker_id to read that user's history. No exclusions, prerequisites, or alternative-tool routing are offered, so it falls just short of the 5 bar.

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 carried structurally. The description adds one useful behavioral distinction — kind=unread returns a count while the other kinds return lists — but says nothing about pagination behavior, auth requirements, or result volume.

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 plus a compact kind-to-return mapping, front-loaded with the core purpose. Every clause carries information; nothing is redundant.

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 usefully sketches what the unread and list kinds return, and 100% schema coverage handles parameters, so an agent can call it correctly. It stops short of describing the shape of returned notification items, which would have made it fully self-contained.

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

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

Schema description coverage is 100%, so the baseline is 3; the description goes beyond the schema's terse '通知类型' by explaining the return meaning of each enum value, which materially helps the agent choose a kind. Pagination parameters (ps/page) are left to the schema.

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

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

It states a specific verb+resource (读取 B 站消息中心通知) and enumerates what each kind returns, so an agent understands the tool's scope. It does not explicitly distinguish itself from the sibling 'messages' tool, which could plausibly overlap, 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?

Each kind value is mapped to its meaning (unread=未读数, reply=回复我的, at=@我的, like=收到的赞), which effectively tells the agent which selector to pick. There is no explicit when-not or named alternative, so it is strong context rather than 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and network profile is covered. The description adds that pagination is supported and that tags are enriched, which is useful behavioral context, but it says nothing about return shape, page limits, or what happens when include_tags is disabled.

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 names the resource, the backing endpoint, and the two capability areas, with no filler or repetition.

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, fully documented, zero-required-parameter list tool this covers the essentials, and no output schema exists so return values need not be explained. It is still thin on how the pagination parameters combine and whether tags cost extra calls, which an agent would want for correct invocation.

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

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

Schema description coverage is 100%, so all five parameters (ps, page, limit, tag_limit, include_tags) are already documented in the schema with defaults and bounds. The description only gestures at '分页与标签补齐' without adding syntax or interaction detail (e.g. how limit relates to ps), so the baseline of 3 applies.

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

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

States a specific verb (获取) and resource (B 站综合热门视频) and even cites the upstream endpoint /v/popular/all, so the agent knows exactly what content comes back. It does not distinguish itself from same-family siblings like rank_list, weekly_list or precious_list, leaving the agent to infer which 'list' tool applies.

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

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

There is no explicit when-to-use guidance and no mention of alternatives among the many sibling list tools (rank_list, weekly_list, precious_list). Usage is only implied by the tool name and the endpoint reference.

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

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

Annotations already declare destructiveHint=true/openWorldHint=true/non-idempotent, and the description adds real behavioral context beyond them: a preview-by-default flow gated behind confirm=true, and the fact that comments become public content. It doesn't describe auth requirements or return format, but materially clarifies the write 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?

Compact, front-loaded Chinese prose that states the primary action first, then image/ reply options, then the crucial publish gate. Every clause carries information; 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 7-parameter, 1-required mutation tool with no output schema, the description supplies the critical context (preview default, confirm gate, public visibility, reply semantics). Auth/permission specifics are the only notable omission, mostly implied by openWorldHint.

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

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

Schema coverage is 100%, so the schema already documents all seven parameters (root, parent, video, dynamic_id, confirm, message, image_paths). The description mainly restates root/parent usage and the confirm gate; it adds only marginal relational meaning over the schema, so baseline 3 is appropriate.

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

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

The description names a specific verb (发表评论) and resource (video/dynamic comment), and notes reply capability via root/parent. It is clearly a write/create tool, not a read tool like video_comments, though it never names a sibling tool explicitly to differentiate 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?

It gives concrete usage conditions: default is preview-only and confirm=true is required to actually publish, plus root/parent to reply. That is clear operational guidance, but it does not contrast against alternatives (e.g., post_dynamic or send_message) or state when a plain comment is preferable.

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

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

Annotations already declare this is a non-readOnly, destructive, open-world, non-idempotent write. The description adds genuinely new traits: the default preview/dry-run behavior and the public visibility of the content, which the annotations do not convey. Return format is not described but that is minor here.

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, front-loaded with purpose and immediately followed by the critical preview-vs-publish distinction. 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?

With no output schema and safety already handled by annotations, the description supplies the two things an agent most needs: the confirm gate and the public nature of the content. Only the lack of any return/preview-result explanation keeps it from being fully complete.

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

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

Schema description coverage is 100%, so the schema already documents text length, confirm semantics, and image count/format. The description echoes the same concepts (text, optional local image paths, confirm) without adding syntax or edge-case detail beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource — publish a dynamic with text and optional local image paths — and clarifies that the resulting content is public. Clear enough that an agent understands the action, though it does not explicitly distinguish itself from nearby posting siblings like post_comment or send_message.

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?

Explains the core workflow: by default only a preview is produced, and confirm=true is required to actually publish. This gives clear operational context, but there is no guidance on when to prefer this tool over alternatives or what prerequisites (auth, account) apply.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so safety and externality are covered. The description adds only a vague parenthetical “（扩展能力）”, without disclosing return format, pagination, or any additional behavioral 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?

The description is a single, front-loaded sentence with no wasted clauses. The parenthetical “（扩展能力）” adds little value but does not bloat the text.

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

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

For a simple list-retrieval tool with complete parameter documentation and read-only annotations, the description is minimally sufficient. However, it omits what the returned list contains and any pagination behavior, and no output schema exists to fill that 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%, so all three parameters (limit, tag_limit, include_tags) are already documented in the schema. The description adds no parameter meaning beyond what the schema provides, which is the baseline for high 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 states a specific verb (获取) and resource (B站“入站必刷”列表), which clearly identifies the tool's function. It does not explicitly contrast with sibling list tools like popular_list or rank_list, but the named list is distinct enough for an agent to distinguish it.

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

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

There is no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description only says what it retrieves, leaving the agent to infer usage from the resource 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 and openWorldHint, so safety is covered. The description adds useful behavioral context: it lists the returned fields and discloses that tags are completed item by item with only the first 20 filled by default, which signals extra latency/work when tag_limit or include_tags are changed.

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: purpose plus endpoint, return fields, then the tag-completion caveat. Every sentence carries information, and the operationally important caveat is front-loaded enough to be noticed.

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 five-parameter read tool with no output schema, the description supplies the return field list and warns about per-item tag fetching, which is sufficient to invoke it correctly. It stops short of explaining the meaning of the type enum or rid values, and does not relate this endpoint to the other ranking tools.

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 3 is the baseline. The description adds real meaning to tag_limit/include_tags by explaining that tag completion is done per item and defaults to the first 20, clarifying the cost implication of raising those parameters beyond what the schema states.

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

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

States a specific verb and resource ('获取 B 站排行榜') and even gives the backing endpoint (/v/popular/rank/all). However, it does not distinguish this tool from the overlapping sibling list tools such as popular_list, weekly_list, and precious_list, so an agent must infer the difference.

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 when-to-use, when-not-to-use, or alternative guidance is given. With four similar ranking/list siblings in the tool set, the absence of routing guidance leaves the agent to guess which endpoint to call.

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 essentially nothing on top of that – it restates 'read' without disclosing return format, whether recommendations are personalized/authenticated, or pagination behavior, which is minimal context for the 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 well-formed sentence with no waste and the resource front-loaded. It is appropriately sized, though extremely sparse relative to what a stronger definition could carry.

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 read tool with full schema coverage and annotations covering the safety profile. The one-line description is minimally adequate, but with no output schema and no statement of return shape beyond '列表', there's a small gap in completeness.

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

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

Schema description coverage is 100%, so the schema already documents both 'video' (BV/av/link formats with examples) and 'limit' (1-50 range). The description repeats none of this and adds no syntax or format detail, so baseline 3 applies.

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

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

The description gives a specific verb and resource ('读取某个视频的相关推荐列表' – read the related-recommendation list for a given video), so the agent knows exactly what it returns. It is largely distinguishable from siblings like video_info or search, but the text never names or contrasts a sibling, so it stops 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 prerequisites, and no alternatives named. With siblings such as video_info and search that could plausibly surface recommendation-style content, some disambiguation was warranted and is absent.

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 openness profile is covered. The description adds that video results carry BV id, link, author, and tags, which is useful since there is no output schema, but it says nothing about pagination behavior, rate limits, or empty-result handling.

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 covering purpose followed by result content, with no filler. It is slightly terse given the tool's filtering and sorting options, but nothing is wasted.

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

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

For a 5-parameter read-only search with full schema coverage and no output schema, the description covers purpose and sketches the return fields. Missing are routing hints against sibling list/info tools and any pagination notes, but the essentials for calling it correctly are present.

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 page, type, limit, order, and keyword are all documented in the schema itself. The description only echoes the video/user distinction and result fields, adding no syntax or format detail beyond the structured data; 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: keyword search over Bilibili videos or users, and names the two searchable entity types. It is clearly distinguishable from siblings like video_info, user_info, or popular_list, though it does not explicitly say it differs from those list/ranking 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?

There is no guidance on when to use this vs. alternatives such as popular_list, rank_list, or video_info, nor any exclusions or prerequisites. Usage is only implied by the mention of two search types, leaving the agent to infer 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 declare destructiveHint=true and idempotentHint=false, and the description adds the crucial non-obvious behavior that the call is a dry-run unless confirm=true, plus that delivery is immediate. It does not cover retraction, rate limits, or duplicate-send behavior, but it goes meaningfully beyond the annotations.

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

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

Three short sentences, front-loaded with the action, then the preview/send rule, then the delivery consequence. No filler or repetition.

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 definition covers the action, the safety gate, and the delivery effect, which is what an agent needs to call it correctly. Minor gaps remain around failure modes and rate limits, but nothing essential is missing.

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

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

Schema coverage is 100%, so receiver_id, text, and confirm are already documented in the schema. The description restates the confirm-to-send semantics and adds nothing about formats or constraints beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('给指定用户发送私信') plus the recipient scope, which cleanly separates it from read-side siblings like messages and from content-posting siblings like post_comment or post_dynamic.

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 defines the operating mode: default is preview only, and confirm=true is required to actually send. That is clear when-to-use guidance for the send path, though it never names an alternative tool or says when not to message a user.

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 the list belongs to the current account, implying authentication context, but it does not describe pagination behavior, rate limits, or failure modes.

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

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

A single front-loaded sentence with no filler. It is appropriately sized for a simple read tool.

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 tool with one optional, fully documented parameter and annotations covering safety, the description is nearly sufficient. It does omit any note about pagination behavior or the returned list structure, which would help since there is no 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?

Schema description coverage is 100%, and the only parameter 'ps' is documented in the schema as a 1-30 return count. The description adds no parameter meaning beyond the schema, 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?

Description states a specific verb ('读取') and resource ('当前账号的稍后再看列表'), and scoping to the current account helps distinguish it from general list siblings. It does not explicitly name an alternative tool, so it is clear but not fully differentiated.

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 when-to-use condition, prerequisites, or alternative tool is mentioned. The agent must infer that this is the watch-later list rather than history, favorites, or another list, so there is essentially no usage guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value by naming the returned fields (card info, level, follower count, following count), which matters since there is no output schema. It still omits error behavior for invalid/private UIDs.

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 action and the returned fields front-loaded. No wasted text, though it is terse enough that it provides no structure beyond the one clause.

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

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

For a simple one-parameter read tool with no output schema, the description supplies the key information an agent needs: what entity it targets and what fields come back. Only routing guidance relative to the many sibling tools is absent.

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

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

Schema description coverage is 100% and the single 'mid' parameter is documented as '用户 UID' in the schema. The description adds no syntax, format, or sourcing detail for mid, so the baseline of 3 applies.

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

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

States a specific verb+resource ('获取...用户的名片信息') and enumerates the data returned (等级、粉丝数、关注数), so an agent knows it retrieves a user profile. It does not explicitly contrast itself with neighbours like list_followers/list_followings, but the resource focus on a single user's card is clear.

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

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

There is no guidance on when to use this versus list_followers, list_followings, user_videos or other user-related siblings. Usage must be inferred entirely from the one-line purpose.

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 nothing beyond purpose: no note on pagination behavior, result ordering, or what happens for a nonexistent/empty account.

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

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

A single front-loaded sentence with no wasted words. It is efficient, though its brevity is closer to under-specification than to richness.

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 list tool with no output schema and full schema coverage, the description is minimally viable. It omits usage context and edge-case behavior, but the structured fields carry the invocation details.

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

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

Schema description coverage is 100%, so mid, page, limit, and order are all fully documented in the schema. The description adds no parameter detail beyond restating that a user is specified, 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 ('获取指定 UP 主的投稿视频列表'), and '投稿' (uploaded/submitted) meaningfully separates it from siblings like list_favorites or history. However, it never names an alternative tool, 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?

There is no explicit when-to-use guidance, no exclusions, and no mention of sibling tools such as user_info or video_info. The only implied guidance is that a specific user ('指定 UP 主') must be targeted, which is minimal.

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 usefully enumerates returned fields (comment content, author, like count, partial replies), but says nothing about rate limits, pagination behavior, or reply completeness beyond '部分'.

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 zero redundancy, and the key capability (reading the comment section) is front-loaded. It packs scope and return fields efficiently, though brevity leaves gaps elsewhere.

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 tool with no output schema, the description partially compensates by naming what is returned (content, author, like count, partial replies). Combined with annotations and full schema coverage, this is close to sufficient, missing only reply-truncation/rate-limit detail.

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

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

Schema description coverage is 100%, so ps, page, sort, and video are fully documented in the schema. The description only loosely echoes the sort enum ('热门或按时间') without adding syntax or format detail beyond what the schema already provides, so baseline 3 applies.

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

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

States a specific verb (读取/read) and resource (视频评论区/video comment section) plus the sort modes and returned fields. The read verb implicitly distinguishes it from the write sibling post_comment, though it 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 description mentions the two modes (热门 hot / 按时间 by time) but gives no guidance on when to prefer one, no exclusions, and no routing away from alternatives like post_comment. Usage is only implied.

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

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

Annotations only declare readOnlyHint and openWorldHint. The description adds real behavioral detail beyond that: the default sampling positions, the DASH-extraction fallback to Bilibili's thumbnail sprite, and the no-ffmpeg behavior of returning the entire sprite. These degradation paths are exactly the failure-mode information an agent cannot get from the annotations.

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

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

Three tight sentences: purpose first, then defaults/input formats, then fallback behavior. Each sentence carries distinct information and nothing is 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?

For an 8-parameter extraction tool with no output schema, the description covers the return medium, default sampling, accepted inputs, and fallback modes well. It does not detail issues like rate limits or oversized multi-image returns, leaving a small gap, but it is largely 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?

Schema coverage is 100%, so the baseline is 3. The description still adds value by clarifying the accepted `times` syntax (seconds, time like 1:23, or percentage) and pinning the default frame positions, which reinforces and clarifies the schema entries rather than merely repeating them.

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 return medium (images) that distinguishes it from text-returning siblings like video_transcript. An agent can tell what it produces 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?

The description explains how to use the tool (default 15%/50%/85%, accepted time formats, fallback behavior) but never says when to prefer it over an alternative such as video_transcript. Usage is implied rather than contrasted, so it is only minimum-viable on this dimension.

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, setting a lower bar. The description adds useful context that the tool returns multiple metadata categories including available subtitle languages, but omits behavioral details like authentication requirements, rate limits, or pagination 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?

A single front-loaded sentence that states the purpose and enumerates returned fields without any wasted words. The structure is efficient and immediately informative.

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 metadata tool, the description is nearly complete: it enumerates the returned fields (compensating for the lack of an output schema) and annotations cover safety. Minor gaps remain around pagination behavior and how multi-part pages are handled.

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. The description adds no parameter-specific syntax, defaults, or constraints beyond what the schema provides, making the baseline 3 appropriate.

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

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

States a specific verb and resource: '获取视频详情', and enumerates the returned metadata fields (title, description, cover, uploader, statistics, multi-part, tags, subtitle languages). This clearly distinguishes it from siblings like video_transcript or video_comments, though it does not explicitly name 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 explicit when-to-use guidance, prerequisites, or alternatives are provided. The only implied usage is the obvious one of fetching video details, but nothing helps an agent choose this over video_transcript, video_frames, or video_comments.

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 real behavioral context beyond that: B站 AI 字幕通常可用 and the no-subtitle path returns available languages plus a hint to switch tools.

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, front-loaded with what the tool returns, then the availability caveat and the fallback. No filler and every sentence carries 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?

With no output schema, the description compensates by stating the return shape (full text plus time segments) and the degraded case (available languages). Nothing critical is missing for a read-only three-parameter 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 lang, page and video are already fully documented in the schema. The description only adds that multiple subtitle languages are supported, which loosely maps to lang but adds no syntax or format detail beyond the schema.

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

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

The description states a specific verb and resource: 读取视频字幕全文与时间分段 (read the full video transcript and its time segments). It also differentiates from the relevant sibling by naming video_frames as the fallback when no subtitles exist.

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

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

It gives a clear condition for use and an explicit alternative: when subtitles are unavailable the tool points the agent to video_frames. It does not spell out when to prefer this over video_info or search, but the primary routing decision is covered.

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 endpoint mapping and confirms it is a listing of items rather than a mutation. It adds no detail on pagination, result count behavior, or data freshness beyond the structured fields.

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

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

A single front-loaded sentence that states the resource, the returned fields, and the upstream endpoint with no filler. It is appropriately sized for a one-parameter read tool, though it stops short of anything else an agent might need.

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 list tool with full schema coverage, complete annotations, and no output schema, the description covers what is returned and how it maps to the source. The missing piece is any distinction from the similarly named sibling weekly_list.

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 limit parameter is documented there (range 1-50, default 12). The description says nothing about the limit, so baseline 3 applies — it neither compensates nor adds value 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 specific verb (列出) and resource (B 站每周必看的期数) and even names the returned fields (期数、主题、链接) plus the backing endpoint /v/popular/weekly. It does not, however, distinguish itself from the sibling tool weekly_list, which sounds highly overlapping.

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 statement of when this should be preferred over weekly_list/rank_list/popular_list, and no prerequisites or rate-limit caveats. The agent must infer selection from the 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 the safety profile is covered. The description adds the default-to-latest behavior and names the return fields (title, link, tags), which is useful since there is no output schema, but says nothing about paging, rate limits, or auth requirements.

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, front-loaded sentences: what it fetches, the default-argument behavior, then the payload fields. No filler and nothing important buried at the end.

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 list tool with four all-optional parameters and full schema coverage, the description covers purpose, default behavior, and return fields. With no output schema, the mention of returned title/link/tags is the needed compensation; only cross-tool routing 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?

Schema coverage is 100% so the baseline is 3, but the description adds meaning the schema lacks: 'number' has no default in the schema, and the description supplies the important semantic that no number means the latest issue. It does not cover limit, tag_limit, or include_tags, but those are documented in 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+resource ('获取指定期数的每周必看视频列表') and pins it to an endpoint, so the agent knows exactly what is retrieved. It also implies single-issue scope ('单期'), which separates it from weekly_issues, though the sibling is never named explicitly.

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

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

The one genuinely useful usage note is that omitting 'number' returns the latest issue, which tells the agent how to call it with zero arguments. However, there is no explicit guidance on when to pick this tool over weekly_issues, popular_list, precious_list, or rank_list — the agent has to infer the split.

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