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

With no annotations, the description carries the burden and adds valuable behavioral detail: it explains lazy-loading pagination, the offset semantics (empty for first request, then use next_offset from previous response), and the cursor field. This goes beyond a simple 'get' and helps the agent understand the tool's stateful behavior.

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

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

The description is compact and well-organized into Args and Returns sections. Every line contributes to understanding the tool's usage, with no redundant filler. It front-loads the main purpose and then provides crucial parameter details.

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

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

Despite no output schema and no annotations, the description covers the essential semantics for a paginated comment-list fetcher: parameters, pagination flow, and the cursor field in the response. It does not describe the full response structure or error cases, but for a read-only list tool it is reasonably complete.

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

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

Schema coverage is 0%, and the description fully compensates. It explains each parameter: oid (object ID with type hints), type_ (comment type), mode (main vs hot), and offset (pagination mechanics including empty string for first request). This adds meaning that the schema does not provide.

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

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

The description clearly states the tool fetches a comment list using a new lazy-loading mode, which is a specific verb+resource combination. It distinguishes itself from comment send/operate siblings by the 'get' action, but it doesn't explicitly contrast with other 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?

No guidance is provided on when to use this tool versus alternatives. It explains how to paginate but not in which scenarios to choose this over other bilibili tools. The context is implied by the function name but not explicitly 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?

No annotations are provided, so the description must carry the burden. It does disclose that page_index and page_size are only valid for get_sub_comments and max page size is 20, but it fails to mention side effects of delete (e.g., irreversible), authentication requirements, or what the operation result contains. The 'Returns: 操作结果' is uninformative.

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 concise with a bulleted argument list and no fluff. However, the Returns line is tautological and the action list is repeated in the argument description, slightly 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?

Given no output schema, the description should explain the return format but only says '操作结果' (operation result). It also lacks information on authentication requirements, error handling, and whether delete is limited to own comments. The tool has six actions with different parameter needs, so more context is needed.

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 description defines each parameter: oid as object ID with examples, action as operation type, type_ as comment type, and explains page_index/page_size scoping and limits. This compensates for the 0% schema description coverage, though action and type_ descriptions are somewhat generic.

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

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

The description clearly states it performs comment operations including like, dislike, delete, and fetching sub-comments. It distinguishes from sibling tools bilibili_comment_get and bilibili_comment_send by covering actions like delete and like.

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

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

No explicit guidance on when to use this tool versus alternatives. The action list implies usage, but no exclusions or recommendations are provided. It doesn't mention that for general comment retrieval one should use bilibili_comment_get.

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?

With no annotations, the description must carry the full burden of behavioral disclosure. It only says 'Returns: 发送结果' (send result), which is vague. It does not mention authentication requirements, side effects, rate limits, or error behavior—critical for a write operation.

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 structure is clear with Args and Returns sections, and each parameter gets a succinct description. However, the Returns section ('发送结果') adds no information and could be omitted. Overall it is efficient but not perfectly lean.

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 tool with 5 parameters, no annotations, and no output schema, the description covers parameter semantics well but lacks behavioral context (auth, errors, response format) and usage guidance relative to sibling tools. The agent cannot fully predict prerequisites or outcomes.

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

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

The description explains every parameter beyond the schema: oid is object ID (video aid/dynamic id/article cv), text is content, type_ is comment type, root is root comment ID, and parent is parent comment ID (usually same as root). This fully compensates for the 0% schema description coverage and adds clarifying context.

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

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

The description clearly states '发送评论/回复' (send comment/reply), a specific verb+resource. It also distinguishes replies from top-level comments via root/parent parameters, and the name differentiates it from sibling tools like comment_get and comment_operate. The intent 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?

No guidance is given on when to use this tool versus alternatives. The only usage hints are parameter-level ('fill when replying'), not tool-selection context. It does not mention that bilibili_video_send_danmaku or bilibili_session_send are for other communication types, leaving the agent to infer applicability.

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?

