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

Annotations declare readOnlyHint=false and openWorldHint=true, and the description is consistent with that – it says credentials are retrieved and written locally, confirming a local write side effect. It adds that the call polls QR status, but does not clarify whether it blocks/loops until success, how long it waits, or what credentials are stored where.

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

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

The description is short and front-loads the core action, but the two fragments (Chinese action phrase and English parenthetical) partially overlap and partly conflict, so it is compact without being cleanly structured.

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

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

An output schema exists, so return values need not be described, and the single parameter is fully covered. The remaining gap is behavioral: the polling/blocking nature of the completion and the relationship to the start_qr_login/get_login_status pair are not fully clarified, leaving a simple auth flow tool only minimally specified.

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 single key parameter is fully documented in the schema itself. The description adds no meaning about the key beyond what the schema already states, so the baseline 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 conveys a verb+resource combination ('取回凭据并写入本地' – retrieve credentials and write locally) tied to finishing a login flow, which separates it from start_qr_login. However, the parenthetical '(finish QR code login, poll QR status)' mixes completion and polling semantics, muddying whether this tool finishes the login or merely checks status – the latter being the job of get_login_status.

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 indirectly through the parameter description ('the key returned by start_qr_login'), and even that lives in the schema, not the description. There is no explicit statement of when to call this versus start_qr_login or get_login_status, and no exclusion or prerequisite 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?

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses 30-minute result caching with cached_at, partial-return semantics when throttled or risk-controlled, per-comment error isolation, withheld/deleted reply counts, and how parent_id indicates the reply target. That is exactly the operational context an agent needs before calling.

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 content is useful but unstructured: it opens with an ordering property and a login note rather than the tool's action, then runs through output-field explanations and failure modes as a flat block. Given an output schema exists, several of these sentences are redundant padding, and the length is not front-loaded around the primary 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?

For a read-only, 5-parameter, paginated call it covers login requirement, pagination via pages/has_more, error and throttling behavior, and caching freshness. Minor omissions remain (no guidance on how many comment_ids are sensible per call, no explicit rate-limit ceiling), but nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so url, pages, start_page, jq and comment_ids are already documented in the schema; the description adds little parameter-level meaning beyond what is there. Most of its prose concerns returned fields (total, withheld, parent_id, image_urls, link_titles), not inputs. 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 identifies a specific resource and scope – second-level replies under a given main comment, returned in ascending time order – and the trailing '(comment replies, sub-replies, thread)' keywords reinforce it. It also ties itself to the sibling get_comments by stating comment_ids are taken from get_comments' comments table. It never states the core action in a single upfront verb+object sentence, so it is clear but not maximally crisp.

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?

Prerequisites are given ('需要登录', comment_ids sourced from get_comments), which implicitly lays out the workflow. It also explains the degraded cases – per-comment errors, partial results under rate limiting. It does not explicitly say when not to use it or name a competing tool, but no sibling overlaps this purpose.

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

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

Annotations only declare readOnlyHint and openWorldHint, so the added '需要登录' (login required) is genuine behavioral context beyond structured data. It also discloses output-shape quirks (image_urls/link_titles newline-joined), though it says nothing about rate limits or caching.

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 lines, front-loaded with the scoping constraint and login requirement, then the formatting caveat. No filler or repetition of schema content.

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 an output schema exists and the input schema is fully documented, the description supplies the missing pieces an agent needs: login requirement, reply exclusion, and field formatting. The only gap is that mode/cursor usage strategy lives entirely in the schema rather than the top-level description.

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

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

Schema description coverage is 100%, so the schema already carries the heavy parameter burden (mode/cursor semantics, count pagination behavior, jq contract). The description adds only a small formatting note about image_urls and link_titles, which nudges it to the baseline of 3 rather than above.

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 explicitly scopes it by excluding secondary comments, naming the sibling get_comment_replies that handles those. It lacks an explicit verb like 'list'/'fetch', but the resource and boundary are unambiguous enough to distinguish it from siblings.

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

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

