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

With no annotations, the description carries the full burden and does disclose real behavior: read-only, no dispatch or retry side effects, and the important caveat that a receipt is not verified account state so it should not be treated as confirmation. It stops short of covering auth requirements, error behavior for unknown action_id, or lifetime of the receipt.

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 with no filler, and the read-only nature is front-loaded. It is arguably over-compressed given the missing context, but the structure is clean and every sentence carries signal.

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?

An output schema exists, so return-value shape need not be explained. However, for a one-param lookup among three similar *_action_status siblings, the description omits action_id provenance, the scope of 'public-action', and how this differs from the comment/DM variants.

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 action_id parameter is completely undocumented. The description says nothing about where action_id comes from, its format, or whether it is reusable, so it fails to compensate for 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?

It states a read of a 'durable public-action receipt/state', which gives a verb and a resource, but 'public-action' is unexplained jargon. Against siblings like bili_comment_action_status and bili_dm_action_status the description gives no clue which action domain this covers, so an agent cannot confidently distinguish it without opening the schema.

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

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

'never dispatches or retries' implicitly tells the agent this is a polling/lookup call rather than a trigger, which is useful. But there is no stated when-to-use condition, no prerequisite (e.g. that action_id must come from a prior action call), and no routing to the sibling status 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?

No annotations are provided, so the description carries the full burden. It does disclose the one behavior that matters most: this is local bookkeeping (saving resume position) with no remote account mutation. It says nothing about idempotency, whether the decision affects later browse_state results, or what happens with a stale/invalid ref.

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

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

Two tight sentences, front-loaded with the action, no filler. Phrasing 'explicitly choose selected/skipped/position' is slightly compressed to the point of ambiguity, 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?

An output schema exists, so return values need no explanation, and the local-vs-remote distinction is covered. However, for a 4-parameter mutation tool with zero schema description coverage, leaving the decision vocabulary and 'part' undefined is a real gap 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 coverage is 0%, so the description must compensate. It loosely gestures at decision values ('selected/skipped') and at position_seconds ('position'), but never defines the allowed decision strings (no enum in the schema either) and never mentions 'part' at all. An agent still has to guess the accepted 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 concrete action on a named object: choose selected/skipped/position for a returned video ref and persist a local resume position. The closing clause ('does not click, watch or change any Bilibili account state') implicitly separates it from bili_watch_video and bili_watch_status, though that contrast is never made explicit by name.

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?

'for a returned video ref' implies it is called after a search/discover/browse call produced refs, and the negative clause tells the agent not to use it to actually watch. But no sibling is named as the alternative for the watching path, and no preconditions for calling it 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?

With no annotations, the description discloses that this reads local recent state and is not durable memory or watch proof. It does not state permissions, side effects, or other behavioral constraints beyond that scope caveat.

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

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

Two tight sentences with no waste; the scope and caveat are front-loaded and useful.

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 output schema exists, so return-value details need not be repeated. However, for a read tool with two undocumented parameters and no annotations, the description leaves important invocation details such as limit/cursor behavior unstated.

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

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

The schema has two parameters, limit and cursor, with 0% description coverage, and the description does not explain either one. 'Recent' loosely implies a bounded result set, but cursor pagination is not addressed.

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 read operation and resource: recent local discovery refs plus seen/selected/skipped and part/time positions. It is distinguishable from long-term memory, but it does not explicitly contrast with sibling tools such as bili_browse_advance or bili_discover.

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 by calling this navigation state and ruling out long-term memory or proof of watching. It gives no explicit when-to-use guidance versus the related browse/discover siblings.

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

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

With zero annotations the description carries the full burden, and it does real work: it discloses that the readback is optional, bounded and anonymous, that it can discriminate accepted/review/visibility, and that absence within one page means unknown rather than failure. The "Never resend" directive is exactly the caution an agent needs after a partial result, though it doesn't state whether this call has rate limits or auth requirements.

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

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

Three short clauses, front-loaded with the purpose and followed by the option and the imperative warning. It is efficient, but the telegraphic phrasing of "absent in one page stays unknown" costs clarity for brevity.

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?

An output schema exists, so return values need not be spelled out, and the description covers the key semantics of partial/unknown results. What is missing is where action_id comes from and the explicit sequencing with bili_comment_send, which matters for a status-polling tool.

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

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

Schema coverage is 0%, so the description must compensate. "Optional bounded anonymous readback" does map to check_visibility and even hints at an anonymity property and a bound on the readback, but action_id (the required parameter) is never explained — its origin from a prior send is left implicit.

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?

"Read durable send status" gives a verb (read), a resource (send status) and a notable trait (durability), but never names the comment domain or ties itself to a prior bili_comment_send action. Against siblings like bili_dm_action_status and bili_account_action_status, the description alone gives no basis for discrimination — only the tool name does.

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 supplies a hard negative ("Never resend") and frames check_visibility as optional, which implies use after a send rather than instead of one. It never states the trigger condition (e.g. "call after bili_comment_send returns pending") or names an alternative tool, so the agent must infer the call site.

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

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

No annotations are provided, so the description carries the full burden. Beyond implying a read-like lookup, it discloses no safety profile, permissions, rate limits, or failure behavior; the single useful clue is that unseen subreplies may require root/page. That is thin for an unannotated tool.

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

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

Two short sentences with the core locating condition front-loaded and no padding. It is efficient, though the terseness edges toward cryptic rather than clarifying.

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?

