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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real context beyond that: the cookie/auth requirement, the conditional favorites behavior, and the default "videos only" scope for feed. It stops short of describing pagination semantics or result volume.

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

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

A single dense sentence front-loads the verb, resource, and auth prerequisite, then enumerates modes with semicolons — zero filler. It is somewhat packed, but every clause carries a distinct fact.

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 six parameters, no output schema, and a multi-mode dispatch, the description covers the mode semantics and the auth prerequisite well. Return shape and pagination behavior are left implicit, though cursor/next is documented in the schema, which is a reasonable division of labor.

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 67%, and the description compensates by defining every `what` value and the folder_id presence/absence branch, which the schema only labels as "收藏夹 ID". It says nothing about page or cursor beyond what the schema already documents.

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 ("读取已登录账号的数据") and then enumerates all five values of the `what` enum with their meanings (me/watch_later/favorites/history/feed). An agent can distinguish this from bili_user (other users) and bili_watch_later_edit (mutation) 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?

It gives a clear prerequisite (BILIBILI_COOKIE must be configured) and spells out the branch condition for favorites: without folder_id it lists folders, with folder_id it lists contents. It does not explicitly name alternatives such as bili_user or bili_watch_later_edit or state when not to use this tool, so it falls short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuine context about what is produced (ffmetadata / OGM chapter markup), but says nothing about behavior when a video has no chapters, whether pagination/season handling differs, or access limits — gaps that matter for an agent reasoning about failure modes.

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

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

Two compact sentences; the core purpose and the available outputs come first, with the Bilibili-Evolved mapping as trailing context. Nothing is redundant, though the parenthetical about OP/ED could be folded more tightly.

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 carries the burden of describing return shape, and it never says what the default `list` output looks like (field names, time units, whether entries include titles). For a read-only 3-parameter tool the remaining gaps are moderate rather than severe, but an agent cannot predict what it will receive.

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 67%, and the description usefully compensates for the one undocumented piece: the `format` enum has no schema description, but the text explains that list is chapters data while ffmetadata and ogm are chapter-file encodings for ffmpeg or OGM tooling. The `page` and `input` parameters are already documented in the schema, so no repetition is needed.

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

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

States a specific verb and resource (获取视频的分段章节) and clarifies what chapters are in this domain (UP主设置的看点 / 番剧 OP、ED 时间), which rules out confusion with bili_danmaku or bili_subtitles. It also names the Bilibili-Evolved feature it mirrors. It stops short of naming any sibling tool 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 implied rather than stated: the mention of ffmetadata for ffmpeg chapter writing hints at when a caller would pick a non-default format. There is no explicit 'use this when…' or 'do not use this for…' guidance, and no pointer to bili_video_info or bili_danmaku as 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 readOnlyHint=true and openWorldHint=true, and the description adds genuinely useful behavior: which fields come back (pinned comment, like counts, IP location, hot sub-replies) and that pagination is offset-based. It does not mention rate limits or whether deep pagination is capped, which keeps it below 5.

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

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

Three short sentences, front-loaded with the resource and the payload, then pagination, then provenance. The Bilibili-Evolved reference is the weakest sentence but does give implementation context; nothing else is padding.

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

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

With no output schema, the description carries the burden of describing return values, and it only sketches them rather than naming the cursor field precisely. It says '用 next_offset 翻页' while the schema's parameter is 'offset' and the cursor field is described there as 'nextOffset', an inconsistency that could make an agent guess at the pagination token's name.

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

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

Schema coverage is 50%; 'sort' and 'limit' have no schema descriptions at all. The description partially compensates by naming the two sort modes (热门/最新) and explaining that the offset parameter is fed from the previous response's cursor, but it never mentions the limit ceiling of 20 or the accepted input identifier formats.

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

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

States a specific verb+resource (获取视频评论) and narrows scope with the sort modes (热门或最新) plus the data returned (置顶评论、点赞数、IP 属地、楼中楼). It is clearly distinguishable from most siblings, though it never explicitly separates itself from bili_danmaku, which an agent could plausibly confuse with 'comments'.

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

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

Usage is only implied: an agent infers 'call this to read a video's comment section.' There is no statement of when not to use it, no prerequisite about needing a resolved video ID, and no pointer to bili_danmaku as the alternative for bullet comments.

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

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