It explicitly routes reply-fetching to get_comment_replies and states the login prerequisite. It does not cover the hot-vs-newest choice or when to use this versus search_videos/get_feed, but the primary sibling disambiguation is present.

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 that the platform may return only partial danmaku, fewer than video info indicates, which is useful data-completeness context. However it omits auth, rate-limit, and return-format details, making 3 appropriate against the lower bar set by 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?

The description is very brief and every sentence is relevant, but it is not front-loaded: it opens with a field note rather than what the tool does. The parenthetical translation feels like an afterthought. There is no bloated text, but the structure does not prioritize selection-relevant 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?

Output schema exists and annotations cover read-only/open-world behavior, so return values and safety need not be explained. The remaining gap is purpose and when-to-use guidance, especially versus get_comments, which makes it only minimally complete for a tool with four parameters and three required fields.

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 input parameters are fully documented in the schema. The description's timestamp note likely refers to an output field, and its partial-danmaku caveat only reinforces the count parameter saturation already described in schema. Baseline 3 is correct 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 explicitly states that the tool retrieves danmaku/bullet comments; it only explains that timestamp is seconds and notes partial data. The parenthetical '(danmaku, bullet comments)' identifies the resource, but without a verb or clear purpose statement the agent must infer the action from the tool name. It also does not differentiate from siblings like get_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?

There is no when-to-use guidance, no alternatives, and no conditions for selecting this tool over get_comments or others. The only context given is a caveat about partial data, which does not help an agent decide when to call it.

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 safety is covered; the description's added value is the 'max 30 per batch' volume constraint. It does not say whether the feed is personalized, whether results refresh between calls, or what pagination behavior exists, so it is only a modest addition over 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?

One short sentence in Chinese plus a keyword line; the resource and its volume limit are front-loaded with zero filler. Every element earns its place.

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

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

With an output schema present, return values need no explanation, and the input schema fully documents jq. What is missing is routing context: how this feed relates to keyword search or per-UP listing, and whether the 30-item cap can be extended. Adequate but with a real usage 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% — the jq parameter is documented at length in the schema itself (input array, per-item fields, return-encoding rules, jq_count). 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 resource and verb-equivalent: the Bilibili homepage recommendation feed, with an explicit batch cap of 30 items. That is enough to distinguish it from search_videos, get_video_info or list_up_videos, though it never names those siblings as alternatives.

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

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

The parenthetical keywords (homepage feed, recommendations, browse) hint at the browse use case but give no when-to-use/when-not guidance. Nothing tells the agent to prefer this over search_videos or list_up_videos for discovery.

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 two pieces of behavioral context beyond that: the authentication requirement and the return form (an inline JPEG rather than a URL or metadata). It stops short of noting errors for out-of-range timestamps or download behavior, so it isn't fully transparent.

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

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

Two short clauses with no filler, and the output format leads ahead of the auth requirement. The only weakness is that brevity shades into under-specification rather than pure efficiency.

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 three-parameter tool with full schema coverage and no output schema, the description covers auth and return format, which is the minimum an agent needs. However, it says nothing about failure modes (invalid link, timestamp beyond video length) or whether the frame is fetched remotely, which would be valuable for an openWorld read.

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 url, page, and timestamp thoroughly, including defaults and edge cases. The description adds no parameter detail whatsoever, 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 states the output ('returns an inline JPEG image') and the keyword tags '(video frame, screenshot)' combined with the name get_frame make the function clear: fetch a still frame from a video. It doesn't explicitly say it extracts the frame at a given timestamp, but the schema fills that in, and no sibling competes for the same purpose.

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?

