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

Annotations already declare readOnlyHint=false and destructiveHint=false, so safety profiling is covered. The description adds high-value behavior beyond that: it is atomic, a failed cycle still burns quota, and ineligibility should end the turn silently — the quota-burn-on-failure trait is exactly the kind of consequence an agent must know 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?

Three short sentences, each carrying a distinct operational fact (what it does, when to call, failure cost). Zero filler and the core action is front-loaded.

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

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

For a zero-param mutation with no output schema and annotations covering safety, the description covers action, cadence, and failure cost. The one remaining gap is what makes the agent 'ineligible' and how to determine it beforehand — likely via whale_status — which is left to inference.

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

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

The tool takes zero parameters, so the baseline is 4; the description correctly implies no arguments are needed and nothing in the schema needs elaboration.

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

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

States a concrete verb and resource: atomically consume one daily browse opportunity. The word 'atomically' plus 'one daily' precisely frames the operation as a single-consumption claim, which is distinguishable from read-oriented siblings like whale_status or whale_record without opening a schema.

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

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

Gives explicit invocation cadence ('call once per heartbeat') and a clear stopping rule ('if ineligible, stop quietly'), which tells the agent not to retry or loop. It does not name a sibling for checking eligibility (e.g., whale_status), so the alternative path 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 read-only, non-destructive, open-world access, so safety is covered. The description adds two pieces of real behavioral context: results are ranked/top ('hot') rather than chronological or exhaustive, and anonymous access is a fallback when no credential exists. It does not say whether anonymous results are limited, rate-limited, or otherwise degraded.

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

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

A single short sentence with no filler; the operation and the anonymity condition are both front-loaded. Its brevity is close to under-specification, but nothing in it is wasted.

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

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

For a tool with zero parameter descriptions and no output schema, the description leaves critical gaps: what bvid identifies, what 'hot' ordering means, how many comments come back, and what the anonymous path changes about the response. An agent can guess the call shape from the schema but not the semantics.

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

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

Schema description coverage is 0%, so the description must compensate and it does not — neither bvid nor count is mentioned. The schema's regex and 1–20 range imply bvid is a video identifier and count is a limit, but the description adds no semantics such as what bvid means or that count caps the number of hot comments returned.

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

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

States a specific verb and resource ('Read hot comments'), which is distinct from every sibling (whale_video, whale_subtitles, whale_popular, etc.) since none of them return comments. It stops short of saying comments belong to a video identified by bvid, so the object of the read is only implied by 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 only conditional ('anonymously when no credential is configured') describes an auth behavior, not when to choose this tool over an alternative. There is no guidance on when to call whale_comments versus whale_video or whale_popular when an agent wants comment-adjacent data.

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, destructiveHint=false, and openWorldHint=false, and the description is consistent with that safety profile. It adds only the vague "recent local" scope and does not disclose freshness, pagination, or what "local" means.

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 a single front-loaded sentence with no filler. The terseness is a completeness problem rather than a conciseness problem.

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

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

For a one-parameter read tool with no output schema, the description does not explain what an "observation" contains, what "local" scopes to, or how many records are returned. The annotations cover safety only, leaving too much unspecified.

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 sole count parameter (default 10, max 50, min 1) is undocumented in the schema, and the description says nothing about it. With 0% schema description coverage, the description fails to compensate.

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 supplies a verb ("Read") and a resource ("recent local observations"), but "observations" and "local" are undefined. It also gives no clue how this tool differs from siblings such as whale_search or whale_popular.

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 prerequisites, and no named alternative. An agent must guess whether to call whale_diary or a sibling like whale_search or whale_popular.

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, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds genuinely non-redundant context: no authentication required, results are filtered against previously recorded videos, and the content must be treated as untrusted source material (a prompt-injection guard). It omits what "previously recorded" is measured against and whether results are paginated.

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, front-loaded sentences with no filler; each carries a distinct fact (scope/exclusion, auth, trust). Slightly ambiguous wording in "previously recorded" costs it the top mark.

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 single-parameter read tool with no output schema and strong annotations, the basics are covered. Gaps remain around what the return payload looks like (video objects? count?), whether results are stable/cached, and the undefined "recorded" set — all relevant to a discovery tool used before whale_record.

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

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

