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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower; the description still adds real value by explaining that online=true triggers an actual browser connection and by stating that login credentials are never returned, a genuine security-relevant disclosure. It omits whether the browser check can be slow, fail, or require an open session.

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

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

Two compact clauses, the local-first behavior front-loaded, the opt-in browser branch second, and the credential caveat last. No filler, no restatement of the tool name.

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

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

There is no output schema and the description only says what is NOT returned (credentials) rather than what is returned, so an agent cannot anticipate the shape of the status result. For a status-check tool whose entire purpose is producing that result, this is a noticeable gap, though the call semantics themselves are fully covered.

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 carries the parameter burden. It explains the online=true path but leaves the default/false path ('本地偏好' only) implicit, and gives no hint about what the local preference check reads or where it comes from. Useful but only half the semantics of the single flag.

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

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

The description pairs a concrete action (checking local preferences, then verifying the live account against the browser) with the auth-status subject implied by the tool name, and it is clearly unlike any of the content-oriented siblings. It stops short of stating outright that it returns a logged-in/not-logged-in result, so the resource is inferred rather than named.

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 conditional 'online=true 时连接浏览器验证实际账号' tells the agent exactly when to pay the cost of a live browser check versus staying local, which is the only real branching decision for this tool. There are no competing auth siblings to route to, so the absence of an explicit alternative is minor.

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

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

The annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so '不会重复执行写入' largely restates what structured data provides. What the description does add is the open-world detail that action_id triggers a re-read of the live Bilibili state rather than local cache, which is genuinely useful context not encoded in the annotations.

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

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

Two short clauses, front-loaded with the listing behavior and then the action_id mode, plus one reassurance clause. No filler or repetition.

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

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

For a read-only two-parameter query with full annotation coverage and no output schema, the description covers both operational modes and the safety profile adequately. Minor gaps remain around receipt retention and whether action_id results still appear when the underlying save failed.

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

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

