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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The only added context is that the data is '公开' (public), which hints at no-auth visibility, but nothing is said about what happens with invalid or private article ids or whether the article body is included.

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, front-loaded sentence with a bracketed category tag and zero filler. It is appropriately sized, though its brevity reflects under-specification rather than disciplined economy.

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

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

For a one-parameter read with rich annotations and no output schema, the minimum needed to call it is present (what it returns, roughly). However, the meaning of the id and any hint about the returned fields are missing, leaving it just barely 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% for the single required parameter 'id'. The description never clarifies that this id is the column article id (as opposed to a video id, dynamic id, or user id), which is exactly the disambiguation an agent needs given the many id-taking siblings.

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 pairs a specific verb (读取) with a specific resource (专栏文章) and scope (公开信息), so an agent can distinguish it from bilibili_video_info or bilibili_user_info without opening the schema. It stops short of explicitly naming those siblings as alternatives, so it lands at a clear-but-not-differentiating 4.

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, and no prerequisites or exclusions. Usage is only inferable from the tool name and the phrase '公开信息' – the description itself provides no 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 only tell the agent the call is read-only; the description adds two traits that matter and are not in structured data: credentials are never returned, and verify=true causes real-time validation against Bilibili (implying latency/network dependency). It stops short of saying what happens when verification fails.

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

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

One compact sentence that front-loads the return contract and then the parameter behavior; every clause adds information and nothing repeats the name or 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?

With no output schema, the description says what is excluded but not what the returned session status actually contains (e.g., logged-in flag, username, expiry), leaving the agent to discover the shape at runtime. Adequate for a one-param read tool, but with a clear 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 coverage is 0%, so the description must carry the single parameter, and it does: verify=true means live validation, with the default of false implied. Lacking only a note on failure/timeout behavior for the verify path.

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 resource (本地会话状态和账号) and explicitly bounds the return payload by excluding Cookie/key, which sharpens what the tool is. It does not, however, differentiate from the sibling bilibili_me, which an agent could easily confuse it with.

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 clause about verify=true implies when to pay the cost of a live check, but there is no explicit when-to-use/when-not guidance and no routing away from bilibili_me or bilibili_user_info. Usage is inferable rather than stated.

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

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

readOnlyHint=true is consistent with a 'query' verb, so no contradiction. The description adds only the category-scoping hint beyond the annotation; it does not disclose the available categories, the shape of the returned capability data, or whether the result is a full dump versus a filtered slice.

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

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

A single short sentence with no padding. Efficient, though terseness here shades into under-specification rather than economy.

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 discovery tool the description is the only place the caller can learn what categories exist and what the response looks like (no output schema), and it provides neither. An agent can invoke it bare, but cannot use the one parameter purposefully.

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% with a single undocumented 'category' string. The description does gesture at it ('按分类'), telling the agent it is a category filter, but it supplies no valid values or enum, so an agent still cannot construct a meaningful category argument.

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 verb (查询) and object (本MCP工具、接口与参数约束) are stated, and it is clearly a meta/discovery tool distinct from the content-fetching siblings. However '接口与参数约束' is vague jargon that doesn't say what an agent actually gets back (tool list? parameter docs? per-category breakdown?).

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 an implied usage (call this to learn about the MCP tool by category), but no explicit when-to-use, no mention of when to prefer it over directly calling a sibling, and no note that the category parameter is optional or how the unfiltered call behaves.

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's "[互动写入]" tag largely restates what the annotations already declare (readOnlyHint=false, destructiveHint=true). It never mentions the confirm gate, the requirement that the service run with --enable-writes (both of which appear only in the confirm parameter's schema description), or that posting is irreversible and affects real account state.

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

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

The description is a single compact sentence that front-loads the purpose before the parameter note. It is terse but not padded; the only cost is that its brevity leaves significant 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 6-parameter destructive write with no output schema and sparse annotations, the description is thin. It omits the required confirm flag, the --enable-writes precondition, expected outcome or return value, and what distinguishes a top-level comment from a reply at the field level.

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?

Given only 17% schema coverage, the description does useful work by defining oid as a video aid and by pointing to root and parent for replies. However, it leaves `type` (an integer with a range of 1-100 but no stated meaning) and `message` completely unaddressed, and it does not define what root and parent actually contain (the top-level comment ID and the ID of the comment being replied to).

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: "发布一条评论/回复" (post a comment/reply), which lets an agent distinguish this write action from read siblings such as bilibili_comments and bilibili_comment_replies. It does not name a sibling it is being contrasted with, 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?

The "[互动写入]" tag signals the write category, and "回复需root和parent" gives a conditional hint that the reply path requires two extra fields. However, there is no explicit statement of when to use this tool versus alternatives (for example, bilibili_comment_delete, or bilibili_comments for reading), and no prerequisites are stated.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the danger profile is covered structurally. The description adds the ownership/auth scope (只能删自己的评论), which is real value, but it does not state irreversibility or what happens when the rpid no longer exists. No contradiction with annotations.

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

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

A single sentence with the write tag front-loaded, zero filler. Nothing is repeated from annotations or 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 destructive, non-idempotent mutation with no output schema and two undocumented identifiers, the description leaves the agent without enough to call it safely (what oid refers to, how failure on an already-deleted rpid is reported). It covers intent but not the operational detail this tool's risk profile demands.

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

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

Schema description coverage is only 25%: the critical oid (target object id) and rpid (comment id) properties have no descriptions, and the description adds no explanation of them. Only confirm carries documentation, so the description fails to compensate for the coverage gap on the two parameters that decide whether the call hits the right comment.

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 concrete verb (删除) and resource (指定评论) plus a scope limit (当前账号自己的), so the agent knows exactly what is removed. It does not name the sibling counterpart bilibili_comment_add, so it falls short of full differentiation, but the tag prefix 互动写入 makes the write intent unmistakable.

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

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

The phrase 当前账号自己的指定评论 functions as an explicit precondition: this only works on comments owned by the authenticated user, implicitly excluding moderation of others' comments. No alternative tool (e.g. bilibili_comment_add for the inverse operation) is named, which keeps it below a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so safety is covered. The description adds nothing beyond the bare action – no mention of pagination defaults, ordering, reply-depth limits, or whether login is required.

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, front-loaded with the resource tag and the action with no filler. Brevity is a virtue here, though it errs toward under-specification rather than excess.

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?