The description adds real behavior beyond the annotations: stats aggregates (总数、高频弹幕、密度、高能时间点), uniform sampling in lines mode when the volume is too large, and that the file modes write a file and return its path. One tension: readOnlyHint=true while the tool writes files to disk, though the description at least discloses that side effect rather than hiding it.

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 mode enumeration is front-loaded and each clause maps to one mode's output, so the density is functional rather than padding. It is a single long sentence chain, however, without separators, which slightly hurts scanability.

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

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

With no output schema and 7 parameters, the description compensates by describing the return shape for every mode, including the file-path return for ass/xml/json. An agent can call this correctly and know what to expect from each mode without further information.

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 86%, so parameters like input, page, from_seconds/to_seconds, limit and block_keywords are already documented in the schema. The description only adds the sampling behavior tied to limit, which is minor value on top of an already well-documented schema — the baseline 3.

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

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

States a specific verb and resource (获取视频全部弹幕) and then enumerates the five modes with what each returns, so the agent knows exactly what the tool produces. It does not differentiate itself from nearby siblings such as bili_comments or bili_subtitles, which is the only reason it falls short of a 5.

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

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

Each mode carries an implicit use case (stats '适合分析观众反应', lines for timestamped text with time-range filtering, ass/xml/json for file export playable in a player), giving clear selection context. There is no explicit 'when not to use this' or pointer to an alternative tool for comment/subtitle retrieval.

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

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

Beyond the annotations it discloses the concrete output location (~/Downloads/bilibili, overridable via BILIBILI_DOWNLOAD_DIR), the ffmpeg merge-and-chapter-metadata behavior, and the graceful fallback to separate files when ffmpeg is absent — none of which the annotations convey. It still leaves out whether files are overwritten on re-download, whether login/cookies are required, and any rate-limit behavior for batch pages.

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 leads with the action and destination, then layers merge behavior, extras, and the async/status flow in a logical order with no filler. It is dense but each clause (directory override, ffmpeg fallback, task ID handoff) carries actionable information; only the closing Bilibili-Evolved naming is low-value padding.

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

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

For an 8-parameter tool with no output schema, it covers the essentials an agent needs: where files land, how merging behaves, and how the async return is used. It doesn't describe the shape of the immediate response (e.g., task ID field name, progress fields) which matters when wait_seconds is 0, leaving a small gap before the bili_download_status handoff.

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

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

Schema description coverage is 100%, so every parameter including mode, codec, pages and wait_seconds already carries its own explanation; the description adds no parameter-level detail beyond restating the ffmpeg merge and the wait_seconds timeout behavior. That meets the baseline for a fully documented schema but doesn't improve on it.

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

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

The first sentence states a specific verb (下载到本机) plus resource and destination, and the tool's scope is further sharpened by naming which artifacts it can fetch (视频/音频/封面/弹幕/字幕). It is clearly distinguishable from siblings like bili_danmaku or bili_subtitles because it frames them as optional extras of a single download job, and from bili_download_status because it names that tool as the follow-up.

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 explicitly says the task runs in the background, that exceeding wait_seconds returns a task ID, and that bili_download_status is the way to check afterwards — a clear usage path. What's missing is routing guidance versus the dedicated siblings (bili_danmaku, bili_subtitles, bili_chapters) when the user only wants danmaku/subtitles, and any note on prerequisites such as login for high qualities.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds the session-scoping behavior of the listing mode, but omits polling semantics, terminal/failure states, and how long results persist — all relevant for an async download status 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, front-loaded with the core purpose and followed by the mode-switching behavior. 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?

No output schema exists, and the description does name what's returned (progress plus result file path), which is the most important thing. But it doesn't cover failure states, job expiration, or the polling/waiting pattern an agent needs for a 0-90s wait parameter, leaving meaningful gaps for an async task 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 50%: wait_seconds is documented in the schema itself, but job_id has no schema description. The description partially compensates by explaining that omitting job_id lists all session tasks, which is the key semantic for that parameter. Baseline 3 fits given the schema already carries the wait_seconds documentation.

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

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