'Login required' is a useful precondition for invoking the tool, but there is no guidance on when to choose this over siblings like get_video_info or get_subtitles. Usage is only implied by the tool's name and the required timestamp parameter.

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 and external-network profile is covered. The description adds value beyond them by disclosing the tri-state result ambiguity — null means verification was impossible, which is materially different from a definitive false — a failure mode callers must handle specially.

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: the action comes first, the important result caveat second. The trailing parenthetical '(login status)' merely restates the tool name and is the one piece of 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 parameters and an output schema already documenting return fields, little is strictly required. But for a tool inside an authentication flow, the description gives no sense of its place relative to start_qr_login, complete_qr_login, or logout, leaving the agent to guess the sequencing.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate on the input side, and it does not waste words inventing any.

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

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

The verb+resource pairing is present: it says it verifies login state against the platform over the network, and the is_login note confirms it returns a login status. However, it never distinguishes itself from the closely related siblings start_qr_login, complete_qr_login, and logout, so an agent must infer where this check sits in the login flow.

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. It does not say to call this before start_qr_login, after complete_qr_login, or to confirm state after logout — the exact routing decision the sibling set demands. The null caveat is about interpreting a result, not about choosing this tool.

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 scope are covered. The description adds one genuine behavioral fact beyond that, namely that a single-segment video yields a single item, which helps set expectations about result cardinality. It stops there, disclosing nothing about rate limits, auth needs, or 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?

The text is very short and has no wasted words, but it reads as two disconnected fragments rather than a front-loaded informative sentence. It is concise to the point of under-specification rather than efficient communication.

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 the parameter schema is fully documented, so the description is not obligated to explain return values or parameter formats. However, for a 2-required-param tool in a crowded sibling set, the lack of any routing guidance leaves a real gap that the structured fields cannot fill.

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 both parameters (url, jq) are documented in detail in the schema, including the array shape and field names (page, part, duration). The description adds no parameter-level information beyond that, 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 identifies the resource (分P / video parts / pages) but largely restates the tool name rather than naming an action with scope. The English gloss '(video parts, pages)' helps clarify the domain, and '单段视频返回一项' hints at output cardinality, but it never says explicitly what is fetched or how it differs from get_video_info.

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

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

There is no when-to-use guidance, no exclusions, and no mention of alternatives such as get_video_info, get_danmaku, or get_subtitles, all of which are plausible siblings an agent could confuse with this one. The agent must infer usage purely 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 cover the safety profile (readOnlyHint, openWorldHint), and the description adds meaningful context beyond them: an auth requirement and a data-quality caveat that subtitles may be AI-generated or machine-translated and thus error-prone. No format or pagination detail, but the added warnings are genuinely useful.

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-loads the return format, auth requirement, and quality caveat in three short lines with no filler. Slightly under-elaborated rather than verbose.

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 a full output schema and 100% parameter coverage, the description need only carry auth and caveats, which it does. The remaining gap is the absence of guidance on when to prefer this over related content tools.

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 jq, url, lang, and page each thoroughly documented in the schema (including the 逐句 output shape and available_langs). The description adds nothing about parameters, 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 name get_subtitles plus the parenthetical gloss (subtitles, captions, transcript) makes the resource unambiguous, and 逐句返回 specifies the return granularity. It is clear what the tool retrieves, though it lacks explicit differentiation from siblings like get_danmaku.

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

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

It states a prerequisite (需要登录) but gives no when-to-use guidance or alternatives relative to sibling tools such as get_danmaku or get_video_info. Usage is only implied by the tool name and keywords.

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 nothing behavioral — no auth requirement, no rate limit, no caching or freshness note — and the field list it does give is redundant with the existing output schema.

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

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

Very short, but the brevity comes from omission rather than tight construction — it is a bare field list with a parenthetical gloss, lacking a leading verb or use context. Nothing is padded, but nothing is front-loaded either.

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 single parameter is fully documented in the schema. What remains missing is when to reach for this tool versus its many siblings, leaving the definition adequate but not self-sufficient.

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?