With no annotations, the description carries full burden but only implies a read operation through '获取' (get). It does not disclose pagination behavior, response structure, authentication needs, or any other behavioral traits.

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 brief and well-structured into purpose, args, and returns. It is front-loaded and contains no filler, though the returns line largely repeats the purpose, slightly reducing efficiency.

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 endpoint, it covers the basic purpose and parameters, but lacks usage alternatives, output details, and any behavioral caveats, making it minimally adequate rather than comprehensive.

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

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

The schema has 0% description coverage, but the description compensates by explaining 'page' starts from 1 and 'page_size' is the number of videos per page with default 20, adding meaning beyond the schema's type and default fields.

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 '获取热门视频' (Get hot videos), which clearly identifies the verb and resource. It is specific to videos, but does not explicitly differentiate from sibling tools like bilibili_get_rank or bilibili_get_hot_search.

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

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

No guidance is provided on when to use this tool versus alternatives. The description only states what it does, with no context on selection criteria 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?

With no annotations, the description carries the full burden of behavioral disclosure. It indicates a read-only operation through the verb '获取' and specifies the return format as a list. However, it does not disclose potential authentication requirements, rate limits, or that it has no side effects beyond fetching data.

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 extremely concise, with just a one-line purpose and a return-type declaration. It is front-loaded and contains no unnecessary 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?

The tool has no output schema, so the description must clarify the return structure. It states 'list of hot search terms' but does not detail the fields of each list item (e.g., keyword, rank, heat). Given its apparent simplicity, this is adequate but not complete.

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

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

The tool has zero parameters, and the schema coverage is 100% (vacuously). The baseline for 0 parameters is 4, and the description does not need to add parameter semantics since there are none to explain.

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

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

The description clearly states the tool's function: '获取热门搜索词' (get hot search terms). It specifies the resource (hot search terms) and the verb (get), and it distinguishes itself from sibling tools like bilibili_get_hot by focusing on search terms rather than general hot content.

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

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

The description provides no guidance on when to use this tool versus alternatives like bilibili_search or bilibili_get_hot. It does not mention any exclusions, prerequisites, or context in which this tool is preferred.

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?

No annotations are provided, so the description carries full burden. It does not disclose any behavioral traits beyond parameter semantics—no mention of read-only nature, rate limits, pagination, or error behavior. The name implies a read operation, but explicit disclosure is absent.

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 uses a structured Args/Returns format and is efficient. The rank_type enumeration is long but necessary, and the overall length is appropriate. No redundant sentences are present, though it could be slightly more compact.

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 only says '排行榜列表' (ranking list), lacking detail on item structure. Given the tool is a fetch/list operation, this may be enough for basic use, but for full completeness it should describe the returned list elements' fields.

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

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

Schema coverage is 0%, yet the description fully explains both parameters: rank_type lists all enum values with Chinese labels, and day clarifies its applicability to PGC types only. This adds significant meaning beyond the schema's bare enums, enabling correct parameter selection.

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

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

The description clearly states '获取排行榜' (get ranking), which is a specific verb+resource. It does not explicitly distinguish itself from sibling tools like bilibili_get_hot, but the resource (rank) is distinct enough. A slightly higher score is not given because it lacks a comparative statement against 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?

The description provides no guidance on when to use this tool versus siblings such as bilibili_get_hot or bilibili_get_hot_search. It only lists parameters and return value, with no contextual hints about appropriate usage scenarios.

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?

No annotations are provided, so the description carries full responsibility. It only states that the tool returns search results, without mentioning rate limits, authentication, sorting, or error handling. The only extra detail is that page_num starts from 1, which is minimal.

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

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

The description is compact and well-structured: a one-line summary, an Args list, and a Returns line. No filler or redundancy.

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

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

