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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety. The description adds valuable behavioral context: pagination semantics (token must be passed back unchanged, no truncation), the requirement to use the exact next_page_token, and the exclusion of root_review_id. It doesn't cover error handling or invalid tokens, but given annotation coverage, 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 a single, dense sentence that front-loads the purpose and then covers usage, token handling, and exclusions. It is efficient with no filler, though slightly run-on. The key information is packed clearly.

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 tool's complexity (pagination with token integrity) and the presence of an output schema, the description covers all necessary usage aspects: purpose, ID sourcing, pagination protocol, and parameter exclusions. 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 coverage is 100% with both parameters documented. The description adds meaning beyond schema: it specifies the source for review_id (from xhs_get_product_review_replies) and the token integrity requirement (must be passed back unchanged). This enriches the parameter semantics beyond the schema descriptions.

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 (获取/get), resource (商品评价回复的嵌套回复/nested replies of a product review reply), and key parameter (review_id). Clearly distinguishes from sibling xhs_get_product_review_replies by specifying it retrieves replies to a reply, not top-level replies. Also explicitly excludes root_review_id, reinforcing scope.

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?

Explicitly states when to use: if review_id is available, use directly; otherwise obtain it from xhs_get_product_review_replies. Names the exact sibling tool as the source for the required ID. Also provides pagination instructions (pass next_page_token back as page_token) and a negative constraint (does not accept root_review_id). These guidelines leave no ambiguity about when and how to invoke.

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