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

Annotations provide readOnlyHint=false and openWorldHint=true, so the write and network nature is partially covered. The description adds little beyond this; offline credential persistence is not mentioned, and the output schema means return values needn't be explained. It also awkwardly says 'poll QR status', which implies a polling read behavior inconsistent with the declared write operation.

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

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

The text is short but poorly structured: the main Chinese description is vague, the useful English gloss is relegated to a parenthetical below it, and the purpose is split across two lines. Front-loading the actual action would improve this significantly.

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

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

Given this is a stateful two-step login flow with a sibling start_qr_login and a 100% schema coverage plus output schema, the description is just barely adequate. It names the flow step but omits prerequisites (requires a valid key from start_qr_login), state expectations (QR must be scanned), and the side effect of persisting credentials locally.

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 documented in the schema, including the linkage of 'key' to start_qr_login. This establishes the baseline of 3; the description adds no parameter-level detail beyond what the schema provides.

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 English gloss 'finish QR code login' states a recognizable verb+resource, but the primary description is the vague Chinese phrase '取回凭据并写入本地' (retrieve credentials and write locally), which describes an effect rather than the operation. The parenthetical is more informative than the main text, which is backwards and muddled.

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 parenthetical 'finish QR code login, poll QR status' implies this is the completion step in a flow that starts with the sibling start_qr_login, which gives usable context. However it never explicitly says when to call this versus get_login_status, nor what preconditions exist.

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?

Exceptional disclosure beyond annotations: chronological ordering, total/withheld counting semantics, per-comment error isolation (a failed main comment only surfaces in its own error), partial-return behavior under rate limiting, cache identity rules, and the fact that rate-limited incomplete results are not cached. It is fully consistent with readOnlyHint=true and safe to call.

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?

Every sentence carries real behavioral payload, which is a strength, but the text is not front-loaded: it opens with an ordering detail rather than what the tool returns, and the purpose only emerges from the accumulating details. Structure is dense but reader-hostile on first pass.

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 an output schema and annotations present, the description needn't explain return values, and it still covers caching, error isolation, rate limiting, and withholding semantics thoroughly. For a 7-parameter, paginated, cached read tool, an agent has everything needed 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 description coverage is 100%, so the schema already documents all 7 parameters and the baseline is 3. The description adds marginal value on refresh/pages caching semantics, but the meanings of comment_ids, video, start_page and jq are already supplied by 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?

The description details the content (二级评论 under a main comment) and closes with the keyword hint '(comment replies, sub-replies, thread)', so an agent can infer the resource. But there is no explicit verb-first statement of what the tool does, and no differentiation from the sibling get_comments, which fetches main comments vs. these sub-replies. Purpose is inferable but not stated.

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 actionable operational guidance—use refresh for new data, split heavy fetches across calls due to the ~30 pages/min limit, and cache reuse across identical-parameter calls. However it never states when to use this tool over get_comments or any alternative sibling, so selection guidance is only 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the output-format detail that image_urls and link_titles are newline-delimited strings, which is genuinely useful and not in the annotations. However, it says nothing about pagination, caching, or rate limits — those live entirely in the schema, so the description's independent contribution is modest.

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?

Extremely terse and front-loaded: the reply exclusion, the alternative tool, and the field-format note are all delivered with zero filler. The trailing "(video comments)" fragment is slightly awkward but functions as the resource label.

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 rich schema carries pagination/caching/mode semantics. Given that, the description covers what it uniquely must: scope (top-level only) and the routing alternative. Only the thin positive statement of purpose keeps it from a 5.

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% and the parameter descriptions are unusually detailed (mode/cursor/batch_id pagination and caching semantics), so the baseline is 3. The description adds no input-parameter meaning at all — the newline-separated note concerns output fields, not the 8 input params — so it cannot exceed baseline.

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 resource ("video comments") and scopes it precisely by excluding second-level comments, then names the sibling get_comment_replies that handles them. An agent can distinguish it from get_comment_replies and get_video_info without opening a schema, though it never states the verb 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?

It gives an explicit routing rule: replies are NOT returned here and must be fetched via get_comment_replies. That is a clear when-to-use-this-vs-alternative statement for the main ambiguity. It does not address other sibling tools or when this tool is inappropriate beyond the reply 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?