For a simple search tool, the description covers the main parameters but lacks usage guidance and specific return structure. Given no output schema and no annotations, the description could be more complete (e.g., examples, return format). It is adequate but has clear 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 0%, and the description compensates by providing Chinese semantic labels for all parameters: keyword (搜索关键词), search_type (搜索类型), page_num (页码，从1开始), page_size (每页数量). This adds meaningful context beyond the bare schema titles, especially the 'starts from 1' note and the categories listed in the opening line.

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 starts with '统一搜索' (unified search) and lists the content types (video, user, article, live), clearly indicating this is a cross-type search tool. This distinguishes it from sibling tools that target specific resources (e.g., bilibili_user_get_info, bilibili_video_get_info). However, it could be more explicit about the search action, though '统一搜索' implies 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?

The description provides no guidance on when to use this tool versus alternatives like bilibili_get_hot or bilibili_get_rank. It simply defines parameters and return value, with no mention of alternatives or exclusions.

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

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

With no annotations, the description carries the burden. It adds pagination mechanics via last_id and last_time, which is useful. However, it does not disclose authentication requirements, whether results are ordered, or any side effects, though as a read operation it is likely safe. More detail on return structure would improve transparency.

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

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

The description is concise and structured as a docstring with Args and Returns sections. It front-loads the main purpose and each line provides necessary information without filler. It earns the space used.

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 listing tool, the description covers the main parameters and return type ('互动消息列表'). However, it does not specify the structure of the returned messages, whether last_id and last_time are required together, or any error cases. Given there is no output schema or annotations, more detail would improve completeness for agent decision-making.

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

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

The schema coverage is 0%, but the description compensates by explaining each parameter: interaction_type enumerates the types, last_id is the last ID for pagination, and last_time is the timestamp for pagination. This goes beyond the raw schema, which only provides types and defaults, and gives functional meaning.

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

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

The description clearly states the tool retrieves interaction messages (replies, likes, @messages) with a specific verb and resource. The enum for interaction_type clarifies the scope, distinguishing it from sibling tools like session_list or session_send. However, it does not explicitly contrast with bilibili_session_notifications, which could be seen as 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?

The description provides no explicit guidance on when to use this tool versus alternatives. It merely states what it does and parameter meanings. There is no mention of scenarios or exclusions, so users must infer usage 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?

Without annotations, the description handles the burden well. It discloses the conditional behavior and parameter effects, including noted limitations (e.g., session_type only for list, begin_seqno only for chat records). However, it doesn't mention potential pagination limits or data format details.

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 well-structured and front-loaded: a one-line summary, then conditional logic, then parameter details. It's compact but thorough, with no redundant fluff.

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

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

Despite no output schema and no annotations, the description provides enough to correctly invoke the tool for both modes. The Returns line is terse but acceptable. It could be improved by describing the structure of the returned data, but given the tool's simplicity, it's adequate.

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

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

Schema description coverage is 0%, but the description fully compensates by explaining each parameter's meaning, default values, allowed values for session_type, and applicability per mode. This is exactly what's needed.

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

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

The description clearly states the tool retrieves either a session list or chat history, with explicit conditional logic based on talker_id. This distinguishes it from sibling tools that handle notifications or sending.

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 provides clear conditional usage instructions: without talker_id for list, with talker_id for chat records. It also explains which parameters apply to which mode. However, it doesn't explicitly discuss alternatives among sibling tools 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?

No annotations are provided, and the description only says '获取通知和设置信息' with a vague Returns clause. It does not disclose side effects, auth requirements, rate limits, or the structure of the returned data, leaving the behavioral profile under-specified.

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 concise and front-loaded with the purpose, followed by an Args list and a Returns line. It avoids excessive prose, though the Returns section is vague and the arg description somewhat duplicates the schema enum.

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 three distinct return modes (unread, system, settings), the description gives no details on the shape or content of each return type. There is no output schema and no annotations, so the description should carry more weight but does not.

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 description adds meaning to the single parameter by explicitly defining each enum value: unread=未读消息数量统计 (unread count), system=系统消息列表 (system message list), settings=消息设置 (message settings). This goes beyond the schema's bare enum names and compensates for the 0% schema description coverage.

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

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

