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

With empty annotations, the description carries the burden, and it does disclose key behavior: status is always available, 'following'/'favorites' are auth-gated and return an honest requires_login state instead of failing opaquely. It also states the return envelope. It stops short of side-effect or rate-limit detail, but for account lookup operations this is sufficient.

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 compact and organized: one-line summary, rationale, return format, and examples. The rationale is slightly meta but earns its place by justifying the operation-discriminator design; no filler sentences are present.

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?

It covers the return shape, examples, and per-operation auth behavior, which is enough to call the tool correctly in most cases. The main gap is the mid parameter's exact effect for the status operation, and the data fields inside each operation's response are not detailed beyond the generic output schema.

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

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

Schema coverage is 100% and the operation parameter already has a detailed description covering enum semantics and the login caveat; the tool description adds useful examples but not much new parameter meaning. The mid parameter remains somewhat under-explained beyond 'only for status'.

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 line names the resource ('account-tier') and lists the three concrete operations: tier status, following feed, favorites. It is distinct from sibling bilibili_explore/search/video tools, though it lacks a crisp verb like 'gets' or 'lists' in the summary line.

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 operation descriptions give clear per-operation guidance: status works always, while following and favorites require a logged-in +86 account and otherwise return a requires_login state. However, there is no explicit when-to-use-this-vs-alternatives statement, so the tool relies on the account domain being self-evident.

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 are empty, so the description carries the full behavioral disclosure burden. It does so by stating the return format, indicating that all operations share a single video-ish list output, and providing invocation examples. It does not discuss auth or side effects, but for a read-only trending/discovery tool this is a minor 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?

The description is well-structured and front-loaded with the core purpose, followed by a concise rationale, return format, and examples. Every sentence adds value and there is no redundancy or 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?

The schema fully documents parameters, and the description supplies the return format plus representative examples for all three operations. An agent has enough context to select the right operation and correctly interpret the response without additional unwritten requirements.

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 input schema already covers all parameters at 100%, including the operation enum with detailed semantics, rid region mappings, and limit bounds. The description adds useful examples but no new parameter-level meaning beyond what the schema already provides, 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 clearly states what the tool does: discover trending content on Bilibili via three list surfaces. It specifically names popular feed, rankings, and hot keywords, and the operation enum reinforces the scope. It does not explicitly differentiate from sibling tools like show_bilibili_trending_card or bilibili_search, so it falls just short of a 5.

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

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

The description and examples make it clear how to invoke each operation (trending, rank, hot_search), and the rationale frames this as the discovery surface. However, it never directly tells the agent when to choose this tool over alternatives such as bilibili_search or show_bilibili_trending_card, so the guidance is implied rather than explicit.

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 no annotations, the description carries the full transparency burden. It helpfully discloses the return envelope (success, data.help, data.tools, message) and provides invocation examples, but it does not explicitly state that the tool is read-only, static, or whether invalid topics produce errors. That leaves some behavior to inference.

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 tightly structured: one clear purpose sentence, a terse return format block, and two concise examples. There is no filler, and the central purpose is front-loaded before the technical details.

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 help tool with one optional parameter and an existing output schema, the description is nearly complete: it provides the purpose, return structure, and examples. It could optionally list all valid topics, but the schema already supplies representative examples, so nothing critical 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?

The input schema already documents the optional 'topic' parameter with a default and examples, and schema coverage is 100%. The description's examples like topic='transcript' reinforce usage but add little semantic value beyond the schema, 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 clearly states a specific verb ('Explain') and resource ('how to use the bilibili-mcp server'), making the tool's meta-role obvious. It implicitly distinguishes itself from all sibling tools, which perform bilibili domain operations rather than server help.

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 clear context: this tool is for explaining how to use the bilibili-mcp server, and the examples show how to invoke it. It does not explicitly state when-not to use it or name alternatives, but no sibling tool overlaps with this help purpose, so context is sufficient.

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 the return envelope and gives concrete call examples, which is useful. However, with empty annotations, the top-level description itself does not mention potential Bilibili risk-control blocks, cookie requirements, or retry behavior; that information appears only in the schema's operation description.

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?