The description discloses behavior far beyond the readOnly/openWorld annotations: platform caps on danmaku_count that scale with part duration, per-part caching with cached_at semantics, refresh to bypass cache, and the non-obvious fact that the server finishes fetching even when the caller receives no result (with the next call served from cache). This is exactly the kind of operational context an agent cannot infer from structured fields.

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?

Content is dense and mostly front-loaded: output layout first, then caps, then caching, then the timeout caveat. Every sentence carries information, though the cap examples and cache prose are somewhat verbose and the layout is a loose bullet-like stream rather than tight prose.

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

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

An output schema exists, yet the description usefully complements it by explaining caching fields and cap semantics that the schema cannot convey. For a read-only, open-world fetch tool the coverage is nearly complete; only explicit sibling differentiation 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 description coverage is 100%, so the baseline is 3. The description's mention of ?p= and refresh restates what the schema already documents ('?p= 可写单段或范围'; '跳过缓存重新取'), so it adds little parameter meaning 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?

The opening lines describe the return shape (one group per video, one row per part, part number via page) and the trailing gloss '(danmaku count per part)' pins down the resource. The verb is implicit rather than stated up front, and it does not explicitly distinguish itself from the sibling get_comments (comments vs. danmaku). Clear enough for selection, but not a crisp verb+resource lead.

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 real operating guidance: omit ?p= to get all parts, use refresh for fresh data. However there is no explicit when-to-use/when-not framing and no routing to an alternative sibling (e.g. get_comments for actual comment text). Usage is implied rather than declared.

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 one useful fact, the 30-item batch cap, but says nothing about pagination/refresh behavior or authentication, so it adds only modest context beyond 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 with the resource and the batch limit front-loaded, plus compact discovery keywords. Nothing is redundant or padded.

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

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

With an output schema present and annotations covering the safety profile, the description needn't explain return values or read-only status. The only meaningful gap is that it never clarifies how the feed differs from the sibling search tools, which an agent might need to route 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 description coverage is 100% and the jq parameter is documented in exceptional detail (field list, size warnings, result formatting), so the schema carries the full burden. The description contributes nothing about parameters; 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?

Names a concrete verb+resource: the Bilibili homepage recommendation feed, with a stated batch cap. It is clearly distinguishable from siblings like search_videos or list_up_videos, though it never states that distinction explicitly.

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

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

The gloss '(browse)' implies a discovery use case, but there is no explicit when-to-use/when-not guidance and no routing to alternatives such as search_videos when the user wants a targeted result rather than passive browsing.

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/network profile is covered. The description still earns credit by disclosing a genuinely non-obvious behavioral detail: is_login can be null meaning 'unable to verify', which is distinct from false. That tri-state semantics is the kind of information structured fields do not convey.

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?

Very short and front-loaded, with the most decision-relevant fact (null ≠ false) surfaced early. The trailing '(login status)' is mildly redundant with the tool name but the text is otherwise waste-free.

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 null-vs-false note covers the main ambiguity. However, for a tool sitting among four auth-related siblings, the absence of any usage context leaves a real gap in 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?

Schema description coverage is 100% for the single 'description' parameter, so the schema already carries the semantics (工具名:目的). 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?

The description says it verifies online with the platform (联网向平台核验) and the trailing tag '(login status)' names the resource, so the intent is inferable but not stated as a clean verb+resource. It never distinguishes itself from siblings like start_qr_login, complete_qr_login, or logout, which is exactly where an agent would need disambiguation.

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 at all: nothing says whether this should be called before/after login flows or how it relates to start_qr_login / complete_qr_login. The agent must infer the calling context entirely from the tool name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only the grouping behavior ('one group per video, one item for a single-segment video'), which is minor and partly duplicated by the output schema. No auth, rate-limit, or ordering behavior 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?