An output schema exists so return values need no explanation, but with no annotations and 0% parameter coverage the description should do more. It omits why one would pick this over other comment tools and provides no format guidance for the required bvid, leaving too much to inference.

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 4 parameters, so the description must compensate. It adds meaning for rpid ("exact"), root ("known thread root"), and page (needed for unseen subreply), but leaves bvid entirely unexplained and gives no formats or defaults.

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

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

It states a specific verb and resource ("Locate a comment") qualified by exact rpid and thread root, which is more than a restatement of the name. However, it never clarifies what "context" means here (surrounding thread? parent chain?) nor explicitly differentiates it from bili_comments or bili_comment_replies, so the agent must infer the distinction.

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?

"Previously read references help; unseen subreply can require root/page" is a vague hint about preconditions rather than a when-to-use rule. No alternatives are named and there is no explicit statement of when NOT to use this versus the sibling comment 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?

No annotations are provided, so the description carries the burden, and it does disclose two real behavioral traits: a cap of up to 20 items and the caveat that results are not a full history. It says nothing about auth needs, rate limits, or ordering, but the bounded-pagination disclosure is genuine added value that the schema and annotations do not supply.

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 with no filler, and the scope constraint ('one root comment') is front-loaded ahead of the limit caveat. The telegraphic style is compact but borders on under-specification rather than verbosity.

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

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

An output schema exists, so return-value explanation is not required and the 'complete IDs/context' note is appropriately short. What is missing is any statement of the relationship to sibling comment tools and what 'bvid' selects, leaving the agent to infer how this slots into the comment workflow.

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 has to compensate. It meaningfully clarifies three of four parameters in passing: 'root' (one root comment), 'page' (reply page), and 'num' ('up to 20'). 'bvid' is never mentioned, though its meaning is conventional. Partial but useful compensation given the bare schema.

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

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

The description names a specific verb and resource: expanding one root comment's reply page, with full IDs and context. It implicitly distinguishes this from the sibling bili_comments (which would list top-level comments), though it never names that distinction explicitly. Slightly telegraphic phrasing ('complete IDs/context') leaves the exact payload a bit fuzzy.

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 full-history claim' implies paginated, bounded retrieval, and 'one root comment' implies the input scope. However, there is no explicit guidance on when to choose this over bili_comments or bili_comment_context, no prerequisites, and no exclusions. The agent must infer the selection criteria from the sibling names 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that replies require separate permission that defaults off and that there is no force override, but it omits other important behavior such as side effects, failure modes, or rate limits for a write action.

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

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

The description is compact and front-loads the main action and scope. The semicolon-separated fragments are efficient, though 'Separate reply permission defaults off; no force' is somewhat telegraphic and could be clearer.

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

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

This is a five-parameter write tool with no schema descriptions and no annotations, and the description omits meaning for bvid, text, and especially the required action_id. The output schema covers return values, but the input context is not sufficient for an agent to call the tool 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. It explains that root is required, parent is only for subreplies, and IDs are strings, but it does not explain bvid, text, or the required action_id, leaving most parameters undocumented.

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 action (reply), resource (comment thread), and scope (observed thread with root rpid required). It does not explicitly name the sibling alternative bili_comment_send, so it falls short of full sibling differentiation.

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

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

It gives structural usage guidance: root is required, parent only applies for subreplies, and reply permission defaults off with no force option. However, it does not explicitly say when to use this versus bili_comment_send or bili_comment_replies, leaving the alternative routing implied.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that data is external and untrusted, that IDs are strings, and that pagination can be page-based or cursor-based. However, it does not discuss permissions, rate limits, read-only status explicitly, or error behavior, leaving meaningful gaps.

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

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

The description is short, dense, and front-loaded with the core operation. Every clause adds information: sortable modes, returned fields, ID typing, pagination mode, and untrusted-data warning. There is no wasted phrasing.

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

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

The presence of an output schema reduces the need to explain return values, and the untrusted-data warning is valuable. Still, with no annotations and 0% schema coverage, the description omits enough parameter and safety detail that an agent may need to infer behavior around num, bvid, and cursor usage.

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 for all five parameters. It adds meaning for sort ('hot/time'), pagination ('page or native cursor'), and BV/IDs as strings, but leaves num undefined and does not clarify bvid or cursor format. It partially compensates but still has clear gaps.

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

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

The description states a specific verb and resource: 'Read one hot/time comment page.' It also lists the returned comment fields and notes nested references. It does not explicitly distinguish this tool from siblings like bili_comment_replies or bili_comment_context, so it falls short of a 5.

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

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

The description mentions 'page or native cursor' and 'hot/time' sorting, but gives no guidance on when to use page versus cursor, when to choose hot versus time, or when to use this tool instead of related comment tools. There are no explicit alternatives or exclusions.

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

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

With no annotations, the description carries the full burden and discloses permission gating, default-off behavior, no force/retry/batch, and that a receipt does not prove public visibility. However, it omits whether the comment is reversible/deletable and any rate-limit behavior.

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

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

Three short sentences with no filler; the key precondition and caveats are front-loaded. It is appropriately sized for a write 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?

The description covers permission gating and visibility caveats, and an output schema exists so return format need not be explained. But with three required parameters at 0% schema coverage and no annotations, the missing parameter roles leave the definition incomplete 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 coverage is 0%, and the description never explains bvid, text, or action_id. The most critical parameter, action_id, is completely undefined, so the description does not compensate for the undocumented 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 identifies a top-level public comment and contrasts it with reply-oriented siblings via 'top-level,' making the resource and scope clear. It lacks an explicit action verb like 'send' or 'create,' but the meaning is still unambiguous.

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

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