The description states '获取通知和设置信息' (get notifications and settings info), and the Args section clarifies three notification types. It clearly indicates a retrieval action for notifications/settings, but it does not explicitly differentiate from sibling notification-related 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?

No guidance on when to use this tool versus alternatives. It does not mention any sibling tools or provide context for when to prefer this over bilibili_session_list or other notification-related 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?

With no annotations, the description carries the full burden of behavioral disclosure. It only states '发送结果' (send result) and does not mention side effects, authorization requirements, rate limits, or failure modes. The send action implies mutation but no further transparency is offered.

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 highly concise, using short labeled sections for Arguments and Returns. Every line is informative, with no fluff or repetition, making it easy to scan and understand.

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 send operation, the description covers the core parameters and states a return value, but the return is vague ('发送结果'). It lacks any mention of possible errors or success indicators, which is a gap given no output schema or annotations. Still, the low complexity makes it minimally adequate.

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

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

The schema has 0% description coverage, so the description compensates by explicitly listing both parameters with meaning: receiver_id is UID and content is plain text message. This adds clear value beyond the schema's type-only definitions, though it omits constraints like length or format.

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

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

The description uses a specific verb+resource structure: '发送私信文本消息' (send private message text). It clearly identifies the action and distinguishes it from sibling tools like bilibili_session_list or bilibili_session_notifications.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention context, prerequisites, or exclude any scenarios, leaving the agent to infer that it is for sending messages only.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals important operational details: page_num/page_size pagination (max 50), keyword only valid for video, offset for dynamic type, and the presence of next_offset in dynamic responses. It does not cover error handling or auth, but overall it provides substantial behavior 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 compact and front-loaded with the main purpose, followed by a clear Args list and a Returns note. Every line adds value, and the structure is easy to scan without redundant phrasing.

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 tool with 6 parameters and no output schema, the description covers all parameter semantics and dynamic pagination behavior. It lacks explicit details about the structure of returned content items or error scenarios, but given the tool's moderate complexity, this is a minor gap and overall sufficiently 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 0%, so the description fully compensates. It explains each parameter (uid, content_type, page_num, page_size, keyword, offset), including type-specific constraints like keyword only for video and offset only for dynamic. This adds meaning far beyond the bare schema titles.

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

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