It is very short, but the telegraphic bilingual phrasing ('即分 P', '每个视频一组') and the parenthetical mash of Chinese and English gloss make it feel under-specified rather than tight. The key idea is front-loaded, but readability suffers.

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 requires three parameters, including an unusual 'description' field whose required format ('工具名:目的') and the mandatory jq expression are never explained in the description. With an output schema present, returns are covered, but the description leaves the agent without guidance on these non-obvious required inputs.

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 all three parameters (including the detailed jq expression semantics) are documented in the schema itself. The description adds no meaning beyond that, which meets the baseline 3 for fully documented schemas.

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 gloss '(video parts, pages)' conveys that this retrieves a video's multi-part (分P) segments, grouping them per video. However, the phrasing is telegraphic with no clear verb, and it never states what the tool actually does in a sentence an agent can act on. It distinguishes it loosely from siblings like get_video_info, but only by inference.

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

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

There is no statement of when to use this tool versus alternatives such as get_video_info or get_subtitles. The description merely describes the return shape ('one group per video'), leaving the agent to guess the selection context.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds a real reliability caveat (subtitles may be AI-generated or machine-translated and contain errors) and states sentence-level granularity, but says nothing about auth needs, rate limits, or pagination behavior for a multi-page resource.

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 plus a keyword line with no filler, and the return-granularity statement is front-loaded. The parenthetical keyword line is mildly redundant with the tool name but earns its place as a search/disambiguation aid.

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 re-explained, and the accuracy caveat covers the main quality risk. Still, for a 5-parameter tool with pagination and language selection, the absence of any when-to-use or alternative-routing content leaves a clear gap.

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

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

Schema description coverage is 100% and the jq/lang/page/video parameters are documented in detail within the schema itself. The description contributes no additional parameter meaning, 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?

The bilingual keyword line "(subtitles, captions, transcript)" identifies the resource, and "逐句返回" indicates sentence-level return granularity. However, the opening line describes output shape rather than stating a verb+resource purpose, and it draws no distinction from siblings like get_danmaku_counts or get_parts.

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

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

There is no guidance on when to use this tool versus alternatives, nor on prerequisites such as login state or which lang track to prefer (deferred entirely to the linked available_langs). The AI-generation/translation caveat is a data-quality note, 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds nothing behavioral beyond a restatement of returned fields — no note on per-input failure handling (the schema hints that only 'input' and 'error' are populated on failure), no mention that author_url may be omitted to reduce volume, and no error semantics 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?

It is short, which is good, but the content is a field enumeration that largely duplicates the output schema rather than front-loading what the tool does. The second line (the English parenthetical) is the only genuinely informative part, and it is relegated to the end.

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 — yet the description consists almost entirely of return values. What is missing is the operation itself: that it takes one or more UP masters (space URL or mid) and returns profile data, and why one would call it over sibling tools. For a 3-required-parameter tool, this is inadequate.

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 the schema already documents all three parameters (authors, jq, description) thoroughly. The description contributes no additional parameter meaning; baseline 3 applies when the schema carries the full load.

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 name plus the parenthetical '(uploader profile, channel info, followers)' implies fetching uploader profile data, but there is no verb statement — the body is a list of returned fields (nickname, signature, level, follower count, etc.) rather than a description of the operation. No sibling differentiation is offered despite list_up_videos and get_video_info being close relatives. Purpose is inferable but vague.

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

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

The description gives no indication of when to use this tool, what it requires (e.g., that it accepts a list of UP masters), or how it differs from list_up_videos or get_video_info. The agent must infer the context entirely from the name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuine context beyond that: running-vs-latest semantics, that 'latest' can be null when unresolvable, and that stale descriptions indicate a cache. This is useful behavioral disclosure that the annotations alone do not convey.

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 text is compact and each clause carries a distinct fact (version, cache detection, since usage, unknown-parameter tolerance, reconnect rule, null case). It is somewhat tangled and reads as concatenated notes rather than front-loaded prose, but there is little wasted wording.

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. The description covers the operational semantics an agent needs: version comparison, cache staleness, the null case for 'latest', and the reconnect/unknown-param behaviors. It is reasonably complete for a low-complexity version 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 100%, so the 'since' and 'description' parameters are fully documented in the schema itself. The description echoes the 'since' usage ('可把 0.13.0 传入 since') without adding syntax or format detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 never states a clean verb+resource like 'returns the server version'; instead it opens with '本说明对应版本 0.13.0' and discusses caching semantics. The trailing '(server version)' tag is the only direct signal of what the tool returns. Purpose is implied rather than stated, and it does not distinguish itself from the 15 sibling tools beyond the 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?

