bili_comment_action_status

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

With zero annotations the description carries the full burden, and it does real work: it discloses that the readback is optional, bounded and anonymous, that it can discriminate accepted/review/visibility, and that absence within one page means unknown rather than failure. The "Never resend" directive is exactly the caution an agent needs after a partial result, though it doesn't state whether this call has rate limits or auth requirements.

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 clauses, front-loaded with the purpose and followed by the option and the imperative warning. It is efficient, but the telegraphic phrasing of "absent in one page stays unknown" costs clarity for brevity.

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 spelled out, and the description covers the key semantics of partial/unknown results. What is missing is where action_id comes from and the explicit sequencing with bili_comment_send, which matters for a status-polling tool.

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

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

Schema coverage is 0%, so the description must compensate. "Optional bounded anonymous readback" does map to check_visibility and even hints at an anonymity property and a bound on the readback, but action_id (the required parameter) is never explained — its origin from a prior send is left implicit.

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?

"Read durable send status" gives a verb (read), a resource (send status) and a notable trait (durability), but never names the comment domain or ties itself to a prior bili_comment_send action. Against siblings like bili_dm_action_status and bili_account_action_status, the description alone gives no basis for discrimination — only the tool name 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?

It supplies a hard negative ("Never resend") and frames check_visibility as optional, which implies use after a send rather than instead of one. It never states the trigger condition (e.g. "call after bili_comment_send returns pending") or names an alternative tool, so the agent must infer the call site.

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