Compact and well-structured, with a front-loaded purpose, a clear return-format block, and two grounded examples. Every section 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?

For a three-parameter search tool with schema-documented parameters and an explicit return format, this is nearly complete. The main gap is the absence of sibling-tool routing guidance.

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 all three parameters, so the schema already explains operation, keyword, and limit. The examples add practical usage context but no new parameter semantics.

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 clear verb and scope: 'Search Bilibili for videos or creators' and the operation enum distinguishes video vs user search. It does not explicitly differentiate from siblings like bilibili_explore, so it falls short of a 5.

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

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

Examples show supported operations and the user-search target is clear, but there is no explicit when-to-use vs when-not-to-use guidance, nor any mention of sibling tools like bilibili_explore or bilibili_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?

With no annotations, the description carries the behavioral burden. It states the server will be stopped and provides the return format, but it does not mention side effects or irreversibility. The confirm parameter is defined in the schema rather than elaborated in the description.

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 compact and front-loads the core purpose in the first sentence. The return format and example are brief, useful additions with no filler.

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

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

The tool has a single parameter, a complete input schema, and an output schema. The description covers purpose, return shape, and a concrete invocation example, leaving nothing essential missing for an agent 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 coverage is 100%, so the confirm parameter is already fully documented as 'Must be True to shut down the server.' The description adds only a usage example, which reinforces but does not significantly expand the schema's semantic content.

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 clearly identifies the action as 'gracefully stop' and the resource as 'the bilibili-mcp server.' This is unique among sibling tools, which are all content/account operations, so there is no ambiguity about what the tool 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 intended use is implied by the description: call this when you need to shut down the bilibili-mcp server. No explicit when-not-to-use or alternative tool guidance is provided, but no sibling tool performs shutdown, so the routing is straightforward.

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 no annotations present, the description carries the full behavioral disclosure burden. It discloses that transcripts are auto-generated, returned as plain text, and that missing or login-required subtitles result in an honest, actionable error rather than an empty response. It also provides the exact return shape and example invocations, making behavior predictable.

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 front-loaded with the core action and use case, then compactly presents return format and examples. Every section serves tool selection or invocation, with no filler or redundant 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?

For a two-parameter fetch tool with an output schema, this covers purpose, accepted argument forms, multi-part behavior, failure mode, and return shape. The examples and error-handling note close the practical gaps an agent would face when calling the 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 input schema already documents both parameters with 100% coverage, so the baseline is 3. The examples illustrate URL-form bvid and part_index usage, but they do not add new semantic meaning or edge-case detail beyond what the schema already 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 opening sentence states a precise action: fetch a video's auto-generated subtitle track as plain text. This clearly distinguishes it from siblings like bilibili_video or show_bilibili_trending_card, which are about video metadata or status rather than transcripts. The return format block reinforces exactly what the tool produces.

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

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

The description implies usage when an LLM needs transcript text for summarisation or translation, and warns about videos without subtitles. However, it does not explicitly name alternative tools or state when not to use this tool, so an agent has to infer selection from the purpose rather than being handed an explicit routing rule.

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 are empty, so the description carries the full burden. It does disclose the return envelope and gives representative calls, but it does not mention authentication needs, error behavior, rate limits, or operation-specific preconditions such as the comments operation's dependency on the video aid. These are left to the schema or left implicit.

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 compact, front-loads the purpose, and uses examples effectively. The return-format block is mildly redundant with the stated output schema, but it is short and does not significantly bloat the definition.

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 the rich input schema and existence of an output schema, the description provides enough to understand the core behavior and how to invoke each mode. The main gaps are explicit sibling differentiation and higher-level behavioral caveats such as error handling and authentication, but these are not critical for a straightforward read-only inspector.

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 aid, bvid, limit, and operation. The description adds only example calls, which illustrate valid parameter combinations but do not convey new meaning beyond the input 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 sentence states a specific action ('Inspect'), a specific resource ('a single Bilibili video'), and enumerates the three data categories: metadata, comments, or part list. This distinguishes it from sibling tools like bilibili_search, bilibili_explore, and bilibili_account by clearly scoping it to inspecting one video.

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

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