It states a hard precondition: 'only when comment permission explicitly enabled; defaults off,' and rules out force, auto-retry, and batch. It does not explicitly name bili_comment_reply as the alternative for replies, so guidance is strong but not fully complete.

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

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

No annotations, so the description must carry behavioral burden and it does: it discloses the 6-minute segment limit, snapshot-pagination semantics, and the "no UID reverse lookup" limitation. It omits any permission or rate-limit note, keeping it from a 5.

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

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

Two dense sentences that front-load the core purpose and then the paging constraint; nothing is wasted. The telegraphic phrasing is slightly terse but 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?

An output schema exists, so return values needn't be described, and the description covers segmenting, paging, and part indexing well. The remaining gap is the meaning of bvid and limit, which is minor against an otherwise complete behavioral picture.

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 clarifies that part is 1-based, that cursor drives paging, and that start/end seconds define the range, but bvid and limit are never explained, leaving half the parameters undocumented 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?

States a specific verb and resource ("Read original danmaku") and scopes it to "one 6-minute segment." An agent can tell this fetches danmaku timing data rather than comments, but "original" is left undefined and there is no explicit sibling differentiation.

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

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

Gives concrete operational guidance: use cursor to page the full range snapshot, and explicitly pick a later time range to continue past the 6-minute window. No exclusion guidance against bili_comments or other siblings, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden and does well: it discloses that refresh builds a new source snapshot rather than paginating the old one, warns that the platform may return duplicate videos, and notes the mutual exclusion of refresh and cursor. Gaps remain on auth requirements (e.g., whether 'following' needs login) and on read-only safety, which no annotation confirms.

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?

Front-loaded with the purpose, then dense semicolon-delimited clauses that each carry distinct information about refresh, cursor, and sources. Slightly telegraphic phrasing ('actual source and personalization limits returned') costs a little readability.

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?

An output schema exists, so return values needn't be described, and the description covers the interaction between the two non-obvious parameters well. Missing detail on limit behavior, category semantics, and authentication for the 'following' source keeps it short of complete.

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

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

Schema description coverage is 0% with 5 params, so the description must supply all meaning. It explains cursor, refresh, and enumerates the source values, but says nothing about limit (default 10) or category ('All'), leaving two of five parameters completely undefined.

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 ('Discover video candidates') and adds a defining scope constraint ('without a BV'), which separates it from BV-based tools like bili_video_info and from bili_search. An agent can identify the tool's role without opening the schema.

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

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

Explicitly states the default mode (homepage), the two continuation modes (refresh=true for a new fetch, cursor for the saved snapshot), and that they cannot be combined. It never routes to siblings like bili_search, bili_related, or bili_browse_advance, so the alternative-selection guidance is incomplete.

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

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

With no annotations, the description carries the behavioral burden and does well: it states the operation is read-only, has no side effect/retry, exposes no message text/credentials, and warns that platform recipient read status is unknown. It does not mention auth requirements or rate limits, but the key safety and limitation context is disclosed.

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

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

The description is short and front-loads what the tool reads. Every clause adds relevant scope or caveat, though the telegraphic 'no side effect/retry' phrasing is slightly terse. It wastes little space overall.

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

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

The tool is simple and has an output schema, so return value details are not required. The description covers non-obvious safety and read-status caveats, but it omits the origin/meaning of action_id and does not explicitly route the agent against sibling DM tools. Adequate but with 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?

The schema has one required parameter, action_id, with 0% description coverage, so the description must compensate. It implies action_id refers to a DM send action but does not explain where to obtain it, its format, or its lifecycle. That leaves an important parameter under-specified.

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: reading durable metadata for a DM send. It also clarifies that this is not a send/retry operation, which helps differentiate it from bili_dm_send. It does not explicitly name the sibling alternative, but the purpose is clear enough to select the 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?

The description implies this is used to inspect the result/status of a DM send, especially by saying 'no side effect/retry.' However, it does not explicitly say when to use this tool versus bili_dm_history, bili_dm_sessions, or bili_dm_unread. Usage is inferable but not fully guided.

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

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

With no annotations, the description does useful work by disclosing that it is read-only ('Does not reply/mark read'), caps pages at 30, and uses a native sequence cursor. It omits important behavioral context such as authentication requirements, ordering direction, rate limits, and whether begin_seqno is inclusive/exclusive.

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 three compact sentences and front-loads the core purpose. Each sentence contributes something, though the ID-type sentence mixes input and output concerns and is partly redundant with the schema.

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

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

For a three-parameter read tool with an output schema, the definition covers purpose, page limit, cursor, side effects, and ID return type. It remains incomplete about authentication, result ordering, and pagination direction, which are relevant for reliably calling a history 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%, so the description must carry parameter meaning. It adds 'max 30' for limit and calls begin_seqno a 'native sequence cursor,' but the ID type details largely restate what the anyOf schema already encodes, and it never explains talker_uid's role, cursor direction, or pagination mechanics.

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

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

The description states a specific verb and resource: 'Read one private-chat message page (max 30) with native sequence cursor.' This clearly distinguishes it from bili_dm_send and bili_dm_unread, though it does not explicitly name those siblings.

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

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

Usage is implied by 'history' and 'Does not reply/mark read,' which signals a read-only context. However, the description does not explicitly say when to use this versus bili_dm_sessions or bili_dm_unread, nor does it explain how to obtain talker_uid or how to paginate with begin_seqno.

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

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

With no annotations, the description carries the disclosure burden well: it warns this sends a REAL irreversible DM, notes the 500-char limit, the required stable unique action_id, and the crucial caveat that there is no recipient read receipt ('unknown does not mean unread or read'). It omits rate-limit and error/retry behavior, but the core safety and side-effect profile is disclosed.

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

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