A 5-parameter, 0%-coverage tool with no output schema needs the description to explain oid, type, and pagination semantics; instead it leaves four parameters opaque, so an agent must guess what identifier oid expects.

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% across 5 parameters, so the description carries full burden, yet it only hints at the 'root' parameter and says nothing about oid (the target video/dynamic id), pn/ps pagination, or the type discriminator. One of the most consequential parameters (type) is completely unexplained.

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: read replies under a given root comment. The '[评论]' tag and 'root comment' scoping distinguish it from the sibling bilibili_comments, which lists top-level comments, 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?

No guidance on when to use this instead of bilibili_comments or how to obtain a root comment id first. The phrase '指定根评论' only implies a prerequisite; alternatives and exclusions are 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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only the oid/type semantics, saying nothing about pagination limits, ordering behavior, or what a call returns. With annotations doing the heavy lifting, this is adequate but thin.

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 that front-loads the resource tag and the core action before the parameter notes. Nothing is wasted, though the bracketed [评论] tag is mild redundancy with the tool name.

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

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

For a 5-parameter list tool with no output schema and zero schema descriptions, the description leaves pagination (pn/ps) and sort ordering entirely unexplained, which an agent needs to page results or choose ordering. The critical oid/type semantics are covered, so it is viable 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?

Schema description coverage is 0%, so the description is the only source of parameter meaning — and it explains just two of five parameters (oid as video aid, type=1 video / 12 article). pn, ps and sort (including what sort values 0/1/2 mean and the 50-item page cap) remain undocumented anywhere.

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: read main comments ([评论]) of video/article content. The word 主评论 implicitly separates it from bilibili_comment_replies, and the type mapping clarifies the content types covered. It does not explicitly name the sibling alternative, 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?

Usage is implied rather than stated: an agent can infer this is the entry point for top-level comments and that replies belong to bilibili_comment_replies. There is no explicit when-to-use/when-not-to-use guidance, no mention of bilibili_comment_add/delete, and no prerequisites such as login or rate limits.

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, idempotent, non-destructive, and open-world, so safety is covered. The description adds that only public XML danmaku are read and that output is capped at `limit` entries, which is useful beyond the annotations, but it says nothing about pagination, ordering, or what the XML payload looks 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 front-loaded sentence with the category tag first and the resource next; nothing is wasted. It is arguably too terse for the information an agent needs, but not padded.

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

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

With no output schema, the description should describe the returned XML danmaku shape, and it does not. Combined with an unexplained required `oid` and no guidance on the 1000-item limit ceiling, an agent cannot reliably invoke this without guessing.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning and it largely does not. It restates that `limit` bounds the result count, but leaves `oid` completely undefined even though it is the required parameter and its type (integer) makes it ambiguous whether it is an avid or a page cid.

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 (公开XML弹幕) scoped to a 分P, and the bracketed tag [字幕与弹幕] separates it from the subtitle tools. It is clear what it fetches, though it never states what 'oid' identifies (avid, bvid, or cid), which is central to the operation.

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 instead of bilibili_subtitles, bilibili_subtitle_text, or bilibili_comments, all of which are adjacent sibling tools. The only routing signal is the category tag, which implies but does not state that this is for danmaku rather than subtitles or comment threads.

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, idempotentHint=true and destructiveHint=false, so the description adds nothing about safety. It also omits behavior an agent would care about: whether private or deleted dynamics error out, whether openWorld access can fail on restricted content, and what the returned payload covers.

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 filler, which is structurally fine. However, brevity here is under-specification rather than economy: the same length could have carried the id format or a pointer to a sibling.

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?

No output schema exists, so the description is the only place to say what a dynamic record contains (text, images, author, stats) — and it says nothing. For a lookup tool with an undocumented id and openWorld access, this leaves real gaps.

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

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

Schema coverage is 0% and the single `id` parameter has no description, so the definition must compensate — but '指定动态' only vaguely implies a dynamic id. It never states the numeric-string format, nor distinguishes dynamic id from user/video ids that other sibling tools take.

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 verb (读取) and resource (动态内容) for a single dynamic by id, which is understandable but extremely generic. It gives no distinguishing detail versus feed-style siblings like bilibili_user_feed or bilibili_my_feed, which also surface dynamic content, so an agent cannot tell from the description alone where this fits.

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 the feed tools, no prerequisites (auth requirements, whether the dynamic can be private/deleted), and no exclusion conditions. The agent must infer everything 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?

Annotations already declare readOnly, idempotent, non-destructive, open-world. The description contributes the non-obvious default-account fallback, which is genuine added context, but says nothing about auth requirements, pagination, or what a folder entry contains.

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

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

One compact sentence with the list action first and the important default condition attached. Nothing wasted, though the parenthetical default is slightly buried after the semicolon.

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?

No output schema exists, so the description should hint at the return shape (folder IDs and names, needed to feed bilibili_favorite_items) and the auth precondition; neither is present. Adequate to call, insufficient to chain.

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% for the single parameter, so the description does the useful work of explaining the meaning of omitting up_mid. It still never defines what up_mid designates (a user mid) or whether passing another user's mid is permitted or private.

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 — listing favorite folders (收藏夹) — which is clear enough to distinguish it from siblings like bilibili_favorite_items (folder contents, not folders). The tag '[收藏]' adds a category hint but the description does not explicitly contrast with the nearest 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 gives a conditional default (omit up_mid to target the currently bound account), which is real usage guidance, but it never says when to use this versus bilibili_favorite_items or whether authentication is required for the default path.

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, idempotentHint and non-destructive, so the safety profile is covered. The description adds only that folders must be 'visible', which is useful, but it says nothing about auth requirements, whether paging beyond the last page errors or returns empty, or rate limits for an openWorld read.

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

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

One short sentence with no filler, which is fine as a headline, but at this length the compactness is a symptom of under-specification rather than discipline. Nothing is front-loaded beyond the tag and the verb.

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?

A 6-parameter tool with zero schema descriptions and no output schema needs far more than this: which id media_id expects, how tid/type narrow results, and how ordering interacts with paging are all missing. An agent could invoke it, but only by guessing at five of six parameters.

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

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