The single `limit` parameter has 0% schema description coverage (only type, default 10, min 1, max 20), so the description was the only place to explain it — but it says nothing about page size or the 20-item cap. An agent must infer the meaning of `limit` entirely from field names.

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

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

States a specific verb and resource ("Read public popular videos") plus a scoping filter ("excluding previously recorded videos"), which hints at the dedupe relationship with whale_record. It distinguishes from siblings like whale_search by emphasizing popularity and public access, though it never names an alternative outright.

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

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

"No login needed" gives a precondition, and the exclusion clause implies this is a firehose you use when you want unseen material. But there is no explicit when-to-use versus whale_search or whale_video, and no statement of what to do if everything is already recorded.

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 this is a non-read-only, non-open-world, non-destructive write operation. The description adds useful context that the save is local and that the video is marked seen, but it does not cover permissions, failure behavior, duplicate handling, or what 'mark video seen' changes on the server.

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

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

Three short sentences, with the primary action front-loaded and no wasted wording. The constraints that follow earn their place by limiting what may be saved and where it goes.

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 write tool with three required parameters and zero schema description coverage, the description is too thin. It does not explain the required identifiers, the meaning of the note/title fields, what happens on save, or what the tool returns, leaving significant gaps an agent must infer.

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

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

Schema description coverage is 0%, and the description does not mention the required bvid, title, or note parameters at all. The word 'observation' weakly implies the note field, and 'video seen' weakly implies bvid, but formats, constraints, and title semantics are left entirely to 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 states a specific verb+resource ('Save a local diary observation') and adds a secondary side effect ('mark video seen'). It is clear what the tool does, but it does not distinguish this write operation from the sibling whale_diary tool, so an agent could confuse the two without inspecting schemas.

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

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

The phrase 'Do not invent observations' and 'No external publication' set content and scope constraints, and the action implies usage after viewing a video. However, there is no explicit when-to-use guidance, no mention of when not to use it, and no pointer to alternatives such as whale_diary or whale_video.

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, openWorldHint=true and destructiveHint=false. The description adds one genuinely useful datum: the local login requirement, which is an authorization prerequisite not captured by the annotations. However, 'upstream WBI implementation' is internal jargon that does not disclose behavior, and pagination limits or failure modes are unmentioned.

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 compact sentence with the core action at the front. The WBI implementation clause is the only part that does not clearly justify 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?