Front-loads the core action and account context, then layers constraints and caveats in compact sentences with no filler. It is dense but every clause addresses a real operational concern; slightly telegraphic phrasing reduces readability marginally.

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

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

For a mutation tool with an output schema (so return values need not be explained), the description covers the essential safety, formatting, and idempotency concerns an agent needs before invoking. Minor gaps around failure/error handling remain, but nothing critical to correct invocation is missing.

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

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

Schema coverage is 0% across all 3 params, so the description must compensate, and it largely does: it explains receiver_uid accepts a decimal string or legacy safe integer, clarifies returned IDs are strings, states the 500-char text cap, and stresses action_id must be stable and unique. These add genuine meaning beyond the bare schema titles.

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

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

States a specific verb and resource ('Send ONE real text DM') and pins the account context ('process-pinned account'). An agent can immediately distinguish this write action from read siblings like bili_dm_history or bili_dm_sessions without inspecting schemas.

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

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

Gives explicit when-not guidance: 'Never auto resend unknown/prepared; inspect history and action_status first' and 'No automatic historical replies', which effectively routes to bili_dm_history and bili_dm_action_status. Clear context is provided, though the alternatives are named indirectly via concepts rather than exact tool names.

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

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

With no annotations, the description carries the burden, and it does useful work by flagging 'Untrusted external data' (a prompt-injection warning) and disclosing the 'up to 30' ceiling. It does not state auth requirements, pagination behavior, or explicitly that the operation is read-only beyond the word '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?

Two short, front-loaded sentences with no filler; the untrusted-data warning is placed where it will be read before invocation. Minor jargon ('stable talker UIDs') asks the reader to already know the domain.

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?

Return values need not be described since an output schema exists, and the security caveat is a real addition. However, for a listing tool with three closely related DM siblings, the absence of routing guidance leaves 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?

The single 'limit' parameter has 0% schema description coverage, so the description must compensate. 'Up to 30' conveys the maximum cap for that parameter, which is genuinely useful, but it does not explain the default of 20 or how the limit is applied.

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

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

Specific verb ('Read') plus resource ('private-chat sessions') and a hint of the fields returned ('talker UIDs and last messages'). It is distinguishable from bili_dm_unread and bili_dm_history by focusing on the session list rather than messages or counts, though the boundary is only implied.

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 choose this over bili_dm_history, bili_dm_unread, or bili_dm_send. An agent must infer from the name alone that this lists conversation threads rather than reading one thread's messages.

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

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

With no annotations, the description carries the full burden. It usefully discloses that the tool does not listen, auto-reply, or send read acknowledgements, and that results are bounded to one server page, but it omits permission requirements and other operational details.

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

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

Two short sentences with no wasted language. The purpose is front-loaded and the exclusions follow immediately, making the description easy to parse.

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

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

For a zero-parameter read-style tool with an output schema, the description is largely complete. It explains the bounded page scope and non-side-effect behavior, though additional auth or rate-limit context could improve completeness.

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

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

The tool has zero parameters, so there is no parameter semantics to explain. The schema coverage is 100%, making the baseline score 4 appropriate.

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

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

The description states a specific verb and resource: inspect DM unread counts. It also scopes the operation to one bounded server page, which distinguishes it from broader DM listing tools, though it does not name a specific sibling alternative.

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

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

Usage is implied by 'Inspect DM unread counts' and clarified by exclusions ('No listener/auto reply/read acknowledgement'), but the description does not explicitly say when to choose this tool over bili_dm_sessions or bili_dm_history.

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

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

No annotations exist, so the description carries the full burden; it does disclose pagination behavior and stable snapshot cursors, which is valuable non-obvious behavior. It does not say what 'accessible' means (auth/permission scope) or whether results are cached/snapshotted across cursor calls in a way that could go stale.

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 sentences, front-loaded with the read action and followed by the behavioral note and exclusion. No wasted words, though the telegraphed phrasing ('native server pagination', 'stable snapshot cursors') is dense for its length.

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?

An output schema exists so return values need not be described, and pagination is covered. However, for a 3-parameter tool at 0% schema coverage, the description leaves the meaning of media_id and the access condition of 'accessible' unexplained, which an agent needs to call it correctly.

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

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

Schema coverage is 0%, so the description must compensate and it largely does not: it alludes to pagination (limit/cursor) via 'native server pagination plus stable snapshot cursors' but never defines cursor stability semantics, and never explains media_id or what a 'folder' identifier is.

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 accessible folder videos') with a clear scope, and the negative clause 'No favorite/unfavorite action' helps separate it from bili_favorite_update. It does not, however, distinguish itself from bili_favorite_lists, which an agent would need to tell apart.

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 'No favorite/unfavorite action' implicitly routes mutation intent to bili_favorite_update, which is useful. But there is no explicit statement of when to call this versus bili_favorite_lists or bili_user_videos, and no prerequisites or access conditions are given.

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

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

With no annotations, the description carries the burden and does disclose that the operation is read-only and never creates or modifies folders. It also mentions a stable local-page cursor, which is useful behavioral context. However, it does not explain access requirements for 'accessible' folders or pagination 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?

The description is short, front-loaded, and avoids filler. The phrase 'string IDs and stable local-page cursor' is slightly compressed and ambiguous, but the read-only guarantee is stated clearly and early.

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 output schema exists, so return values do not need explanation. Still, for a tool with no annotations and 0% schema description coverage, the description omits the limit parameter and does not clarify access or pagination behavior. 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?