It offers implicit guidance — pass 0.13.0 into 'since' to see usage changes, and reconnect if a tool is missing from the list — which explains how the version signal should be acted on. However it gives no explicit when-to-use vs alternatives, and the advice is tangled up with caching mechanics rather than framed as usage scenarios.

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

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

With readOnlyHint=true and openWorldHint=true already covering the safety profile, the description contributes genuinely useful semantics beyond the annotations: comment count includes secondary comments, danmaku count and total duration are sums across all segments while current-segment duration counts only one part, single-segment videos ignore ?p= and leave current_page empty, and staff is only populated for joint submissions with a documented 'name(role,mid)' format. No auth, rate-limit, or failure-mode detail is given, but the edge-case semantics are a real addition.

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 text is dense and free of filler, with the statistical caveats packed into a few clauses. Its only weakness is structural: it opens with a verbless fragment ('contains title, author...') instead of a front-loaded statement of purpose, so the reader must reconstruct the action from context.

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 batched, jq-driven tool with an output schema, the description correctly focuses on the tricky counting semantics and per-segment behavior rather than re-explaining return values. What remains missing is routing guidance toward overlapping siblings and any note on partial-failure behavior beyond what the jq schema already covers.

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 the jq, videos, and description parameters are already fully documented in the schema, making 3 the baseline. The description's note that single-segment videos ignore ?p= and that current_page is empty mildly reinforces the videos-parameter semantics, but adds no new syntax or format information beyond what the schema states.

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 returned contents (title, author, publish time, summary, stats) rather than stating a verb+resource action; an agent must infer that this fetches metadata for one or more videos. The trailing keywords '(video info, metadata, stats)' reinforce the resource but do not distinguish it from siblings like get_parts or get_danmaku_counts, which cover overlapping data.

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

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

There is no explicit when-to-use statement, no exclusions, and no routing to alternatives such as get_parts (segments) or get_danmaku_counts (danmaku). The statistical caveats hint at overlap with those siblings but never tell the agent which tool to pick.

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 and open-world behavior, so the description doesn't need to restate safety. It adds useful pagination behavior: max 40 items per batch, and total semantics where keyword changes total to the matching count. It still omits auth/rate-limit details, but the added pagination context is meaningful.

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 definition is very concise and every sentence carries useful information. Its structure could be better front-loaded, since the purpose appears in a trailing English parenthetical after pagination details, but there is 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?

An output schema exists and schema coverage is complete, so return values and most parameter details need not be described. Still, for a six-parameter list tool with several sibling listing/search tools, the description is minimally adequate and lacks clear routing guidance for when to choose it over alternatives.

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 the schema already documents all six parameters. The description adds output-related meaning for keyword ('total is matching count when keyword is present') but does not meaningfully extend parameter syntax or semantics 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?

The parenthetical names the resource scope ('uploader videos, channel uploads, other videos by this author'), and the batch/total text implies a listing operation. However, there is no explicit verb phrase such as 'List videos for a given author,' and it does not clearly differentiate itself from siblings like search_videos or get_up_info.

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

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

The scope phrase implies this tool is for an author's uploads, giving an implicit use context. But it gives no explicit when-to-use guidance, prerequisites, or comparison to alternatives such as search_videos, get_feed, or get_up_info.

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

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

Annotations already establish readOnlyHint=false and openWorldHint=false, so the mutating, non-open-world profile is covered. The description adds one genuinely useful behavioral detail beyond annotations — that the deletion targets *locally stored* credentials rather than server-side session state — but says nothing about reversibility or whether re-authentication is required.

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

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

One short, front-loaded clause with no filler; the bilingual synonym in parentheses earns its place by improving retrieval match for 'log out'/'sign out'. Every token serves a purpose.

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 annotations cover the safety profile. However, for a destructive local action the description omits the practical consequence (session invalidation, need to re-login), leaving a meaningful gap for an agent deciding whether to call it.

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

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

