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

Beyond the annotations, the description discloses the login requirement, the single-review-per-user-per-product rule, the idempotent edit-on-recall behavior, and the self-rating prohibition. These are meaningful behavioral details that the annotations alone do not convey, and they align with idempotentHint=true and destructiveHint=false.

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 entire description is one dense, purposeful sentence. It front-loads the core action and includes only high-value constraints and prerequisites, with no repetition of schema 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 tool with no output schema and only three parameters, the description is complete: it covers authentication, usage constraints, idempotent behavior, and how to obtain the required productId. Nothing critical for a correct first call 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 description coverage is 100%, so the schema fully documents all three parameters. The description adds slight context by linking productId to get_product / search_products and confirming body is optional, but does not go beyond the schema in a substantial way.

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 specifies the action: rate a product with 1–5 stars plus an optional text review. The phrase '一人一产品一条，再次调用即编辑' (one per person per product, calling again edits) distinguishes it from sibling rating-related tools like delete_my_rating and get_product_ratings.

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 provides explicit prerequisites and constraints: requires login, cannot rate your own product, and must obtain productId via get_product / search_products first. It does not explicitly mention when to avoid this tool in favor of an alternative, but the guidance is clear enough for correct invocation.

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