Schema description coverage is 0%, so the description should compensate for all three parameters. It explains that an empty uid means the caller's own account and that cursor is a stable local-page cursor, but it never explains the limit parameter. Partial coverage leaves meaningful gaps.

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: reading accessible favorite folders. It distinguishes itself from mutation sibling bili_favorite_update by explicitly saying it never creates or modifies folders. The only minor gap is that 'accessible' is somewhat vague, but the core purpose is clear.

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

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

It provides one useful usage condition: an empty uid means the caller's own account. The read-only constraint also implicitly rules out mutation, but it does not explicitly name alternatives such as bili_favorite_update or bili_favorite_content. Usage is implied rather than fully guided.

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

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

No annotations are supplied, so the description carries the full burden; it does disclose the auth prerequisite (favorite permission), the ownership restriction, single-item granularity and no batching. It says nothing about idempotency, what happens on repeated calls, rate limits, or what is returned, which matters for a mutation tool.

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

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

Two short, front-loaded sentences with the scope constraints leading and the parameter hints trailing; no filler. The 'defaults OFF' clause is the one piece that adds ambiguity rather than information.

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

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

For a four-required-parameter mutation with zero schema coverage and no annotations, the description leaves the most cryptic field (action_id) undefined and never clarifies the bvid/media_id pairing. The output schema existence lowers the need to describe returns, but the input-side gaps remain significant.

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

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

Schema description coverage is 0% with four required parameters, and the description only glosses 'Folder ID string' (presumably media_id) and hints at 'enabled' via 'defaults OFF'. bvid and especially action_id — an non-obvious required string — get no explanation at all.

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) and resource (ONE video in ONE own favorite folder), which clearly separates it from the read-only favorites siblings (bili_favorite_lists, bili_favorite_content). The scope qualifiers are strong, but 'defaults OFF' sits awkwardly next to a required 'enabled' parameter and muddies what the operation does by default.

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

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

Gives real preconditions and exclusions: requires favorite permission, must be your own folder, exactly one video, no batch. It does not name a sibling alternative or say when to prefer a different tool, so it stops short of the top band.

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

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

With no annotations, the description still discloses the two most important safety traits: a consent/permission gate and an off-by-default posture that prevents accidental follows. It omits idempotency, error behavior, and what unfollow does to existing state, but the output schema covers return values.

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 dense sentence that front-loads the scope constraint and the permission prerequisite, then lists exclusions. No filler, nothing redundant.

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

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

This is a state-changing social action with zero annotation coverage and three required, undocumented parameters, one of which (action_id) is completely opaque. The description establishes safety posture but leaves an agent unable to confidently construct the enabled/action_id semantics.

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 only clarifies that uid must be a single UID. The enabled boolean's direction and, critically, the purpose of the required action_id are never explained 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 pair (follow/unfollow) on a specific resource (ONE UID), which immediately distinguishes it from batch or account-wide operations. The scope exclusions reinforce this, though the follow-vs-unfollow direction is never tied to a named parameter.

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

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

Gives a clear precondition (only with explicit follow permission; defaults OFF) and explicit exclusions (no block/marketing/batch). It stops short of naming which sibling to use for those excluded cases, but the intended usage context is unambiguous.

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

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

With no annotations, the description carries the full burden, and it does disclose two meaningful traits: results are limited to what is 'accessible' and 'platform privacy limits are respected', warning that the list may be partial. It does not state whether auth is required, whether paging has a max depth, or what happens on an invalid uid.

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 dense sentence with the negated-sibling clarification front-loaded and no filler. It is arguably over-compressed, since several clauses are packed into one line, but every clause carries information.

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

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

An output schema exists, so return shape need not be explained, and the description covers the two things an agent can't infer: uid typing/paging behavior and privacy-limited results. The unannotated mutation-adjacent risk is low since this is clearly a read tool, leaving only limit/auth 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%, so the description must compensate, and it partially does: 'String UIDs' clarifies the uid type (non-obvious given it is a string, not a number) and 'resumable pages' explains the cursor's role. The limit parameter and cursor's format/termination semantics are left undocumented.

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... following list') and explicitly negates the nearby write sibling ('not follow/unfollow'), which lets an agent separate it from bili_follow. It stops short of saying whose list is read (the uid param implies a target user) and whether it's the caller's own list by default.

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 exclusion 'not follow/unfollow' implicitly routes mutation intent to bili_follow, which is useful. But there is no positive guidance on when to choose this over bili_user_info or bili_social_events, and no prerequisite/auth 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?

With no annotations, the description carries the full burden and discloses important behavior: explicit permission requirement, default OFF, single-video scope, stable action_id, and no force/batch/retry. It stops short of describing side effects or reversibility, but the output schema can cover return values.

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 dense sentence with no filler, and it front-loads the action and permission constraint. Every clause adds a distinct behavioral rule.

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 output schema exists, so return values need not be explained, and the description covers key safety behavior around permission and batching. However, with no annotations and 0% schema coverage, an agent is still left guessing about bvid and action_id semantics.

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 three required parameters. The description hints at bvid ('one video'), enabled ('defaults OFF'), and action_id ('stable action_id'), but never defines bvid format, what enabled=false does behaviorally, or how action_id is generated and used for idempotency.

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 (like/unlike) and resource (one video), and explicitly rules out batch/force/retry variants. It does not name a sibling tool, but the scope is clear enough to distinguish it from broader mutating 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 states a meaningful precondition ('only with explicit like permission; defaults OFF'), which tells the agent when calling is permitted. However, it does not compare against sibling tools or explain when to use unlike versus like beyond the enabled flag.

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

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