Only one parameter, and schema coverage is 100% with a description explaining it accepts either an author_url or a numeric mid. The description adds no parameter meaning beyond the schema, 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 enumerates returned fields (昵称、签名、等级、粉丝数…) and adds the gloss 'uploader profile, channel info, followers', which implies a profile-fetch, but it contains no verb and never states it retrieves UP主 profile data. It also does not distinguish itself from siblings like list_up_videos or get_video_info.

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

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

There is no statement of when to use this tool, no prerequisites (e.g. needing an author_url from another tool), and no mention of alternatives. The agent must infer usage entirely from the field list.

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 does add genuinely useful interpretation context beyond annotations — that comment counts include second-level replies, danmaku counts and full duration are summed across all parts, while segment duration is per-segment — but it says nothing about auth needs, rate limits, or failure behavior.

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

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

The text is short and the statistical caveats are valuable, but it is not front-loaded with a purpose statement — it opens with a field enumeration that duplicates what the existing output schema already provides, making the first sentence the weakest rather than the strongest part.

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, the description need not restate return fields, and it does supply the non-obvious aggregation semantics an agent needs to interpret those fields correctly. Annotations cover the safety profile and the schema covers both parameters, leaving only usage routing unaddressed.

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

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

Schema description coverage is 100%, so both url (link/short-link/BV-av/share text) and page (1-based segment index, fallback to ?p=N, then segment 1) are already fully documented in the schema. The description contributes nothing additional about parameters, 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 never states an action verb; it opens with a list of returned fields (title, author, publish time, description, statistics), which largely restates the tool name get_video_info. It weakly implies the resource is a single video's metadata rather than comments/danmaku/parts, but the differentiation from siblings is left to inference.

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

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

There is no statement of when to use this tool, no prerequisites, and no reference to alternatives such as get_parts or get_comments even though those siblings overlap in subject matter. The agent must infer usage purely from the name and schema.

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 cover readOnlyHint=true and openWorldHint=true, so the safety profile is already known. The description adds genuinely non-obvious behavior: max 40 items per batch, that 'total' means the overall video count but the matched count when a keyword is supplied, and that login is required. That is useful 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?

It is short, but the structure is poor: a trailing keyword-stuffed parenthetical in English and a stray list fragment, with the behavioral facts front-loaded instead of the purpose. Nothing is verbose, yet the ordering and mixed-language fragments cost clarity.

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 100% schema coverage, the description only needs to supply what structured fields cannot: the login requirement, the 40-per-batch cap, and the meaning of the total field. It covers those, so it is close to complete for this tool, though the missing purpose/usage framing is a small gap.

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

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

Schema coverage is 100% and the schema itself already documents jq, cursor, order, keyword, and author_url in detail, including that keyword matches beyond title. The description's keyword/total note largely restates what the schema says, 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 tool name and the parenthetical tag list ("uploader videos, channel uploads, other videos by this author") imply the resource, but the description never states a verb+resource sentence like 'list the videos uploaded by a given UP主'. The Chinese text instead leads with batch size and return semantics, so the core purpose is inferable rather than 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?

"需要登录" gives a prerequisite, but there is no when-to-use guidance and no routing against siblings such as search_videos, get_feed, or get_up_videos-style alternatives. An agent gets no signal about when this is the right tool versus a search or feed tool.

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 declare readOnlyHint=false, consistent with a credential-deleting operation. The description adds genuine context beyond the annotations by specifying the credentials are LOCAL, which tells the agent this is a client-side clean-up rather than a server session revocation. It does not state whether the user must re-authenticate afterward, keeping it short of 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?

A single front-loaded sentence carrying the full meaning, with the bilingual synonyms in parentheses aiding disambiguation. Nothing wasted.

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

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

An output schema exists, so return values need no explanation. For a no-argument, single-purpose logout tool the description covers what is needed; it only lacks a note on post-logout state or prerequisites.

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

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

The tool takes zero parameters, so the baseline is 4; the description has no parameter semantics to add and does not need to.

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

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