Schema description coverage is 0% across 6 parameters, so the description carries the full burden and fails: media_id (required), pn/ps paging bounds (1-1000, 1-50), tid category filter, type, and the order enum (mtime/view/pubtime) are never explained. Only the word '分页' gestures at pn/ps.

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

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

States the verb and resource: paginated read of videos inside a favorites folder (收藏夹). This is distinguishable from bilibili_favorite_folders, which lists the folders themselves, but the description never says so explicitly, and the bracketed tag '[收藏]' plus a single short sentence leaves the scope ('visible' only) under-explained.

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 call this versus bilibili_favorite_folders (to find a media_id first) or bilibili_video_info (for details on a returned video). The 'visible favorites folder' wording hints that private folders are out of reach but never states it as a precondition.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description only adds that the result is a 'tree', hinting at a hierarchical structure, but says nothing about auth requirements, caching, or the shape/depth of that tree.

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

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

A single short sentence with the resource front-loaded and no filler. It is perhaps terse to a fault, but nothing in it is wasteful.

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

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

For a zero-parameter read with no output schema, the description should sketch what the tree contains (area IDs, names, parent/child nesting) so an agent knows what it can do with the result. That information is missing, leaving the agent to call it blind.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies no input is required, and the schema is fully consistent with 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 and resource (读取 = read, 直播分区树 = live-streaming partition tree), which is clearly distinct from siblings like bilibili_live_rooms or bilibili_live_room_info that deal with actual rooms. It does not explicitly call out those siblings, but the resource is unambiguous for a zero-parameter lookup.

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 call this versus bilibili_live_rooms or bilibili_live_room_info, nor any mention that the partition tree is typically a prerequisite for discovering area IDs before listing rooms. Usage must be inferred entirely 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds only the vague phrase '当前可见', without explaining visibility conditions, auth requirements, or what happens when a room is offline.

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?

It is a single front-loaded sentence with no filler, so it is structurally clean. However, the brevity comes at the cost of under-specification for a tool with six parameters.

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?

A six-parameter live-stream resolver with no output schema and zero parameter documentation is not adequately described by one sentence. An agent cannot know how to set qn, codec, format, protocol, or platform, nor what the returned URLs look like, from this description.

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 six parameters at 0% schema description coverage, the description must compensate but mentions none of them. Critical parameters such as qn (quality), codec, format, protocol, and platform are left completely undocumented, and even room_id is not explained.

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: 取得 (retrieve) 直播流地址 (live stream URL), with the [直播] prefix anchoring it to the live domain. This clearly separates it from bilibili_video_playurl, but it does not explicitly name that sibling or clarify what '当前可见' (currently visible) means.

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 such as bilibili_live_room_info or bilibili_video_playurl, nor any stated preconditions like needing a room to be live. Usage is only implied by the tool name and description.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds only a hint that live status is included in the response; it says nothing about auth requirements, error behavior for invalid/nonexistent room IDs, or response 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?

A single short sentence with the resource front-loaded and zero filler. It is efficient, though its brevity comes at the cost of the missing guidance noted in other dimensions.

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

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

For a one-parameter read tool with no output schema, the description is minimally adequate: it tells the agent the tool returns room info plus live status. It falls short by not explaining the sole parameter's format or how it differs from the live_rooms listing endpoint.

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 single parameter room_id is documented nowhere. The description does not clarify its format (numeric ID vs. short ID), valid ranges, or where an agent can obtain a room_id, which matters on Bilibili where short IDs are common.

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 ("读取直播间信息和直播状态" – read live-room info and live status), which is clear about what it returns. It does not explicitly distinguish itself from close siblings such as bilibili_live_rooms (a listing tool) or bilibili_live_playurl, so sibling differentiation is left to inference.

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 bilibili_live_rooms or bilibili_live_playurl, and no prerequisites or exclusions. An agent must infer from the name alone that this fetches a single room's metadata rather than a room list or stream URL.

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, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond them: no word on pagination behavior, result caps (page_size max 30, page max 1000), or whether an empty area returns empty results or errors.

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

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

A single front-loaded clause with zero padding, which is good structure. But the brevity crosses into under-specification rather than conciseness — it spends one sentence where three or four pieces of information are needed.

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 5 undocumented parameters, no output schema, and a sibling (bilibili_live_areas) that clearly supplies the required area identifiers, the description should explain the area-id workflow and pagination. It supplies almost none of that, so an agent cannot confidently construct a correct call from the definition alone.

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% across 5 parameters, so the description carries the full burden, yet it only implies the area-based filter. page, page_size, sort_type (enum online/live_time), and the parent_area_id vs area_id distinction are left completely unexplained.

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 (直播间列表) with a scoping filter (按直播分区), so an agent knows exactly what it returns. It does not, however, distinguish itself from siblings like bilibili_live_areas or bilibili_live_room_info, which is the remaining requirement for a 5.

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

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

There is no statement of when to use this tool versus bilibili_live_areas (to discover areas) or bilibili_live_room_info (single room). A genuinely useful note — that parent_area_id must come from bilibili_live_areas — is absent, leaving usage to inference.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description does add one piece of real context beyond them: it operates on the currently bound session and verifies login, implying it can fail when unauthenticated. It says nothing about what the returned profile contains.

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, front-loaded with the [账号] category tag, with no redundant restatement of the title. It is efficient, though bordering on under-specified for an auth-gated read.

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

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

For a zero-param read tool with full annotation coverage, the description is close to adequate, but it leaves real ambiguity: how '本人的资料' differs from bilibili_user_info, and how this differs from bilibili_auth_status. With no output schema, a hint about the returned profile shape would also help.

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

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

The tool takes zero parameters, so there are no semantics for the description to compensate for. Baseline 4 applies; nothing is missing or misleading on this dimension.

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 phrase (核验登录 / 读取本人资料) on the 'self' resource scoped to the bound session, which implicitly separates it from bilibili_user_info. However, it never names the near-identical sibling bilibili_auth_status, so an agent must guess which one is the auth probe.

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, when-not-to-use, or named alternative. The phrase 使用当前已绑定会话 hints that no credentials are supplied, but nothing tells the agent whether to prefer this over bilibili_auth_status or bilibili_user_info.

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, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds the pagination-continuation behavior via offset, which is genuine value, but says nothing about the login requirement implied by '当前登录用户' or about page size / termination conditions.

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

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