States a specific verb+resource: querying download task progress and the resulting file path. It's clearly distinct from bili_download (which starts a download), though the differentiation is implied rather than stated 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?

The description explains one usage mode: omitting job_id lists all tasks in the current session, which is real guidance for choosing between the two call shapes. However, it doesn't say when to use this rather than bili_download, or when to poll vs. use wait_seconds — that's left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and openness profile is covered. The description adds nothing further about behavior — no indication of what the results look like, pagination semantics, or mode-specific restrictions — but it does not contradict the annotations either.

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 mode list is compact, parallel, and dense with meaning, using one clause per enum value. The trailing sentence about Bilibili-Evolved entry points adds little for an agent, and the payload is not front-loaded with a purpose statement, keeping it slightly below top marks.

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-parameter, no-output-schema, multi-mode tool, the description covers the mode selector but says nothing about pagination or result shape for each mode, and the two numeric parameters remain undocumented anywhere. Adequate to invoke, not complete enough to know what to expect back.

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

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

Schema coverage is only 25% (only `region` has a description), so the description has to carry weight — and it does, defining all four `kind` enum values with their real-world meaning and flagging that `region` applies to ranking only. It leaves `page` and `limit` unexplained beyond their numeric bounds, which is the remaining gap.

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

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

The description enumerates the four concrete retrieval modes of the tool (hot search words, popular videos, per-region rankings, weekly must-watch), so an agent can tell this is a Bilibili trending/ranking fetch tool. It never states the operation in a single upfront verb+resource sentence and does not differentiate itself from siblings like bili_search, which keeps it out of the top band.

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 implicitly says which `kind` value to pick by glossing each one, and notes that region only applies to ranking. But there is no explicit when-to-use statement, no exclusion of alternatives (e.g. use bili_search for keyword lookup instead), and no note on what happens for modes that ignore page/limit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and network-openness are covered. The description adds value by naming the data returned (title, live status, popularity, partition, start time), which substitutes for the missing output schema, but says nothing about failure modes for nonexistent or offline rooms.

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

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

A single short sentence with the verb front-loaded and no filler. It is terse but every word carries information; only slightly clipped for a description serving as the sole summary of a tool.

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

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

For a one-parameter read-only lookup, the description plus annotations plus the fully documented schema cover what an agent needs. The enumerated return fields compensate for the absence of an output schema; only error/edge-case behavior is left 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?

Schema coverage is 100% and the single parameter already documents that it accepts a room ID or a live.bilibili.com URL. The description adds nothing about the parameter, so the baseline 3 applies.

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

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

States a specific verb (查询) and resource (直播间) plus an enumeration of the fields returned (标题, 开播状态, 人气, 分区, 开播时间). No sibling covers live rooms, so the tool is distinguishable by name alone, though the description never explicitly contrasts it with bili_video_info or bili_user.

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

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

There is no when-to-use guidance, no mention of when to prefer bili_video_info or bili_user instead, and no note that it works for offline rooms. Usage is only implied by the field list, similar to the calibration case that scored 2.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so safety and network scope are covered by structured data. The description adds that b23.tv short links are resolved (implying a network hop) and that av⇄BV both directions are supported, but says nothing about failure behavior for unparseable input or about the shape of the resolved 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?

The capability statement is front-loaded and the second clause lists output ID types compactly. The trailing mapping to Bilibili-Evolved features is provenance rather than actionable instruction and could be trimmed, but overall there is little 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?

There is no output schema, and the description helpfully compensates by naming the ID types that come back, which is what an agent needs to chain into bili_video_info or bili_live_room. What remains unstated is the concrete return shape (field names, single vs. multi-match) and permission/rate considerations.

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

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

With a single parameter at 100% schema description coverage, the schema already carries the burden and baseline 3 applies. The description's enumeration of ID families slightly extends the schema by signaling the range of accepted formats, but it adds no syntax or validation detail beyond the schema's own examples.

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 ("解析...链接或编号成结构化 ID") and enumerates exactly which ID families are produced (aid/bvid, ep/ss, mid, room, cv), plus the extra capability of av⇄BV conversion. An agent can tell immediately that this is the URL/ID normalization entry point rather than a content-fetching 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?