The description clearly states the tool's function: '获取用户内容' (get user content) and enumerates the specific content types (video/article/album/bangumi/dynamic). This distinguishes it from sibling tools like bilibili_user_get_info (user info) and bilibili_user_get_followers/followings.

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 purpose implies usage (fetching a user's posted content), but there is no explicit 'when to use' or 'when not to use' guidance, nor reference to alternative tools. It lacks exclusions or decision criteria, so it only meets the 'implied usage' level.

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?

With no annotations, the description carries the full burden for behavioral disclosure. It adds a meaningful constraint: '非自己只能查看前5页' (non-own can only view first 5 pages), which is valuable. However, it does not explicitly state that the operation is read-only, nor does it mention authentication or rate limits, leaving some transparency gaps.

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 concise and well-structured with clear 'Args' and 'Returns' sections. Every line provides essential info: parameter explanations and a critical limitation. No redundant or filler 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?

The description covers parameters and a key usage constraint (5-page limit). Since there is no output schema, the return description '粉丝列表' is somewhat vague but sufficient for a simple list tool. It could benefit from specifying the return structure, but overall it is complete enough for a tool of this complexity.

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

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

The schema provides no descriptions for the parameters (0% coverage), so the description must compensate. It explains all four parameters: uid, page_num, page_size, and order, including the meaning of order ('desc-倒序, asc-正序'). This adds useful semantics beyond the bare schema.

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

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

The description clearly states the tool's purpose with a specific verb and resource: '获取用户粉丝列表' (Get user follower list). It is easy to distinguish from the sibling tool bilibili_user_get_followings based on the word '粉丝' (followers), even though the description does not explicitly mention the alternative.

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. The description only provides parameters and a limitation note but does not mention any exclusions, prerequisites, or when to choose another tool. The usage context is entirely implicit.

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

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

The description discloses a key behavioral limitation—'非自己只能查看前5页' (non-self users can only view the first 5 pages)—which is important context beyond the schema. However, it omits other behavioral aspects like authentication requirements or error handling, and since no annotations are provided, the description carries the full burden but is not exhaustive.

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

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

The description is compact and well-structured, front-loading the purpose and using a clear Args/Returns format. It avoids unnecessary verbosity, though it repeats default values already present in the schema, which is a minor 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?

The description adequately covers parameter semantics and includes a critical pagination restriction. However, since there is no output schema, it lacks details about the structure of each item in the followings list, and it doesn't mention authentication prerequisites or error scenarios, leaving the tool somewhat incomplete for an agent.

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

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

With 0% schema description coverage, the description compensates by explaining each parameter: uid (user ID), page_num (starts at 1), page_size (default 20), and order (desc/asc with Chinese explanations). This adds meaningful semantics beyond the raw schema, especially for the 'order' enum values.

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

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

The description uses a specific verb '获取' (get) and resource '用户关注列表' (user followings list), which clearly distinguishes it from sibling tools like bilibili_user_get_followers (which retrieves followers).

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention sibling tools or exclusions beyond stating it returns a list of followings, leaving the usage context implied rather than explicit.

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?

No annotations are present, so the description carries the full burden. It only lists high-level return categories and implies a read operation via '获取', but it does not disclose authentication needs, error behavior, data freshness, rate limits, or any side effects.

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 concise and well-structured with Args and Returns sections. Every sentence is purposeful and there is no redundant prose.

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, the description covers the core purpose and return categories. However, the absence of annotations, output schema, and usage guidance leaves the agent without enough context for robust invocation and expectation setting.

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 only parameter uid is described as '用户UID', which simply restates the schema's meaning without adding practical guidance on how to obtain or validate the UID. With 0% schema description coverage, the description should compensate but does not.

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

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

The description clearly states the action '获取用户完整信息' (get complete user info) and enumerates return categories (basic info, relationship stats, UP data), which distinguishes it from sibling tools like bilibili_user_get_followers. However, '完整信息' is somewhat broad and does not precisely delimit the exact scope.

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

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

No guidance is provided on when to use this tool versus alternatives such as bilibili_user_get_contents or bilibili_user_get_followings. It does not state use cases, prerequisites, 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?

With no annotations, the description carries the full burden of disclosing behavioral traits. It only lists actions and a vague return ('操作结果') without addressing side effects (e.g., what 'remove_fans' actually does), permissions, rate limits, or reversibility for mutations. This is a significant gap for a mutation tool.

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

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

The description is concise and well-structured: a one-line purpose statement, a short Args list, and a Returns line. Every sentence earns its place, and the format is easy to parse. There is no wasted 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?

Given the tool's complexity (five action types) and lack of annotations or output schema, the description is incomplete. It fails to clarify what each action entails, what the operation result looks like, or any side effects. This makes it insufficient for an agent to confidently invoke the tool in nuanced scenarios.

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

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

The schema has zero description coverage, so the description must compensate. It provides brief explanations ('uid: 目标用户UID', 'action: 关系操作类型') and clarifies the enum actions in Chinese, which adds minimal value beyond the schema's titles. However, it does not elaborate on parameter constraints, relationships between parameters, or the precise meaning of actions like 'remove_fans' in context.

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

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

The description clearly states the tool's purpose with a specific verb ('修改' / modify) and resource ('用户关系' / user relationship), followed by a list of concrete actions (关注/取关/拉黑/取消拉黑/移除粉丝). This distinguishes it from sibling tools like user_get_info or user_get_followers, which are read-only.

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

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

The description clearly implies when to use the tool: whenever you need to change a user relationship (follow, unblock, etc.). It is the only sibling tool for modifying relations, so the context is clear. However, it does not explicitly state when not to use it or mention alternatives for related actions (e.g., viewing followers), so it stops 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?

With no annotations available, the description carries the full burden of behavioral disclosure. It only states the purpose and return type, without mentioning side effects, permissions, rate limits, or error conditions. For a read-only 'get' tool, this minimalism may be acceptable, but it offers no explicit assurance of non-mutating behavior.

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

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

The description is succinct, using a structured Args/Returns format. Every element serves a purpose, and there is no unnecessary elaboration.

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

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

Given the tool's simplicity (one parameter, no annotations, no output schema), the description covers the essential input and output. However, it omits potential edge cases like missing videos or unavailable AI summaries, which leaves slight gaps in understanding.

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 description defines 'bvid' as '视频的BV号' (the video's BV number), which adds meaning beyond the input schema's bare 'Bvid' property. This clarifies the parameter's intention, though it lacks examples or format details.

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

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

The description clearly states the tool's function using the verb '获取' (get) and the resource '视频AI总结' (video AI summary). This is specific and distinguishes it from sibling tools like bilibili_video_get_info and bilibili_video_get_danmaku.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or preferred use cases, leaving the agent to infer usage solely from 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?

With no annotations, the description carries the full burden. It discloses segmentation behavior via from_seg and to_seg parameters and states the return type, but it does not mention authentication, rate limits, or error handling. The read-only nature is implied by 'get' but not explicitly confirmed.

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 concise and well-organized with Args and Returns sections. Each line contributes necessary information without redundancy, making it easy for an agent to quickly parse.

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

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

As a simple retrieval tool, the description covers the function and parameters. However, without an output schema, the return value is only described as 'danmaku list' with no structure, and it omits potential edge cases or limits, leaving some context 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 description adds meaning to all four parameters beyond the schema, explaining bvid as the BV number, page_num as starting from 0, and the defaults for from_seg and to_seg. This compensates well for the 0% schema description coverage, though it does not define 'segment' size.

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

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

The description clearly states '获取视频弹幕列表' (Get video danmaku list), specifying a clear verb (get) and resource (danmaku list for a video). This distinguishes it from sibling tools like bilibili_video_send_danmaku, which is for sending danmaku.

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 implies usage for fetching danmaku for a specific video, but it does not provide explicit guidance on when to use this tool versus alternatives. It lacks exclusion criteria or mentions of 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?

With no annotations provided, the description must carry the burden of behavioral disclosure. It mentions the return contents (download links, quality list, player config) but does not disclose important behaviors such as whether authentication is required, whether download links expire, or any error conditions. This is a significant gap for a tool that returns potentially sensitive or time-limited data.

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 concise and well-structured, with a front-loaded purpose statement followed by clearly labeled Args and Returns sections. Every sentence contributes necessary information, with no redundant 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?

The tool has no output schema, so the description must explain return values; it does provide a summary ('包含下载链接、清晰度列表、播放器配置等信息') but remains vague with '等信息' (and so on). Given the tool's moderate complexity and lack of annotations, the description covers the essentials but lacks detail on return structure, error handling, and special conditions, making it adequate but incomplete.

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

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

The schema has 0% description coverage, but the description fully compensates by explaining both parameters: 'bvid: 视频的BV号' and 'page_num: 分P序号，从0开始' (part index starting from 0). This adds clear meaning beyond the bare schema and clarifies the default behavior of page_num.

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

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

The description clearly states the tool's function: '获取视频下载链接和播放器信息' (get video download links and player info). This is a specific verb-resource pair and distinguishes it from sibling tools like bilibili_video_get_info or bilibili_video_get_danmaku, which serve different purposes.

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 usage is implied by the purpose: when a user needs download URLs or player configuration for a Bilibili video, this tool is appropriate. However, there is no explicit mention of when not to use it or which alternative tools to consider instead, leaving some ambiguity in choosing among video-related 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?

There are no annotations, so the description carries the full burden. It describes return fields (title, desc, stat, pages, tags) which gives some insight into behavior, but it does not disclose whether authentication is required, any rate limits, or any potential errors. The operation is implicitly read-only, but this is not explicitly stated.

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

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

The description is compact and front-loaded, with the main statement in the first line, followed by a simple Args/Returns structure. Every sentence adds value without redundancy.

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

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

Given the tool's simplicity—one parameter, no output schema, no annotations—the description covers the essential aspects: purpose, parameter meaning, and the shape of return data. It lacks explicit failure conditions, but for a basic getter this is 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 schema only provides the type string with no description, but the description's Args section explains bvid as the video's BV number with an example (BV1xx411c7mD). This fully compensates for the 0% 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 clearly states '获取视频完整信息' (get complete video information) and enumerates what's included: basic info, statistics, p-list, tags. This specific verb+resource framing distinguishes it from sibling tools like bilibili_video_get_danmaku or bilibili_video_get_ai_conclusion.

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 implies this tool is for when you need the full video metadata, but it does not explicitly state when to use it over alternatives or mention any exclusions. The sibling tool names hint at alternatives, but the description itself provides no direct 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?

No annotations are provided, so the description carries the full burden. It discloses parameter constraints (e.g., cancel only for like/favorite, coin_num valid for coin) but does not mention authentication requirements, rate limits, side effects on video interaction counts, or any potential irreversibility. This is a mutation tool with significant missing 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 structured with a one-line summary, a clear Args section with each parameter on its own line, and a Returns line. Every sentence adds value, and the format is easy to scan. No redundant or vague 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?

The parameter coverage is excellent, but the tool lacks an output schema and annotations. The return value is only described as '操作结果' (operation result), which is vague. Additionally, authentication prerequisites and potential error cases are not addressed, making the description incomplete for a mutation tool with 5 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?

The input schema contains only titles and no descriptions, so the description fully compensates. It explains each parameter in detail: bvid as the video BV number, action with its enum meanings, cancel with its validity scope, coin_num with valid values (1 or 2), and media_id with its conditional requirement and default behavior.

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 opens with '视频互动：点赞/投币/收藏/三连' (video interaction: like/coin/favorite/triple), which clearly specifies the verb and resource. It distinguishes from sibling tools by focusing on user interactions rather than retrieval or sending danmaku.

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 through the action types and parameter conditions, but there is no explicit statement about when to use this tool versus alternatives like bilibili_video_send_danmaku. No exclusions or alternative tool names are 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool sends a danmaku but does not mention side effects (e.g., public posting), authentication requirements, rate limits, or what the '发送结果' (send result) contains. It lacks behavioral context beyond the basic action implied by the name.

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 well-organized and front-loaded with a one-line summary ('发送弹幕'), followed by a concise bullet-style Args list. Each parameter gets a single line with meaning and default. No unnecessary information or repetition exists, making it easy to scan.

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

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

The description thoroughly covers parameters but is incomplete in other respects. It has no output schema and only says 'Returns: 发送结果' without specifying the result structure or error cases. It also omits authentication needs and any behavioral side effects. For a write operation with multiple parameters, this is adequate but leaves gaps for an AI agent.

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

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

Schema description coverage is 0%, and the description fully compensates by explaining every parameter: bvid is the BV number, message is the content, page_num starts from 0, progress is in milliseconds, color is hex with a default, font_size has three options, and mode maps 1/4/5 to scrolling/bottom/top. This adds meaningful semantics beyond the enum/defaults in the schema, enabling correct invocation.

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

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

The description clearly states '发送弹幕' (send danmaku), specifying the exact action and resource (a Bilibili video). It distinguishes from sibling tools like bilibili_video_get_danmaku, which retrieves danmaku, and bilibili_comment_send, which sends comments. The verb+resource combination is specific and unambiguous.

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

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

The description provides no guidance on when to use this tool vs alternatives. It does not mention prerequisites (e.g., authentication) or when not to use it. The only implied usage is 'when you want to send a danmaku,' but there are no explicit comparisons to sibling tools such as bilibili_comment_send or bilibili_video_interact.

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