Two short clauses, no filler, and the core purpose is front-loaded before the pagination hint. It is efficient, though the offset note is stated as a bare instruction rather than integrated into a fuller usage sentence.

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, an agent cannot learn what a feed entry looks like, and the description does not say whether results are mixed dynamic types or how the type filter narrows them. Annotations carry the safety profile and the schema is trivial, so the gap is moderate rather than severe.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain offset as the pagination cursor, which is more than the bare schema (default "") provides, but the type parameter's enum (all/video/pgc/article) is never mentioned, leaving half the parameters to be inferred from self-descriptive 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?

States a specific verb and resource: read ([读取]) the following feed ([关注动态]) of the currently logged-in user, with a [动态] category tag. This implicitly separates it from bilibili_user_feed (a named user's feed) and bilibili_my_history, but no sibling is named explicitly, so the distinction relies on the reader noticing '当前登录用户'.

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

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

The only usage guidance is the pagination note ('后续分页传offset'), which tells the agent how to continue a listing but not when to pick this tool over bilibili_user_feed, bilibili_my_history, or bilibili_popular. Usage is implied by the 'my' scope rather than stated.

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

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

Beyond the static hints in annotations (readOnlyHint: true), the description discloses the critical behavioral pattern of this tool: the pagination sequence. This guidance on using the response cursor is essential for successful tool invocation.

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, fitting its core function, scope, and the two most critical operational rules into a single, highly effective sentence.

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 complexity of pagination and the nature of a read-only history retrieval tool (which is confirmed safe by annotations), the description covers all necessary operational steps and behavioral constraints required for the AI to call it correctly.

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

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

Since schema description coverage is 0%, the description is vital. It adds operational meaning to the pagination parameters (max/view_at) by explaining that they must be initialized to zero on the first request and replaced by a cursor on subsequent requests, which is not explicit in the schema definition.

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 defines the purpose: reading the user's own viewing history ('本人观看历史'). It is specific, utilizes the correct resource terminology, and distinguishes its function as a historical archive retrieval compared to other user data retrieval tools.

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

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

It provides explicit usage guidelines regarding pagination. It mandates that the initial call must set max/view_at to 0, while subsequent calls must utilize the cursor from the response. This dictates the necessary operational workflow.

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, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds the account-scoped '[账号]' cue, implying credentials are needed, but does not mention pagination, result ordering, or what the returned list contains.

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

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

A single short sentence with the account marker front-loaded and no filler. It is appropriately sized for a simple zero-parameter 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 zero-parameter read operation with rich annotations, the definition is minimally sufficient. However, with no output schema, it does not describe the shape of the returned Watch Later list or whether results are paginated, leaving an agent to discover the response format at call time.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain. The baseline of 4 is appropriate because the empty schema is self-evident and the description does not need to document inputs.

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 (稍后再看列表) with the scope 本人, which clearly identifies a personal Watch Later listing rather than a video search. It does not explicitly name the Add/Delete siblings, but the read-only nature makes the distinction reasonably 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 alternatives such as bilibili_watch_later_add/delete or bilibili_my_history. The '本人' scope implies personal use but no exclusions or conditions are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered structurally. The description adds nothing beyond that — no mention of pagination behavior, page size limits, total result caps (pn max 1000), or whether auth is required for a public endpoint.

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

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

A single short sentence with no waste, but it is under-specified rather than genuinely concise; the bracket tag '[发现]' consumes space without adding information for the agent.

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 paginated list endpoint with no output schema, the description should at least explain paging semantics and what a result item looks like. Neither is present, leaving the agent to guess how to page through results or what fields come back.

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 both parameters (pn, ps) are entirely undocumented in the schema. The description never mentions pagination at all, so the agent cannot infer that pn is a page number or ps is page size without guessing from abbreviations — a clear gap that the description was responsible for filling.

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 concrete verb and resource (读取热门视频列表), so an agent knows this returns a list of trending videos. However, it never distinguishes itself from close siblings like bilibili_search_hot or bilibili_ranking, which could plausibly return overlapping 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?

There is no guidance on when to use this versus bilibili_search_hot, bilibili_ranking, or bilibili_my_feed. No prerequisites (login/auth) or exclusions are stated.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds the rid=0 meaning (site-wide versus per-region), but says nothing about result size, pagination, or whether the ranking is a snapshot; with annotations carrying the load, a 3 fits.

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 clause, front-loaded with the [发现] category tag and the core action, with zero filler. It is terse to the point of under-specification, 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 two-parameter read-only tool with full annotations and no output schema, the description covers the main axis (region) but omits any explanation of the `type` ranking variant, which an agent would need to choose a value confidently.

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

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

Schema description coverage is 0%, so the description must compensate and only partially does: it explains rid (0 = site-wide) but leaves the `type` enum values (all / origin / rookie) completely undefined, which is the more ambiguous of the two parameters.

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 (读取排行榜 'read the ranking') with a scope qualifier (按分区 'by region'), which separates it reasonably well from siblings like bilibili_popular or bilibili_search_hot. It stops short of explicitly naming those alternatives.

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

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

No indication of when to pick this over bilibili_popular (popular list) or bilibili_region_online (per-region activity), which are the obvious overlapping siblings. The only usage-like hint is the rid=0 note, which is really a parameter default rather than selection 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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds nothing further: no mention of scope (all regions returned at once?), freshness of the statistics, or what is returned, despite there being no output schema.

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

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

A single short sentence that front-loads the verb and resource with no padding. It is efficient, though its terseness borders on under-specification rather than being a model of crispness.

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

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

For a zero-parameter tool with an empty schema and no output schema, the description should at least indicate what the returned statistics contain and whether results span all zones. It gestures at 'online/submission statistics' but leaves the agent guessing about return shape and scope.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no parameter semantics for the description to explain. No conflict exists between the description and the empty 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 names a specific verb (读取/read) and resource (分区在线/投稿统计/region online and submission statistics), so the general intent is discoverable. However, it never clarifies whether '分区' means all zones or a single zone, nor how it differs from siblings such as bilibili_popular or bilibili_ranking that also surface aggregate stats.

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 this tool is the right choice versus bilibili_popular, bilibili_ranking, or bilibili_live_areas. The only hint is the '[发现]' (discovery) tag, which implies exploratory use but states no conditions or exclusions.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: output is a paginated raw structure and titles may contain highlight HTML, which warns the agent about return-format quirks it would otherwise not expect.

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

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

Two short, front-loaded sentences with no filler: capability first, return characteristics second. Efficient, though the second clause packs two distinct facts (pagination structure and HTML-in-titles) into one line.

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 6-parameter tool with no output schema, the description should clarify the multi-mode search_type behavior and pagination semantics. It hints at paginated raw output but says nothing about the parameters an agent must set to search different resource types, leaving a substantial 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 0% across 6 parameters, so the description carries the full documentation burden, yet it names no parameters. It never explains search_type's enum categories (video/user/live/article/media), the order options, tids, duration, or page limits, leaving the agent to guess from bare enum names.

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 (搜索/search) and enumerates the resource types covered: videos, UP主, live rooms, articles, and film/TV. This clearly distinguishes it from retrieval tools like bilibili_video_info, though it does not explicitly name the closest sibling bilibili_search_hot to differentiate hot-search behavior.

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

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

The description gives no guidance on when to use this tool versus alternatives such as bilibili_search_hot or the specific info tools. The '[发现]' discovery tag implies exploratory use, but there is no stated condition, prerequisite, or exclusion to route the agent among the many sibling 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 readOnly, idempotent, open-world, and non-destructive, so the safety profile is covered. The description adds only that results are 'real-time' (实时); it says nothing about refresh cadence, result shape, or what happens on upstream failure, which would matter for an open-world read.

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

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

A single short sentence with the discovery tag front-loaded and no filler. It is efficient, though its brevity contributes to the missing parameter and usage detail 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?

With no output schema and no annotations about return content, the description never indicates what a hot-search entry contains or how limit shapes the response. For an open-world discovery tool, that omission leaves the agent unable to predict results.

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

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

There is one parameter (limit, 1-50, default 10) with 0% schema description coverage, and the description never mentions it. An agent gets no guidance on what limit controls or the effect of hitting the 50 cap, so the description fails to compensate for the coverage gap.

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

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

States a specific verb (读取) and resource (实时搜索热词), making clear this returns trending search terms rather than performing a search. This distinguishes it reasonably from the sibling bilibili_search, 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 [发现] tag hints at a discovery use case, but there is no statement of when to use this versus bilibili_search, bilibili_popular, or bilibili_ranking. No prerequisites or exclusions are given, leaving the agent to infer selection.

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, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds genuinely independent context: some AI subtitles require a logged-in session and depend on platform visibility, which explains why calling this tool may return nothing. It does not say what is returned when tracks exist, such as language or AI-generated flags, or whether the call is rate-limited.

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 compact clauses with no filler, and the caveat about authentication is placed right after the core purpose. The leading [字幕与弹幕] tag is questionable clutter because it names a sibling's domain, but the rest is efficient.

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 no output schema and 0% parameter coverage, the description says nothing about what a successful response contains, such as available tracks, their languages, or whether the subtitles are AI-generated. Combined with the missing differentiation from bilibili_subtitle_text, an agent has to guess both what is returned and when to call this tool rather than the sibling.

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 both parameters rely on the description, but 分P字幕轨道 only indirectly hints that cid identifies the video part. The description never explains that bvid is the video ID, that cid is the part ID, or how to obtain the cid, leaving the agent dependent on the schema's type and pattern alone.

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 has a specific verb-resource pair: 查询字幕轨道, and it notes that this is per-P (分P), which explains the cid parameter. However, the bracketed tag [字幕与弹幕] wrongly suggests this tool also handles danmaku, which is actually the sibling bilibili_danmaku, and the description never distinguishes this tool from bilibili_subtitle_text, the actual closest 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?

The description gives no guidance on when to use this tool rather than bilibili_subtitle_text, which presumably retrieves the same subtitles. It also gives no prerequisites about how bvid and cid must be obtained, for example via bilibili_video_pages. Only the implicit hint that 部分AI字幕 depend on login state suggests any usage context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety and side-effect profile is fully covered. The description adds one useful behavioral fact – that timestamped text is merged into combined output – but does not clarify whether timestamps are retained in the result or stripped, which matters for downstream use.

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 a bracketed category tag up front. Nothing is padded, though the category tag adds little value and the sentence could be more front-loaded toward the input expectation.

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 should describe the return shape, and it only says 'merge timestamped text' without specifying format (plain text lines, JSON array, whether offsets remain). For a single-input parsing tool this is adequate but leaves the agent guessing at the output contract.

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 single 'url' parameter is completely undocumented in the schema and the description only implies it is a subtitle JSON endpoint ('字幕接口返回的hdslb字幕JSON'). It does not state whether a video URL, subtitle JSON URL, or arbitrary URL is accepted, which is the key ambiguity given no max/format hints.

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 specifies a concrete action (parse hdslb subtitle JSON and merge timestamped text) but frames it in ambiguous terms – '读取字幕接口返回的hdslb字幕JSON' leaves it unclear whether this fetches or merely parses already-returned JSON. It does not distinguish itself explicitly from the closest sibling, bilibili_subtitles, which presumably supplies the URL this tool consumes.

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 or when-not-to-use guidance is given. Critically, it never states that the url should come from bilibili_subtitles, nor does it explain when to prefer this over that sibling, leaving the agent to infer the workflow.

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, idempotentHint, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only that the dynamics are 'public', implying no auth or private-content access is required, but nothing about pagination behaviour or what a returned item looks 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?

The single bracketed sentence is front-loaded and free of filler. It is efficient, though its brevity spills over into under-specification rather than tightness.

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 list tool with no output schema and 0% schema coverage, the description should cover pagination and the meaning of host_mid. Neither is addressed, so an agent must guess how to page through results.

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

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

Schema description coverage is 0%, so the description must explain both parameters; instead it only hints that host_mid identifies the uploader. The offset parameter, which controls pagination, is not mentioned at all, leaving the schema to carry undocumented 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 states a concrete verb (读取) and resource (公开动态) scoped to a specified uploader (指定UP主), which implicitly separates it from bilibili_my_feed (the caller's own feed). It does not, however, distinguish it from bilibili_dynamic_detail, which also returns dynamics.

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 bilibili_my_feed, bilibili_dynamic_detail, or bilibili_user_videos, nor any prerequisites such as needing a valid host_mid. Usage must be inferred entirely from the name.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true and idempotentHint=false, so the safety profile is carried structurally. The description reinforces the write nature with [互动写入] but does not add real behavioral context such as whether unfollow removes server-side state, whether repeated calls fail, or any rate limits.

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 clause with the write tag and the act mapping front-loaded; nothing is wasted. It is arguably terse given the undocumented parameters, but structurally it is clean.

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

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

For a destructive, non-idempotent write with a required confirm flag and a server-side --enable-writes prerequisite (documented only in the schema), the description does not summarize those gating conditions or the reversibility of the change. It is minimally adequate because annotations and the confirm param description cover part of the burden.

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

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

Schema coverage is only 25% — act, fid and re_src are undocumented in the schema. The description compensates for the most ambiguous one by mapping act=1/2 to follow/unfollow, and 'UP主' implies what fid targets, but re_src remains entirely unexplained in both places.

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

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

The description names a specific verb pair (关注/取消关注) applied to a specific resource (UP主), and the [互动写入] tag flags it as an interactive write. It is clearly distinguishable from read-oriented siblings such as bilibili_user_followings, though it does not explicitly name an alternative tool.

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 maps act=1 to follow and act=2 to unfollow, which is a minimal usage cue, but gives no guidance on when to prefer this tool over nearby siblings (e.g., bilibili_user_relation_stats or bilibili_user_followings) or on prerequisites such as login state.

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 read-only, idempotent, non-destructive behavior, so the description does not need to restate safety. It does add value by disclosing that pagination is required and that platform-side visibility restrictions can truncate results — a real behavioral caveat. However it omits whether invisibility means empty list vs. error, and does not mention the page-depth cap (pn max 1000) that bounds enumeration.

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, front-loaded with the action and resource, with the visibility caveat trailing. No filler, though the '[用户]' tag is decorative rather than 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?

Three undocumented integer parameters, no output schema, and a tool whose results are inherently paginated and gated by privacy settings. The description leaves the agent without parameter meaning, page-size semantics, or what an empty/restricted response looks like, which is inadequate 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 0%: pn, ps, and vmid have no descriptions at all. The description only implies pagination ('分页') and a user target, without defining vmid as the user ID, pn as page number, or ps as page size, nor their ranges/defaults in words. With zero schema coverage the description had the full burden of explaining parameters and did not meet it.

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

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

States a specific verb and resource: paginated reading of a user's public following list. It is clearly distinguishable from sibling write operation bilibili_user_follow and from bilibili_user_relation_stats, though the bracketed '[用户]' prefix adds no information.

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

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

No guidance on when to use this versus alternatives such as bilibili_user_relation_stats (counts) or bilibili_user_feed (dynamics). The only guidance-adjacent remark is the caveat that the platform restricts visible scope, which hints at partial results but does not route 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 readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds one genuinely new fact: the WBI signature is attached automatically, which tells the agent it need not supply auth signing. It omits whether login/credentials are required for this endpoint and whether any fields are privacy-gated.

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 clause with no filler. Brevity is appropriate, though at this length it is arguably under-specified rather than merely tight.

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?

No output schema, so the description should hint at what the profile contains (name, avatar, level, signature, follower counts) and whether authentication affects results. Given the low complexity and existing annotations, the omission is a gap but not fatal.

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% for the single parameter mid, and the description only implies it identifies the target UP主 without stating that it is the numeric Bilibili user ID, its format, or where to obtain it. The schema-only enforcement (integer, minimum 1) does not convey semantics.

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

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

States a specific verb and resource: read a UP主's public profile (读取UP主公开资料). An agent can distinguish it from the video/comment/live siblings, though it does not explicitly contrast with the close neighbor bilibili_user_relation_stats.

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, or prerequisite guidance. The nearby bilibili_user_relation_stats and bilibili_user_videos tools are never mentioned, so the agent must infer that this returns identity/profile data rather than relations or uploads.

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, idempotentHint, non-destructive and openWorld, so the safety profile is covered. The description adds only that the tool returns count-type statistics — no auth requirements, error behavior, or whether counts require a login session.

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

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

One compact sentence, front-loaded with the resource and immediately listing the returned fields. No filler, though it is terse enough to leave gaps.

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 stat tool with no output schema, the description should at least enumerate the full set of returned metrics and clarify the return shape; '等关系统计' leaves the output unspecified. It is 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 single parameter vmid has 0% schema description coverage, and the description never explains that vmid identifies the target user. With a required parameter undocumented in both schema and description, the agent must infer its meaning from the name.

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 is returned (关注数、粉丝数). It is distinguishable from bilibili_user_followings, though the description does not explicitly draw that contrast.

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

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

No when-to-use guidance is given: nothing says to prefer this over bilibili_user_info (full profile) or bilibili_user_followings (list of followed users). The '[用户]' tag hints at user context but is not explained.

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, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds two useful bits not in annotations: the '[用户]' marker signals a logged-in credential is required, and '自动附加WBI签名' says signing is handled internally. It says nothing about pagination limits, error cases, or what an invalid/private mid returns.

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

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

A single short sentence with the resource stated up front and no filler. It is efficient, though so terse that brevity shades into under-specification rather than crispness.

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 five undocumented parameters, no output schema, and a list-returning tool, the description should at least characterize the response (video entries, paging behavior) and the role of mid. Neither is present, so an agent must guess at call semantics beyond the required field.

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% across 5 parameters, and the description only indirectly implies that 'mid' identifies the UP主. It gives no meaning for pn/ps (paging), tid (partition filter) or order (pubdate/click/stow), leaving the agent to infer everything from bare field names and constraints.

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: read a UP主's uploaded-video list, which is distinguishable from siblings like bilibili_user_feed or bilibili_video_related. It doesn't explicitly name those siblings, so it stops short of full 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 purpose implies the scenario (enumerating one creator's uploads), but there is no explicit when-to-use/when-not, no mention of alternatives such as bilibili_search or bilibili_user_feed, and no prerequisites stated beyond the implicit auth marker.

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 and openWorldHint=true, so the write/destructive profile is fully covered in structured data; the description's [互动写入] merely restates it. It adds no extra context about the confirmation flow, the effect of simultaneous add/del in one call, or any rate-limit/permission behavior.

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

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

One compact sentence with the write nature front-loaded and the comma-separated format detail attached directly to the folder-ID concept. No filler, though the sentence is arguably too short given the tool's complexity.

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

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

There is no output schema, and for a destructive, non-idempotent write with five parameters the description omits what the tool returns and how add/del combine in a single call. The 20% schema coverage leaves several parameters undocumented in both places, so the definition is only marginally complete.

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

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

Schema coverage is only 20%, so the description must carry weight; '夹ID以逗号分隔' usefully explains the format of add_media_ids/del_media_ids, which the schema leaves bare. However, it says nothing about rid (the video ID), the type field, or how add and del interact, so the compensation is only partial.

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 pair (add/remove from a favorite folder) and resource, and signals the write nature with the [互动写入] tag. This distinguishes it from read siblings like bilibili_favorite_items and from other write siblings like bilibili_watch_later_add, though it never names an alternative 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 implies usage (managing a favorite folder's contents) but gives no when-to-use/when-not guidance, no mention of the confirm gate or --enable-writes prerequisite (these live only in the schema), and no pointer to a sibling such as bilibili_favorite_folders for discovering folder IDs.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety and idempotency are covered. The description adds that this is a broad metadata read spanning several sub-resources, which is context beyond the annotations, but says nothing about auth needs, rate limits or failure modes for invalid/private videos.

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 bracketed-tag plus one clause, with the resource type front-loaded and no filler. It is terse to the point of omitting useful detail, but nothing present is wasteful.

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

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

For a one-parameter read-only metadata tool with rich annotations and no output schema, the description's field inventory (title, intro, uploader, aid, cid, parts, stats) effectively serves as the return-value contract. Nothing critical to invoking it correctly 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?

There is a single required parameter (bvid) at 0% schema description coverage; the schema gives only a regex. The description never clarifies what bvid is or that the BV-id format is required, so it does not compensate for the coverage gap, though the parameter is at least self-evident from its name.

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-plus-resource (读取视频) and enumerates the fields returned (title, intro, uploader, aid, cid, parts, stats), so the agent knows exactly what this fetches. It partially blurs with siblings such as bilibili_video_stat and bilibili_video_pages by listing 统计 and 分P among its outputs, but the 'one call returns everything' framing is still distinguishable.

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 statement of when to prefer this over bilibili_video_stat, bilibili_video_pages or bilibili_search, and no prerequisites noted. The agent must infer usage 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=false, destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds the useful point that this is a bidirectional toggle (like=1 set, 2 unset) rather than a one-way action, but says nothing about auth requirements or that the toggle is not idempotent in practice.

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: category tag, action pair, then the parameter mapping. Nothing is wasted and the write nature is front-loaded.

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 confirm gate and the --enable-writes server requirement are documented in the schema, and annotations cover destructiveness, so the essential mechanics are available. However, for a state-changing tool with no output schema, the description never states that an authenticated session is required or what happens on failure, leaving a meaningful 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 only 33% (only confirm is documented), so the description must carry weight — and it does, decoding the otherwise opaque enum by stating like=1 means like and 2 means unlike. The aid parameter is left unexplained, but its meaning is conventional for this API family.

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?

Names a specific verb and resource (点赞/取消点赞视频) plus a category tag [互动写入] that separates it from the many read-only siblings. It is clearly distinct from bilibili_video_favorite (favoriting) and the comment/watch-later write tools by resource and action, though it does not explicitly call out those neighbours.

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

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

Usage is only implied: the [互动写入] tag and the like/unlike phrasing tell an agent this is the mutation counterpart of video info, but there is no statement of prerequisites (login, --enable-writes) or of when to prefer this over bilibili_video_favorite. An agent can infer the context but must guess the conditions.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful return-field context (cid, title, duration) but says nothing about auth, rate limits, or error behavior; with annotations carrying the behavioral load, a 3 is appropriate.

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

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

One front-loaded sentence with zero filler. Every element (视频, 分P, cid, 标题, 时长) earns its place.

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

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

For a simple one-parameter read tool with no output schema, listing the returned fields is helpful and annotations cover safety. However, it omits any bvid guidance and any routing signal versus the many sibling video tools, leaving 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 never mentions the required bvid parameter. The schema does supply a pattern and length bounds, but the description does not explain what bvid means or where to obtain it, so it fails to compensate for the coverage gap.

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

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

Uses a specific verb (读取) and resource (视频各分P) and names exactly what is returned: cid, title, and duration. That is clear enough to distinguish it from generic video-info tools in practice, but it never explicitly contrasts itself with siblings like bilibili_video_info or bilibili_video_stat.

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?

Provides no when-to-use guidance and no alternatives. An agent cannot tell from the description whether to call this or bilibili_video_info when it needs video metadata, nor whether this tool is only meaningful for multi-part videos.

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

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

Annotations already cover read-only, idempotent, non-destructive, and open-world behavior. The description adds important runtime behavior beyond that: the returned URLs are temporary, time-limited, and tied to the current session's playback 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 tightly written sentence with the key behavior front-loaded. The '[视频]' prefix and the expiry warning are useful and carry 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?

For a five-parameter tool with no output schema and no schema parameter descriptions, the definition is too sparse. It conveys the broad result type and URL expiry, but leaves parameter meanings, quality/format controls, and actual response structure unclear.

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% across five parameters, so the description must compensate, but it names no parameters and does not explain bvid, cid, qn, fnval, or fourk. The only relevant hint is '清晰度', which loosely relates to quality but does not clarify how qn or the format parameters work.

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

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

The description states a specific verb and resource: obtain temporary playable media URLs and quality for the current session. The '[视频]' tag helps distinguish it from live playurl tools, but no sibling tool is named and the distinction from tools like bilibili_video_info is only implicit.

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 implies the tool is for getting playable media addresses, but gives no explicit when-to-use guidance, no alternatives such as bilibili_video_info or bilibili_video_pages, and no stated prerequisites beyond the vague 'current session' scope.

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, idempotentHint=true, and destructiveHint=false, so safety is fully covered by structured fields. The description adds nothing beyond that — no information on result size, pagination, or whether the recommendation list is personalized or requires auth.

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 phrase with zero waste and the resource front-loaded. It is efficient, though this brevity contributes to the missing context 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 one-parameter tool with no output schema, the description should at least clarify the parameter's role and roughly what comes back (list of videos, count, ordering). Neither is present, leaving the agent to guess at return shape.

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 single `bvid` parameter is undocumented in both schema and description. The regex pattern hints at the BV-id format, but the description never explains that `bvid` identifies the seed video whose recommendations are returned.

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 ('关联推荐视频'/related recommended videos), which is enough to separate it from bilibili_video_info, bilibili_video_pages, or bilibili_video_tags. It doesn't explicitly name a sibling, but the resource noun is distinctive.

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

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

Usage is only implied: an agent can infer this returns recommendations for a given video. There is no statement of when to prefer it over bilibili_video_info or bilibili_popular, and no exclusions or prerequisites.

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?

注解已经声明了只读、幂等和开放世界，因此安全概况已清楚，描述没有与之矛盾。额外的“从当前详情接口提取stat”暗示这些计数来自详情端点，可能反映缓存或时间点数据，这是有用的上下文，但没有提及刷新行为、认证需求或哪些字段可能缺失。

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?

一句话，前置了资源标签和获取内容的列表，没有填充内容。只有轻微的冗余：“stat”和列出的计数名称说的是同一件事。

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?

一个简单只读单参数工具，安全概况已充分注解，因此描述需求适中。它仍然缺少必需的 bvid 标识符语义，也没有说明返回的 stat 对象包含哪些内容，不过缺少输出 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 描述覆盖率为 0%，并且 schema 只作为约束（没有描述）暴露 bvid 的 BV 格式模式。描述完全没有说明该参数，因此调用者不读 schema 就不知道它需要 BV ID，也不知道该格式。

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

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

明确动词加资源：从详情接口读取视频的播放、弹幕、评论、收藏、投币与点赞计数。清楚表明这是统计子集，从而与 bilibili_video_info 区分开，不过它从未明确指出后者，只是暗示了范围上的差异。

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?

范围（仅 stat 计数）暗示当你只需要互动指标而不是完整视频元数据时使用它，但没有明确说明何时选择它而不是 bilibili_video_info，也没有要求或排除项。

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, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds nothing beyond that – no note on auth requirements, rate limits, or whether tags come from an unauthenticated public endpoint, even though the tool is marked openWorld.

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?

It is a single short sentence with zero padding, which is good, but it is under-specified rather than appropriately concise – the bracketed '[视频]' prefix is a category tag that adds little for an agent.

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, an agent gets no hint about the shape of the returned tag list (names? ids? counts?) or whether authentication is needed. For a single-param read tool this is minimally acceptable but leaves real gaps.

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

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

Schema coverage is 0%: the single required 'bvid' parameter has a pattern and length constraints but no textual explanation in either schema or description. The description never mentions bvid or its expected BV-id format, so it fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('读取视频标签' – read a video's tags), which is distinguishable from siblings like bilibili_video_info or bilibili_video_stat. It does not explicitly contrast with any sibling, but the resource is unique enough that an agent can place 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 versus bilibili_video_info (which may also surface tag data) or how it relates to other metadata tools. No prerequisites, no exclusions, no alternatives 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 destructiveHint=true, idempotentHint=false and openWorldHint=true, so the risk profile is covered. The '[互动写入]' tag reinforces that this mutates the user's account state, but adds little beyond the annotations and says nothing about what gets destroyed or whether re-adding is safe.

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 a bracketed category tag and zero filler. Appropriately sized, though it could have used that brevity budget for one routing or prerequisite 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 destructive mutation with no output schema, the definition should at minimum state the write-mode prerequisite and clarify the aid parameter. Annotations carry the safety profile, but the agent is left to infer both the required server flag and how to source 'aid'.

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

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

Schema coverage is only 50%: 'confirm' is documented, but 'aid' has no description anywhere. The description does not explain what 'aid' is (the numeric video ID) or where an agent obtains it, so it fails to compensate for the coverage gap.

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

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

The description names a concrete verb+resource ('将视频加入稍后再看' = add video to Watch Later), which is immediately distinguishable from bilibili_watch_later_delete and bilibili_my_watch_later. It does not explicitly call out those siblings, but the action 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?

There is no guidance on when to use this versus alternatives such as bilibili_video_favorite or bilibili_my_watch_later, and no mention of the write-enabled service prerequisite (that lives only in the confirm parameter schema). Usage is inferable 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 destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is fully carried by structured data. The description only restates that it is a write, adding nothing about side effects, partial-failure behavior, or the fact that removal is irreversible. Since annotations do the work here, a low score reflects the description's lack of added context rather than a contradiction.

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

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

One short sentence, front-loaded with the write tag followed by action and format. No filler, though the extreme brevity is part of why behavioral context is missing.

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

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

For a destructive write tool with no output schema, the definition leaves out what happens on partial success, whether missing aids error out, and any confirmation semantics (that lives only in the schema's confirm field). Enough to call it correctly, but thin for a destructive operation.

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 50%: 'confirm' is documented in the schema, while 'avids' has only a pattern. The description usefully explains in words that avids is a comma-separated list, which is the undocumented parameter, but it adds nothing about limits, invalid-id handling, or the confirm gate. Reasonable compensation, hence a middling score.

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 (remove/移除) and resource (稍后再看/watch later) plus the input format (comma-separated aids), which distinguishes it from bilibili_watch_later_add and bilibili_my_watch_later. It stops short of explicitly naming the sibling alternatives, but the purpose itself 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?

There is no guidance on when to use this versus bilibili_watch_later_add or bilibili_my_watch_later, nor any prerequisite or exclusion noted. The [互动写入] prefix implies a write operation but gives no conditions for use.

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