With no annotations, the description must carry the full behavioral burden. It does convey that the operation is a read and is side-effect free ('no automatic reply'), and that it preserves reference IDs and quoted context for later follow-up, but it never explains the pagination contract for last_id/time_cursor or any auth/rate-limit behavior.

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

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

A single compact sentence with the verb front-loaded and no filler words. It borders on over-compression, 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?

An output schema exists, so return values need not be explained, and the read-only nature is implied. However, for a 4-parameter tool with zero schema coverage and no annotations, the description leaves meaningful gaps around cursor semantics and parameter options.

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 all four parameters, so the description must compensate. It partially does: 'native id/time cursor' maps to last_id and time_cursor, and 'reply/@' hints at kind, but num and the exact format/relationship of the two cursors remain 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 verb 'Read' and resource 'reply/@ notification page' are identifiable, so purpose is inferable. But the phrasing is compressed to the point of ambiguity ('native id/time cursor, keeping reference IDs and quoted context') and it never names itself against the closest siblings such as bili_dm_unread or bili_social_events.

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 routing signal is the exclusion 'no automatic reply', which tells the agent this tool does not send replies but not when to pick it over bili_social_events, bili_dm_unread, or bili_comments. No explicit when-to-use or prerequisite guidance is given.

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

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

No annotations are provided, so the description carries the burden; it does usefully disclose read-only scope ('Cannot change permissions') and that the hourly limit is a combined public one. It stops short of explaining whether gates are per-account, how the limit resets, or what forms the response takes for blocked vs allowed states.

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

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

Two tight sentences: the capability first, the constraint second. No filler, no restatement of the tool name, and the negative constraint is placed where it is most useful.

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?

An output schema exists, so return values need not be described here, and the description covers the full scope of what is read. A brief note on how the gates relate to the mutating siblings would make it complete for an agent deciding between them.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies a parameterless global read with no scoping arguments.

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

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

States a specific verb ('Read') and enumerates the exact resources: comment/reply/DM/like/favorite/follow gates plus the combined public hourly limit. This is far more specific than the sibling action tools (bili_like, bili_follow, bili_comment_send), though it doesn't explicitly name a sibling it replaces.

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?

'Cannot change permissions' implicitly frames this as an inspection/pre-flight tool rather than a mutation, which is useful. But it never says when to call it (e.g., before attempting bili_comment_send or bili_like) or what alternatives exist, leaving the agent to infer the use case.

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

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

With no annotations, the description carries the full burden. It does disclose two behavioral traits: results are a 'stable snapshot' (implying consistency across pages) and cursor-based pagination for full enumeration. It omits read-only status, auth requirements, and whether the snapshot expires or is stale relative to live data.

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

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

One short sentence with no padding, which is good, but the brevity comes at the cost of substance: 'platform-related' and 'complete items' are hedged phrasing that would need to be replaced rather than trimmed.

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?

An output schema exists so return values needn't be explained, but for a three-parameter tool with zero schema coverage, the entry parameter bvid and the limit are unexplained, and the notion of 'stable snapshot' is never grounded. The agent cannot tell what a call returns or how results relate to the input video.

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, but it only implicitly explains the 'cursor' parameter. The required 'bvid' (which video to find relations for) and the 'limit' cap are never mentioned, leaving two of three parameters undefined anywhere in the 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 names a verb and resource ('Read a stable snapshot of platform-related videos') but 'platform-related' is vague and never says what the videos are related to (presumably the bvid input). Siblings like bili_video_info and bili_discover are not differentiated, so an agent must infer that this returns videos related to a given video.

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

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

The only guidance is procedural ('use its cursor for further complete items'), which is pagination mechanics rather than when-to-use. There is no statement of when to choose this over bili_video_info, bili_discover, or bili_search.

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

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

No annotations are provided, so the description carries the full behavioral burden. "External data" vaguely suggests an external source, but the description does not disclose read-only behavior, rate limits, authentication requirements, pagination, result limits, or side effects. It adds little behavioral context beyond the basic purpose.

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 very short and front-loads the core action and resource. "External data." is a terse fragment that is less useful than the preceding sentence, but overall it avoids waste.

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

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

An output schema exists, so return values need not be fully documented. However, with no annotations and 0% schema description coverage, the description should explain the keyword/num/order parameters and basic behavior; it does not, leaving the definition incomplete 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% and there are three parameters, yet the description never mentions the required keyword parameter, the num default, or the order default. It lists returned fields instead of explaining parameter meaning, so it does not compensate for the schema's complete lack of parameter descriptions.

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: "Search real public videos," and lists the main returned fields (titles, BV IDs, UP authors, brief descriptions). It is clear what the tool does, but it does not distinguish itself from sibling tools such as bili_discover, bili_video_info, or bili_user_videos.

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 word "Search" implies usage for keyword-based video discovery, but the description gives no explicit when-to-use guidance, prerequisites, or alternatives. It does not explain when an agent should choose this over bili_discover, bili_browse_advance, or bili_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?

Despite having no annotations, the description discloses meaningful behavior: stable IDs deduplicate locally, only explicit ack marks events processed, recent_event_id is an association and not a Recent Events write, and there is no background polling or reply. It still omits read-versus-write safety and permission expectations, but the key operational semantics are unusually well covered.

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

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

The description is compact and free of filler, but it is too compressed for a five-parameter tool with no schema descriptions. The opening noun phrase does not front-load a clear action, making the overall structure less helpful than its brevity suggests.

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?