States a specific verb and resource: it deletes locally stored credentials, which is exactly what 'logout' means and distinguishes it from siblings like get_login_status and start_qr_login. Clear enough that an agent can tell it apart from the login-flow tools, though it doesn't name any of 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?

Usage is implied by the name and description — call this when the user wants to sign out — but there is no explicit when-to-use statement, no prerequisite (must be logged in), and no mention of how it relates to get_login_status or the QR-login tools. Adequate for such a simple, self-evident operation, but no guidance is actually provided.

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 readOnly/openWorld safety, but the description adds genuinely useful behavior: a 30-item batch cap, a 30-batch ceiling, paid courses being filtered out, batches possibly being short, and summaries being platform-truncated. These tell the agent how to interpret and iterate results, which the annotations do not.

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 with no filler, but the ordering buries the primary purpose at the very end behind pagination limits and field notes. The batch/pagination caveats are useful but would land better after a leading statement of what the tool does.

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, return-value detail is not required, and pagination (cursor/next_cursor) plus the truncated-summary caveat are covered. Combined with annotations covering the safety profile, an agent has enough to invoke and iterate correctly, though the lack of sibling routing detail is a minor 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%, so the schema already documents query, order, cursor, and jq thoroughly. The description adds almost nothing parameter-specific beyond noting that pagination fields are not part of the jq input, which the schema already implies. 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 trailing parenthetical states a clear verb+resource ('search videos, find video by keyword'), so the agent knows this searches the video catalog by keyword. It also hints at a sibling relationship by naming get_video_info for full descriptions. It does not, however, distinguish itself from suggest_keywords or list_up_videos, so differentiation is 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 gives one concrete routing rule — use get_video_info to get the untruncated summary — and explains the pagination flow via next_cursor. Beyond that there is no explicit when-to-use/when-not guidance relative to the other search-adjacent siblings, leaving selection mostly 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 and openWorldHint, so safety is partly covered, but the description adds genuinely useful side-effect context: no local credentials are persisted and the write happens in a separate tool. It does not mention QR expiry/refresh behavior, which would be the remaining gap.

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 return value and followed by the credential-handling note. No filler, though the redundant English '(QR code login)' parenthetical adds little.

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 input parameters and no output schema, the description adequately covers what the tool produces (an inline QR image) and how it relates to the completion step. Only the lifecycle details of the QR code (expiry, polling cadence) are absent, which is a minor gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. Schema coverage is 100% and trivially complete.

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 action and return artifact ('returns an inline QR code image') and explicitly distinguishes itself from the sibling that performs the write ('credentials are written by complete_qr_login'). An agent can select it without opening the schema.

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

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

The description makes the pairing with complete_qr_login clear, implying this is the entry step of a two-call flow. It does not state explicit preconditions (e.g., whether an existing session blocks the call) or an explicit 'when not to use', 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 safety is covered. The description adds genuinely useful behavior beyond that: a hard cap of 10 suggestions and the fact that symbols such as + and # are ignored during suggestion matching, which materially affects how an agent should phrase the input term.

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 an English synonym parenthetical; the result cap and symbol behavior are front-loaded and nothing is padded. Slightly more frugal than a fully optimized definition but no wasted text.

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

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

An output schema exists so return values need no explanation, and annotations cover the read-only/open-world profile. The description supplies purpose, result count, and input-symbol behavior, leaving only the selection guidance versus search_videos 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 `term` parameter is already documented as a possibly partial keyword. The description adds no format, length, or normalization rules for the term itself, so this sits at the baseline for high-coverage 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?

States a specific resource and scope: 'B 站搜索框的联想词' (Bilibili search-box autocomplete terms), capped at 10. It is clearly distinct from sibling tools like search_videos or get_video_info, though it never names an alternative to reinforce the 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?

Usage is only implied by '搜索框的联想词' — an agent can infer this is for typeahead-style suggestion expansion, not full search. There is no explicit when-to-use/when-not statement and no pointer to search_videos as the alternative for actual result retrieval.

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