Accepted inputs are exemplified and short-link support is mentioned, so usage is implied, but nothing says when to pick this over siblings like bili_video_info or bili_user (which presumably expect a raw ID). There is no explicit "call this first to normalize a link, then pass the result to X" guidance or any exclusion.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered, but the description adds nothing behavioral beyond that: no mention of pagination behavior, result caps, rate limits, or what a search returns. The second sentence is provenance trivia (parity with the browser extension UI) rather than operational context.

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

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

Two short sentences with the capability stated first, no filler or repetition. The provenance sentence about Bilibili-Evolved is of marginal value to an agent, keeping it just below a 5.

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, open-world search with four parameters and no output schema, the description covers what can be searched but omits result shape, pagination limits, and sort interaction with `type`. An agent could invoke it, but would likely need a probe call to learn how results come back.

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

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

Schema coverage is only 50% — `type` and `order` are documented in the schema, while `keyword` and especially `page` are not. The description's type enumeration largely restates the existing enum description and says nothing about pagination or sort semantics, so it fails to compensate for the undocumented half.

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 (搜索) plus the exact resource domains (视频、用户、番剧、影视、直播间、专栏), which matches the `type` enum and makes the tool's scope unmistakable. It does not explicitly contrast itself with lookups like bili_user or bili_video_info, so sibling differentiation is left implicit.

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

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

The mapping to Bilibili-Evolved's 搜索栏 / Launch Bar implies this is the keyword-entry search entry point, which hints at when to reach for it. However, there is no explicit when-to-use/when-not guidance and no pointer to alternatives such as bili_hot for trending or bili_resolve for ID/URL resolution.

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

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds genuinely new behavioral context: AI subtitles typically require a login Cookie, and omitting lang switches the tool into a listing mode rather than a fetch mode. It does not cover error behavior or rate limits, so not a 5.

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

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

One dense paragraph, front-loaded with the core action and followed by format guidance, the lang-omission rule, and the cookie caveat in priority order. Slightly packed, but no sentence is 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?

With no output schema, the description correctly compensates by describing the text return format, and it flags the auth prerequisite for AI subtitles. Page/multi-P selection and save behavior are left to the schema, which covers them adequately.

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 83%, so the baseline is 3, but the description adds meaning the schema lacks: the concrete output shape of format=text ('[mm:ss] 台词') and the semantic effect of omitting lang. This is real value beyond the enum and per-param 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?

States a specific verb and resource (获取视频字幕, including AI-generated) and immediately clarifies the return shapes for each format. An agent can distinguish it from siblings like bili_danmaku, bili_chapters, or bili_video_info 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?

Gives actionable selection guidance: format=text is recommended for AI summarization/translation, while srt/ass/json should be saved as files. It also explains the special 'input only, no lang' case that enumerates available languages. No explicit sibling exclusion is offered, 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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds the payload shape (which profile fields come back, plus the optional recent-submission block), but says nothing about failure behavior for unknown users, auth requirements, or rate limits.

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

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

A single compact sentence with the field list front-loaded after the colon and the optional recent-submissions capability appended last. Every clause carries information; there is no boilerplate.

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 correctly compensates by enumerating the returned profile fields and noting the optional recent-video attachment. For a 2-parameter read tool this is nearly sufficient; only edge-case behavior for invalid or unresolvable input is omitted.

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

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

Schema coverage is 100%, so both parameters are already fully documented with the same example forms (UID, space.bilibili.com link, video link/BV号). The description restates rather than adds, so baseline 3 is correct.

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

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

States a specific verb (获取) and resource (用户资料) and enumerates the returned fields (昵称、签名、等级、粉丝数、获赞、认证), so the agent knows exactly what it gets. It does not explicitly contrast with the overlapping sibling bili_resolve, which also accepts links, so differentiation is only partial.

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

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

The description explains the accepted input forms, including the useful routing rule that a video link yields its UP 主, which is implicit guidance on when this tool applies. However, it never says when NOT to use it or name bili_resolve/bili_video_info as the alternative path for link resolution.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe, network-fetching read. The description adds useful context about what data is returned (including paginated part lists for videos and episode lists plus rating for bangumi links), but it does not cover error behavior for invalid IDs or rate limits. Given that annotations already cover the safety profile, a 3 is appropriate.

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

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