An output schema exists, so return-value details are less necessary, but the input side is significantly under-documented. With no annotations and 0% schema description coverage, the description should do more to explain pagination, source selection, and ack behavior for an agent to invoke the tool 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 explain all five parameters, but it only adds meaning for ack_event_ids ('explicit ack') and recent_event_id (association, not a write). It leaves num, cursor, and sources unexplained, including how sources relates to the default 'reply,at,dm'.

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 identifies the domain as pending notification/DM references and adds characteristics like 'bounded' and 'unified', but it never states a clear verb such as list, fetch, or check. It does not clearly distinguish the tool from siblings like bili_notifications, bili_dm_unread, or bili_dm_history.

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 guidance on when to use this tool versus the many notification and DM siblings. The only usage-adjacent statement is 'No background polling/reply', which is a behavioral constraint rather than a routing rule.

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

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

With no annotations, the description carries the burden and does disclose meaningful traits: whole-text return, exclusion of timestamps/frames/ASR, and the failure mode that missing subtitles stay missing rather than being synthesized. It omits auth/cookie requirements, which matter for Bilibili subtitle access, but the output schema covers return shape.

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

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

Three short sentences, front-loaded with what is returned, followed by exclusions and the failure caveat. No filler; every clause carries information.

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

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

For a one-parameter read tool with an output schema and no annotations, the description covers output scope, exclusions, and the missing-subtitle case. Only auth prerequisites and the exact meaning of "first-P" for multi-part videos remain unaddressed.

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

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

Schema coverage is 0% for the single bvid parameter and the description never mentions it, but "first-P" implicitly conveys that no part/page selector is needed — bvid alone targets the first part. That is real added meaning beyond the bare string property, though format expectations remain undocumented.

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 ... subtitle ... FULL text") and scopes it to the first part only. "No timestamps/frames/ASR" implicitly separates it from transcript or danmaku-style tools, but no sibling is named explicitly.

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

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

Usage is only implied: it reads existing subtitles and explicitly will not generate/transcribe them, so an agent knows not to expect ASR fallback. No alternative sibling (e.g. bili_video_info, bili_danmaku) is named for cases where subtitles 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?

With no annotations, the description must carry behavioral disclosure. It indicates read-only behavior ("No posting/following") and notes the cursor is a native string, but it omits permissions, rate limits, and pagination behavior, leaving meaningful gaps for a tool with no annotation coverage.

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

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

The description is two short, front-loaded sentences with no filler. It is efficient, though its terseness contributes to gaps in parameter and usage explanation.

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?

An output schema exists, so return values need not be described. However, for a tool with three undocumented parameters and no annotations, the description omits what uid and num control and does not clarify the difference from sibling user-content tools, leaving an agent under-informed.

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 all three parameters lack structured documentation. The description only adds meaning for the cursor ("native string cursor"), while the required uid and optional num remain unexplained, which is insufficient compensation.

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

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

The description states a specific verb and resource ("Read public user dynamics") and distinguishes itself from sibling write actions with "No posting/following." It is somewhat ambiguous about what "dynamics" means versus bili_user_videos or bili_user_info, but the core purpose is clear.

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

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

The phrase "No posting/following" provides a negative exclusion, implying this is for reading rather than writing. However, it does not explicitly say when to use this tool over siblings like bili_user_videos or bili_user_info, leaving usage selection largely inferred.

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

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

With no annotations, the description carries the full burden; 'Read' and 'public profile' do establish that this is a non-mutating access to public data. However, the trailing sentence 'Agent identity remains unverified' is cryptic and gives no actionable context about auth, rate limits, or what happens on an invalid/private UID.

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

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

Compact and front-loaded: the purpose leads, followed by the parameter disambiguation. The final clause about agent identity is short but of dubious value, slightly diluting an otherwise tight 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?

An output schema exists, so return values need not be explained, and a single-parameter read-only tool needs little. Still, an agent is left without the source of the UID and without any note on behavior for private or nonexistent users, which the annotation-free definition should supply.

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

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

Schema coverage is 0% and the single 'uid' parameter has no description, so the description must compensate. It does add real meaning by stating the value is a UID string and explicitly distinguishing it from a comment rpid, but it never says where to obtain the UID (e.g., from bili_comments).

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

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

Specific verb plus resource: 'Read a commenter's public profile/signature'. That separates it from the uid-taking siblings bili_user_videos and bili_user_dynamics, which return content rather than profile data. It stops short of naming those siblings directly, so it is clear but not fully differentiated.

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

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

'Read a commenter's public profile' implies the trigger (you have a commenter's UID and want their profile), but there is no explicit when-to-use, when-not, or named alternative. The only real guidance is the warning not to pass a comment rpid, which is a parameter-usage rule rather than tool-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?

With no annotations, the description carries the burden alone; it does disclose meaningful traits: read-only framing ('Read'), public-uploads-only scope, single-page pagination, and BV ID preservation so results can be chained into bili_video_info. It says nothing about whether keyword filters within the user's uploads, what happens on an invalid UID, 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?

Two short, front-loaded sentences with no filler; every clause carries information. It reads as telegraphic fragments rather than prose, which costs a little readability but not substance.

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?