There is no output schema and no description of what a search result contains (video fields, ordering, paging behavior beyond the schema's maximum), and parameters are undocumented. For a discovery tool, an agent is left guessing about the results and the page cap.

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

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

Schema description coverage is 0%, so the description has to explain both parameters. It says nothing about 'keyword' semantics or about the 'page' parameter's hard cap of 5, which meaningfully limits how callers use results.

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: search Bilibili videos. It is distinguishable from siblings like whale_popular or whale_video, but it does not explicitly say how it differs from 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?

It names a prerequisite ('requires local login') but gives no guidance on when to use this search instead of the sibling listing tools such as whale_popular, or what the search covers.

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, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds context beyond that: it operates on a locally configured cookie and deliberately never emits the raw cookie, a privacy trait invisible in the annotations. It does not say what happens on auth failure, which keeps 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?

Two short sentences, the purpose first and the output restriction second. 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?

For a no-param, no-output-schema read tool, the definition covers purpose, data source and output restriction. A little is missing about the success/failure signal (e.g. what an unauthenticated result looks like), which matters for a verification call an agent will branch on.

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 correctly signals that configuration comes from a local cookie rather than from arguments, which is the only parameter-relevant fact.

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 ('verify') and a specific resource (the account behind the locally configured cookie), which resolves the ambiguity of the opaque name 'whale_session'. It is implicitly distinct from data-fetching siblings like whale_popular or whale_video, but the differentiation is never made explicit.

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

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

Usage is only implied: an agent can infer this is an identity/auth-check step, but the description never says when to call it (e.g. before write operations like whale_record) or when not to. No alternative or prerequisite is named.

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

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

Annotations already declare readOnly, non-destructive, closed-world behavior, so the safety profile is covered. The description adds meaningful context beyond that: it reads LOCAL state, reports credential PRESENCE rather than validity, and explicitly disclaims login validation — preventing an agent from over-trusting the result. It does not say anything about cost, side effects, or format, but little more is needed for a read-only status 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?

Two short sentences with no filler, and the enumeration of reported values comes first. The opening is a verbless fragment ('Local configuration, credential presence and current autonomous window'), which is terse to the point of being slightly clipped, but it is front-loaded and easy to parse.

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

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

With no output schema, the description carries the burden of telling the agent what comes back, and it does so by enumerating the three reported items. The 'does not validate login' caveat covers the main misinterpretation risk. Only the shape/format of the returned data is left unspecified, which is a minor gap for a zero-param status tool.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline for a 0-parameter tool applies, and the description correctly signals that no input is expected.

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

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

The description names the three concrete things reported: local configuration, credential presence, and the current autonomous window. It is a noun phrase rather than a verb+resource statement, but an agent can still tell exactly what the tool returns. It does not explicitly distinguish itself from sibling whale_session, though the closing caveat hints at the boundary.

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 line 'Does not validate login' implies that login validation belongs to another tool (likely whale_session), which is a useful implicit exclusion. However, there is no explicit statement of when to call this versus whale_session or whale_claim_cycle, so the routing guidance is inferred rather than stated.

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

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

Annotations already establish readOnly=true, openWorld=true, and destructive=false, so the description does not need to repeat safety basics. It adds meaningful context by stating that login is required and that returned transcripts include timestamps, though it does not cover error behavior or whether subtitles may be unavailable.

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

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

The description is a single front-loaded sentence with no wasted text. The action, output trait, and login prerequisite all appear immediately.

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 read-only tool with annotations and no output schema, the description covers the core action, timestamps, and login prerequisite. However, it omits the meaning of the sole required parameter and does not clarify transcript format or availability constraints, leaving a notable gap for invocation.

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

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

Schema description coverage is 0%, and the only required parameter, bvid, is not explained at all in the description. The schema provides type and a regex pattern, but the description adds no meaning about what bvid identifies or how it relates to the requested subtitle transcript.

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 clear verb and resource ('Read official subtitle transcript') plus a useful scope qualifier ('official') and output trait ('with timestamps'). It does not explicitly distinguish the tool from siblings like whale_video, but the subtitle-transcript focus is specific enough for an agent to understand what it does.

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

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

The phrase 'requires login' provides an important prerequisite, but the description gives no explicit when-to-use guidance, exclusions, or alternatives such as whale_video for video metadata versus whale_subtitles for transcripts. Usage is implied by the name and purpose rather than stated as selection guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that — the login requirement, which an agent needs to anticipate auth failures — but it says nothing about what the upstream fetch returns or how the four data types are bundled.

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 and front-loads the resource list, but the closing sentence ('Text analysis is not proof of visually watching video') is cryptic and arguably irrelevant to invoking the tool, so the brevity reflects under-specification rather than tight writing.

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 one parameter, no output schema, and only a regex for bvid, the description should explain what a call returns and when to prefer it over the dedicated subtitle/comment tools. It instead stays generic and spends its one value-add sentence on an ambiguous caveat.

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

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

The single required parameter bvid has 0% schema description coverage, so the description carries the explanatory burden — but it never mentions bvid, its format, or that it is a Bilibili video ID. The schema's regex pattern is the only hint, leaving the description failing to compensate for the coverage gap.

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

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

The description names resources ('metadata, subtitles, danmaku and comment digest') but is a noun phrase with no verb, and it does not explain how this aggregate tool differs from siblings like whale_subtitles or whale_comments. An agent can infer it fetches video-associated content for a given video, but the scope boundary versus siblings stays murky.

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?

'May require login' offers a prerequisite, but there is no when-to-use/when-not guidance and no routing to alternatives such as whale_subtitles or whale_comments even though those siblings clearly overlap. The final sentence about text analysis is not usage guidance in any actionable sense.

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