The description is essentially one dense sentence listing return fields, followed by a short mapping to Bilibili-Evolved features. The return-value information is front-loaded, and the description is generally efficient, though the feature-mapping clause is marginal.

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?

Since there is no output schema, the description must enumerate what comes back, and it does so thoroughly: video metadata, statistics, tags, part lists, collection info, and bangumi episode lists plus scores. For a one-parameter read tool this covers the essentials; only failure modes and pagination behavior are missing.

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

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

Schema coverage is 100%: the single `input` parameter is already documented as accepting BV号, av号, ep号, ss号, b23.tv short links, and full URLs. The description repeats the concept of video/bangumi links but adds no syntax or format details beyond what the schema provides. Baseline 3 is correct.

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 (获取视频/番剧详情) and enumerates the returned fields (标题、简介、封面、UP主、播放量、分P、合集、番剧评分), so the purpose is unambiguous. It does not differentiate itself from the sibling bili_resolve, which likely handles the same link/ID inputs, 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 implies the intended use case: retrieving details for a video or bangumi link. However, it gives no explicit guidance on when to use this tool instead of bili_resolve (for the same identifier types) or bili_video_streams, bili_danmaku, or bili_subtitles (for fetching other aspects). The agent must infer the choice.

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

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

Beyond the readOnlyHint annotation, it discloses two operationally critical facts: the direct URLs require a `Referer: https://www.bilibili.com/` header and expire in about 2 hours. Both would silently break an agent's downstream download if omitted.

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, front-loaded with what is returned, then the download caveat and the sibling pointer. Nothing is padded and every clause carries actionable information.

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

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

With no output schema, the description still names the return payload (quality/codec list, selected DASH video and audio URLs, size estimates) and the constraints on using those URLs. An agent has everything needed to call it and act on the result.

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

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

Schema description coverage is 100%, with each parameter (page, codec, quality codes, include_all) fully documented in the schema itself, so the baseline is 3. The description only echoes the quality/codec enumeration at a high level and adds no format or default nuance beyond the schema.

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

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

States a specific verb+resource: it lists available qualities/codecs and returns the selected DASH video/audio stream direct URLs with size estimates. This is clearly separable from siblings like bili_video_info (metadata) and bili_download (file saving).

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 routes the agent away from this tool when the goal is saving locally ("想直接存到本地请用 bili_download"), which is the key fork. It does not say when to prefer bili_video_info over this tool, but the main alternative is named.

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

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

注解已声明 readOnlyHint=false、destructiveHint=true、idempotentHint=true，安全画像清楚；描述在此之上补充了注解无法表达的鉴权与开关要求（bili_jct Cookie、BILIBILI_ALLOW_WRITE 环境变量），这是真正增量信息。未说明失败场景（未登录/视频不存在）或移除操作是否可撤销，故非满分。

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?

两句话零冗余：第一句说明做什么，第二句前置警示鉴权与开关要求。信息密度高且前后顺序合理，安全警示紧跟用途之后。

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?

两参数、无输出 schema、注解已覆盖安全与幂等画像，描述的职责主要是说明用途与写入准入，这两点都做到了。剩余缺口是失败/错误行为与返回值形态未提及，但因无 output schema 且工具简单，属可接受范围。

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

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

schema 覆盖率仅 50%：input 有描述（多种视频标识格式），action 仅靠枚举值自解释。描述中「加入或移出」恰好为 add/remove 提供了语义映射，但未补充 action 之外的行为差异（如 add 幂等、remove 后列表顺序等）。基线 3 合适。

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?

「把视频加入或移出「稍后再看」」以具体动词（加入/移出）指向明确资源（稍后再看列表），并直接对应 action 枚举的 add/remove。同名参数 input 接受 BV/av/ep/ss/短链，由 schema 补全，不与任何兄弟工具重叠，agent 无需打开 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?

描述给出了可写前置条件（Cookie 含 bili_jct、BILIBILI_ALLOW_WRITE=true），这属于环境前提而非使用时机建议。没有任何「何时该用/何时不该用」或与 bili_video_info、bili_download 等兄弟工具的选择指引，agent 只能靠自己推断。

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