An output schema exists, so return values need not be explained, but for a 5-parameter tool with zero schema coverage and no annotations the description is too thin — the semantics of keyword and the page/num interaction are exactly what an agent needs and does not get.

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 there are 5 parameters. The description usefully supplies the order values (pubdate/view/favorite) that the schema lacks as an enum, and clarifies uid must be exact, but num, page, and especially keyword (does it filter this user's uploads or search globally?) remain undefined 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?

States a specific verb and resource ('Read one page of public uploads by exact UID'), which clearly separates it from bili_search (keyword discovery) and bili_video_info (single video). The scope qualifiers 'public' and 'exact UID' further sharpen it, though it never names a sibling it replaces.

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 prefer this over bili_user_dynamics, bili_search, or bili_favorite_content, and no note that the exact UID must first be obtained (e.g. via bili_user_info). 'Read one page' hints at pagination but is not usage guidance.

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

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

No annotations are provided, so the description carries the full burden. 'Read' plus the explicit scope exclusion ('no video frames') does establish this as a non-mutating metadata fetch, but it says nothing about auth requirements, rate limits, or failure behavior for invalid bvids.

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

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

A single compact sentence with the returned fields front-loaded and the scope exclusion last. Every clause carries information; nothing is redundant.

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

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

An output schema exists, so return-value explanation is not required, and the scope statement covers what the tool returns. However, with no annotations and no parameter documentation, the identifier format and any access requirements remain unstated for a tool that is otherwise simple.

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 there is one required parameter, 'bvid', which the description never mentions. An agent gets no hint that it is a Bilibili BV identifier or what format is expected (e.g. 'BV' prefix), so the description fails to compensate for the schema gap.

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

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

Names a specific verb ('Read') and enumerates exactly which fields are returned: description, author, statistics, number of parts. The closing clause 'no video frames' scopes it away from playback tools like bili_watch_video, though that sibling is never named explicitly.

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

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

Usage is only implied: the 'no video frames' exclusion hints that frame/playback retrieval lives elsewhere, but the description never states when to pick this over bili_watch_video, bili_browse_advance, or bili_related, nor does it state any 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?

With no annotations, the description carries the full burden and does disclose that reading is free and does not initiate a model call, which is important behavioral context. It also lists the status information returned, but it does not explain authentication needs, whether the job expires, or what happens if the job_id is unknown.

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

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

The description is two concise sentences with the core purpose front-loaded. The second sentence adds useful behavioral context without padding, though the first sentence's dense list of status aspects is slightly hard to parse.

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

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

An output schema exists, so return values need not be described, and the description adequately conveys the tool's read-only status-checking role. However, for a tool with zero annotation coverage and an undocumented required job_id parameter, it should do more to explain the parameter's origin and the job lifecycle.

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 the single parameter, job_id. It does not state where the job ID comes from (presumably bili_watch_video), what format it has, or whether it can refer to both pending and completed jobs.

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

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

The description uses a clear verb ('Read') and names the resource and returned aspects: a pending video perception job or completed material, coverage, limitations, real usage, and cleanup status. It distinguishes this status-checking tool from the sibling action tool bili_watch_video, though it does not explicitly name that 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 phrase 'Read a pending ... job' implies this is used after a job has been created, and 'Reading is free and does not initiate a model call' gives useful context for choosing it over a model-triggering sibling. However, it does not explicitly say when not to use it or name the alternative that starts a perception job.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the job is asynchronous (poll bili_watch_status), that results report actual source coverage and gaps rather than overclaiming, and it enumerates hard limits (64MiB, 1 concurrent job, 3 API attempts/day, no Agent/schedule created). It does not describe failure modes or partial-failure behavior beyond the coverage caveat.

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?

Front-loaded with the core operation and the range constraint, followed by the async/limits facts. Nearly every sentence carries information; the closing 'Decide your interests and notes' is the one sentence that does little work.

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 async job tool with no annotations, the description covers the essential unstated behaviors: async polling, honest coverage reporting, quotas, and no scheduling side effect. Return-value detail is legitimately omitted because an output schema exists; the remaining gap is parameter-level meaning for bvid/part/question.

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 compensate. It adequately explains start_seconds/end_seconds (explicit, continuous, max 180s, only needed for long parts) but says nothing about bvid, part (default 1), or the ambiguous 'question' parameter; 'Decide your interests and notes' is too vague to resolve what 'question' does.

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 (perceive) plus resource (a complete short Bilibili part or an explicit start/end range of a long part) and specifies audio+video capture. That distinguishes it from metadata siblings like bili_video_info and bili_subtitle. 'Perceive' is non-standard phrasing, but the scope 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?

It tells the agent to poll bili_watch_status after calling and states the 180s range cap, which is real operational guidance. It never says when to prefer this over sibling tools such as bili_video_info or bili_subtitle, leaving the choice 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?

With no annotations, the description carries the full behavioral burden, and it does disclose one genuinely useful trait: secrets are never echoed back, which reassures an agent this call is safe to inspect. It omits what happens on an unauthenticated/expired session (error vs. empty result) and whether the call hits the network or reads cached state, which matters for a status-check tool.

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

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

A single compact sentence with the security guarantee front-loaded after the purpose clause; nothing is redundant. It is arguably over-compressed for a tool whose identity semantics (who vs. which user id) drive selection.

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 no-argument read with an output schema is a simple contract, and the return shape is already documented, so this is close to complete. The remaining gap is the authentication edge case and the boundary against bili_user_info, both of which an agent needs before choosing this tool.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter discussion is needed or expected.

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 says it checks 'saved Bilibili account status', which implies verifying the stored/authenticated session rather than fetching an arbitrary user's profile. But it never states the core outcome (confirming which account is currently logged in), and with a sibling named bili_user_info in the same namespace, an agent cannot confidently tell the two apart from the text alone.

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

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

There is no guidance on when to call this versus bili_user_info, bili_account_action_status, or bili_permissions. The 'never return Cookie/token values' clause is a safety note, not a usage condition, so the agent must infer the call context entirely.

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