The examples show how to invoke each operation, and the schema operation descriptions add mode-level guidance such as 'comments needs the video aid' and 'pages returns the multi-part page list'. However, the description never explicitly says when to prefer this tool over alternatives like bilibili_transcript or bilibili_search, or when not to use 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?

With empty annotations, the description carries the full burden of disclosing side effects. It says 'clear' early on but never explains whether invoking the tool clears the cache, under what conditions, or whether that is reversible; the status-surface rationale even conflicts with the destructive verb.

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 brief, uses helpful headings (RATIONALE, Return Format, Examples), and front-loads the action. The example line is somewhat redundant but harmless.

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 return format is specified, but the core ambiguity about whether a call can clear the cache is not resolved anywhere. An agent cannot safely predict the tool's side effects from this definition, which is a critical gap even for a zero-parameter 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 has zero parameters and the schema already defines an empty object, so there is nothing for the description to add. Per the zero-parameter baseline, this is adequately covered.

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

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

The first sentence names a specific resource ('Bilibili response cache') and two actions ('Show and clear'), but the rationale describes only a 'tiny status surface', making it unclear whether this tool is read-only or destructive. It also does not distinguish itself from the sibling 'show_bilibili_status_card'.

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 rationale provides a concrete use case: debugging rate-limit staleness. However, it does not mention when to prefer this tool over similar status/display siblings or state explicit exclusions.

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?

Discloses return format: ToolResult with plain text fallback plus structured PrefabApp card, and lists the status dimensions shown. With no annotations, this gives the agent concrete behavioral expectations. It stops short of covering edge cases or failure behavior, so not a 5.

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

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

The purpose is front-loaded and the return-format note is useful, but the RATIONALE and Examples sections are essentially padding for a zero-param tool; the example only repeats the call name. It is reasonably short but not every sentence 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?

For a zero-param status card it covers the core purpose and return format, which is most of what an agent needs to invoke it. However, it lacks guidance on when to choose this over sibling status/cache/trending cards and doesn't mention behavior when configuration is missing or incomplete.

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 has zero parameters and the schema covers this completely, so there are no parameter semantics for the description to add. The 0-param baseline of 4 applies; the description correctly avoids inventing parameter details.

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 clearly states the tool 'Show bilibili-mcp configuration status as a rich in-chat card' and names the concrete contents: tier, cookie state, and cache headroom. This is a specific verb+resource that distinguishes it from sibling tools like show_bilibili_cache_card or show_bilibili_trending_card.

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 or comparison with alternatives. The RATIONALE is a design mandate about shipping a Prefab surface, not practical advice for choosing this tool over sibling status/cache/trending cards, so the agent receives no selection criteria.

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 no annotations, the description carries the full behavioral burden. It discloses the return format (ToolResult with plain-text fallback plus a structured PrefabApp card) and notes that the card renders the feed without the agent reading raw JSON. It does not cover errors, rate limits, or authentication, but these are less critical for a read-only trending tool.

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

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

The main action is front-loaded and the Return Format/Examples sections are useful. However, the RATIONALE block contains internal jargon ('per fleet SOTA') that does not directly help an agent select or invoke the tool, so not every sentence 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?

For a tool with one optional parameter, no output schema, and no annotations, the description covers the essential ground: what it does, how it returns results, and a concrete invocation example. It could add sibling routing and more detail about limit semantics, but an agent can call it correctly with the information provided.

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 example 'show_bilibili_trending_card(limit=5)' illustrates how to pass the optional parameter, but the description does not explicitly explain that 'limit' controls the number of trending items returned. The schema provides the type and default, and the parameter is self-explanatory, so the gap is minor.

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 clearly states the tool's function: show current Bilibili trending content as a rich in-chat card. This is specific enough to distinguish it from siblings like bilibili_search or show_bilibili_status_card, though it does not explicitly name those 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 purpose implies when to use the tool: when a user asks what is trending on Bilibili right now. However, there is no explicit guidance about when not to use it or which sibling tool to prefer for other intents, such as search or account status.

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