Schema description coverage is 0%, but the description clarifies action_id's semantics — it looks up the actual remote status of a prior save action rather than just a local receipt — which the bare uuid pattern does not convey. The limit parameter (default 20, max 100) is still undocumented as to what it bounds (number of receipts), so the compensation is partial but meaningful.

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 action and resource: querying recent save receipts, with an optional action_id mode to re-read the actual Bilibili state. This clearly distinguishes it from the sibling write tool bilibili_save_videos, though it never explicitly names that sibling or state the relationship.

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 '传 action_id 可回读' implies the two usage modes (list recent receipts vs. check one action's real status), and the closing clause '不会重复执行写入' hints it is the safe verification step after a save. But it never states explicitly when to prefer this over simply re-calling bilibili_save_videos or how soon after a save it should be used.

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

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

The annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered structurally. The description's additional value is the precedence rule (URL p kept unless part is given), which is real behavioral detail; it does not mention what happens on an invalid or unreachable video identifier, so it stops short of rich transparency.

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

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

Two compact sentences with no filler, and the override/precedence information comes immediately after the resource statement. It is well front-loaded, though the second clause is terse enough that its referent (which p, which URL) needs a second read.

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

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

There is no output schema, but the description names what comes back (metadata and分 P), and annotations carry the safety and idempotency profile, so the description is close to sufficient for a 2-parameter read tool. The remaining hole is the format of the required video argument, which an agent must guess.

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

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

Schema description coverage is 0%, so the description is the only source of parameter meaning – and it only partially compensates. It explains part as an explicit override of the URL's p value, but leaves video completely uncharacterized: nothing says whether it is a full URL, a BV id, or something else, despite a 2048-character cap that hints at URLs.

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

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

A specific verb (读取, "read") plus a specific resource (视频元数据与分 P, "video metadata and parts"), so the agent knows the payload involves both metadata and per-part data. However, the very similar sibling bilibili_read_video is never mentioned, so the boundary between the two read tools has to be inferred rather than read off the description.

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

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

The clause about the URL's p being preserved and part explicitly overriding it implies when to set part, which is genuinely useful usage context. Beyond that there is no stated when-to-use or when-not-to-use guidance, and nothing routes the agent between this tool and bilibili_read_video or bilibili_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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds that results are scoped to the current logged-in account and that IDs are exact/usable downstream, which is genuine context, but it says nothing about authentication failure behavior or whether followed/collected folders are excluded.

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

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

A single compact sentence with the resource and the account scope front-loaded and the downstream purpose trailing. No filler, no restatement of the tool name.

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

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

With no output schema, the description does its part by stating that precise folder IDs are returned, which is the key return-value fact an agent needs. For a zero-parameter read tool with full annotation coverage this is nearly complete; only the logged-out/empty-list edge cases are 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?

The tool takes zero parameters, so the schema carries no semantic burden and the baseline is 4; however, the description also adds no parameter-level information because none exists. It sits just below the zero-parameter baseline because it neither confirms the absence of filters nor explains that no pagination or filtering options are available.

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

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

The description names a specific verb and resource ('列出...收藏夹') and narrows the scope to folders created by the currently logged-in account, which separates it from the saving siblings. It does not explicitly name bilibili_save_videos as its counterpart, so differentiation is implied through the stated downstream use rather than spelled out.

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?

'提供精确 ID，供保存工具使用' establishes the workflow context: call this before a save operation to obtain the folder identifier. That is clear when-to-use guidance, but there are no explicit exclusions or notes about what to do when the list is empty or the account is not authenticated.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior, yet the description still adds real context: output carries a coverage range and a truncation cursor, subtitle type (human vs AI) is surfaced, and missing subtitles produce an explicit error. Missing is any statement about auth or rate limits, though openWorldHint signals external dependence.

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?

Four short clauses, each carrying distinct information: scope, subtitle typing, return shape, error behavior, and exclusion of ASR. The most important constraint (one part, subtitles) comes first with no filler.

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

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

Return behavior and error behavior are explained even though there is no output schema, which is good. But with five parameters at zero schema coverage, an agent cannot tell what 'video' accepts or how start_seconds/end_seconds interact with the returned coverage range, so the definition is not complete enough 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% across 5 parameters, and the description documents none of them. '分P' hints at part and '截断游标' hints at limit, but video format, start_seconds/end_seconds ranges, and the 200/500 limits are left entirely unstated — the largest gap in this 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 states a specific verb and resource: it reads the timestamped subtitles of one part (分P) and distinguishes human from platform-AI subtitles. That is precise enough to separate it from bilibili_get_video, but no sibling is named, so the differentiation is only implied by scope.

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

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

The negative scope sentence '本版不提供 ASR' tells the agent what this tool will not do, which is useful routing information. However, it never says when to call this instead of bilibili_get_video or how to react to a no-subtitle error beyond 'it errors clearly'.

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

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

Annotations already cover read-only, idempotent, open-world and non-destructive semantics. The description adds real value beyond them: it discloses the side effect of opening the target video page in a browser, the default sampling positions (10%/50%/90%), the 6-frame ceiling, and the epistemic limit of the result.

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?

Four short sentences, front-loaded with the return value and defaults. Every sentence carries information; the "not frame-by-frame" caveat earns its place by preventing overclaiming, though the phrasing is slightly repetitive with the default-sampling 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?

No output schema exists, but the description does state what comes back (screenshots and real timestamps). For a browser-driving, open-world tool it omits prerequisites such as authentication (a sibling auth-status tool exists) and expected latency, and leaves two parameters undocumented.

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 the `times` parameter well (defaults and max 6 frames), but leaves `video` (URL vs BV/av id) and `part` (multi-part index) undefined in both schema and description.

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

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

States a concrete verb+resource pair: sampling frames from the Bilibili player and returning screenshots plus actual timestamps. This is clearly distinct from sibling tools like bilibili_read_video, though it never names an alternative explicitly, so it stops short of a 5.

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

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

Usage is implied (visual verification of a video) but there is no explicit "use this when / use X instead" guidance against bilibili_read_video or bilibili_get_video. The caveat that sampling is not equivalent to watching the whole video is a useful interpretation constraint but is not routing guidance.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=true, but the description adds meaningful behavior beyond that: it deduplicates before adding, reads back to verify, deletes nothing, and treats unconfirmed old tasks as verify-only. It does not describe rate limits or what the verification read-back returns, which keeps it below a 5.

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

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

Four short clauses, front-loaded with the primary action, then the default target, then the safety sequence (dedupe, add, verify, no deletion), then the preview and retry qualifiers. Every sentence adds information with no repetition.

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

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

For a 4-parameter mutation tool with no output schema, the definition covers the mutation semantics, the safety guarantees, and the dry-run mode. Gaps remain around what a successful save returns and how target/folder selection interacts with the configured default, which an agent would need.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it largely does: preview=true is explained as check-only, the default configured target explains why targets is optional, and the 'don't blindly resend' clause maps to retry_unconfirmed. It never explains the videos array limits or the watch_later/favorite target kinds explicitly, leaving some schema detail unstated.

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

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

The description names a concrete verb (add to watch-later / favorites) and the resource (videos), and scopes it to 'final recommendation or explicitly user-requested' items. It does not explicitly name a sibling to contrast with, even though bilibili_get_save_receipt and bilibili_list_favorite_folders sit adjacent to it, so it falls one step short of full differentiation.

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

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

The usage context is clear: use it for final recommendations or explicit user requests, use preview=true to only check, and for unconfirmed legacy tasks default to verification rather than resending. What's missing is a pointer to the sibling tools (e.g. get_save_receipt for reading back receipts, list_favorite_folders for folder IDs), so the agent must infer alternatives.

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

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

Annotations already declare readOnly=true, idempotent=true, openWorld=true, so the safety profile is covered. The description adds genuinely new behavior beyond that: the result carries title/uploader/duration/link and nothing is persisted, which resolves the main ambiguity of a search tool against a save workflow. It says nothing about pagination behavior or result volume, hence not a 5.

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

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

Two sentences, zero waste, with the returned fields and the non-persistence caveat front-loaded. Nothing is redundant with the name or the annotations.

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

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

Return fields are described, which is necessary given there is no output schema, and the non-persistence note closes the biggest workflow gap. However, with three parameters at 0% schema coverage, an agent still has no guidance on paging through results or caps, so the definition is adequate but incomplete for a paginated search tool.

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

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

Schema description coverage is 0%, so the description has to carry parameter meaning, and it explains nothing about page or limit — the bounds (page ≤ 50, limit ≤ 20) exist only as bare constraints with no stated semantics. Only 'keyword' is implied by the word 搜索, leaving two of three parameters undocumented on both sides.

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

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

The description gives a specific verb+resource (搜索 B 站视频) and enumerates what comes back (标题、UP 主、时长、链接). It does not name a sibling, though the clause '搜索候选不会自动保存' implicitly points at the save workflow; the tool is still distinguishable from bilibili_save_videos and bilibili_read_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 statement that search candidates are not auto-saved implies an agent must call bilibili_save_videos to persist anything, but that alternative is never named and no conditions for choosing this over bilibili_get_video are given. Usage is inferable rather than stated.

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