Skip to main content
Glama

bili_comment_replies

Expands a Bilibili root comment’s reply page with complete IDs and context for up to 20 replies, helping agents inspect threaded comment discussions without claiming full history.

Instructions

Expand one root comment's reply page with complete IDs/context; up to20. No full-history claim.

Input Schema

NameRequiredDescriptionDefault
numNo
bvidYes
pageNo
rootYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden, and it does disclose two real behavioral traits: a cap of up to 20 items and the caveat that results are not a full history. It says nothing about auth needs, rate limits, or ordering, but the bounded-pagination disclosure is genuine added value that the schema and annotations do not supply.

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

Conciseness4/5

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

Two short clauses with no filler, and the scope constraint ('one root comment') is front-loaded ahead of the limit caveat. The telegraphic style is compact but borders on under-specification rather than verbosity.

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

Completeness3/5

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

An output schema exists, so return-value explanation is not required and the 'complete IDs/context' note is appropriately short. What is missing is any statement of the relationship to sibling comment tools and what 'bvid' selects, leaving the agent to infer how this slots into the comment workflow.

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

Parameters3/5

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 compensate. It meaningfully clarifies three of four parameters in passing: 'root' (one root comment), 'page' (reply page), and 'num' ('up to 20'). 'bvid' is never mentioned, though its meaning is conventional. Partial but useful compensation given the bare schema.

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

Purpose4/5

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

The description names a specific verb and resource: expanding one root comment's reply page, with full IDs and context. It implicitly distinguishes this from the sibling bili_comments (which would list top-level comments), though it never names that distinction explicitly. Slightly telegraphic phrasing ('complete IDs/context') leaves the exact payload a bit fuzzy.

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

Usage Guidelines2/5

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

'No full-history claim' implies paginated, bounded retrieval, and 'one root comment' implies the input scope. However, there is no explicit guidance on when to choose this over bili_comments or bili_comment_context, no prerequisites, and no exclusions. The agent must infer the selection criteria from the sibling names alone.

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