There is a single parameter with 100% schema description coverage, so the schema already documents it ('格式为 工具名:目的。'). The description adds no parameter-level information, which is acceptable given the high coverage; 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?

The description states a specific verb and resource ('删除本地保存的凭据' / delete locally saved credentials) and the parenthetical 'log out, sign out' reinforces intent. It is clearly distinguishable from the login siblings (start_qr_login, complete_qr_login, get_login_status), though it does not name any of them 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?

There is no when-to-use or when-not-to-use guidance beyond the implied act of logging out. No alternatives (e.g. get_login_status to check state first) or prerequisites are mentioned, so the agent must infer all usage context.

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

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

Beyond the readOnly/openWorld annotations, it discloses real behavioral traits: a 30-item batch cap, a 30-batch total ceiling, paid courses being filtered out, and batches sometimes being short. These are non-obvious operational facts an agent could not infer from annotations or schema.

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

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

The text is short with no filler, but it is not front-loaded: it opens with batch limits and truncation quirks before the purpose, which is buried in a trailing parenthetical. Purpose should lead, so structure is only adequate.

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 description covers pagination, filtering, and the summary-truncation caveat. Combined with the rich schema, an agent has enough to call it correctly; only the sibling-routing gap keeps it from a 5.

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 the schema already documents all five parameters in detail, including the jq input fields and the order enum. The description adds only marginal parameter context (batch size, filtering) and does not explain syntax beyond the schema, so 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?

The parenthetical 'search videos, find video by keyword' gives a clear verb+resource, and the body notes it filters out paid courses. It distinguishes itself from list_up_videos and get_feed implicitly, but never names those siblings, so it stops short of an explicit contrast.

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

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

It routes the agent usefully: summary is truncated, so use get_video_info for the full description, and it explains pagination via batch limits and the cursor. There is no guidance on choosing this over suggest_keywords or get_feed, so it falls 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?

The annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds important behavioral context: it does not write local credentials, whereas complete_qr_login does. It does not mention auth requirements or rate limits, but the core side-effect distinction is clearly 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 very short and front-loaded with the return value, then adds the credential-writing distinction. The English parenthetical '(QR code login)' is somewhat redundant, but the overall structure is efficient and wastes little space.

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

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

For a simple login-start tool with annotations covering safety and no output schema, the description adequately states what is returned and how it relates to complete_qr_login. It could say more about the login workflow sequence, but it is 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?

There is one required parameter, and schema description coverage is 100%. The schema already explains the description parameter format, and the tool description adds no further meaning about that parameter, so the baseline of 3 is 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: returns an inline QR code image and the corresponding link URL. It also distinguishes itself from the sibling complete_qr_login by explicitly saying credentials are not written locally and that complete_qr_login handles writing them.

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 clear workflow context by naming complete_qr_login as the credential-writing step, which implies this tool starts the QR login flow. It does not explicitly state when not to use this tool or list alternative login-status tools, but the context is sufficient for an agent to route correctly.

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 real behavioral value beyond that: a hard cap of 10 results and the caveat that symbols like + and # are ignored during suggestion. It does not discuss rate limits or error behavior, but the added constraints are meaningful.

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 plus a synonym tag; the core purpose is front-loaded and nothing is redundant. It is well-sized for a simple lookup 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?

An output schema exists, so return-value explanation is unnecessary. The description covers purpose, result limit, and a notable input caveat. The main gap is the absence of routing guidance relative to sibling search/feed tools, but otherwise it is complete for this tool's complexity.

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

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

Schema description coverage is 100%, so the schema already documents both 'term' and 'description'. The description adds no parameter-level detail (e.g., partial-word behavior or the odd '工具名:目的' format for description), so the baseline of 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?

The description states a specific resource and behavior: 'B站搜索框的联想词' (Bilibili search-box autocomplete), capped at 10 results. The parenthetical synonyms ('search suggestions, autocomplete, related keywords') reinforce the concept. It is distinguishable from the sibling search_videos, though it never names that sibling explicitly.

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

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

There is no when-to-use or when-not-to-use guidance. The synonym list aids keyword matching but does not tell an agent when to pick this over search_videos or get_feed. No conditions, prerequisites, or alternatives are stated.

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