list_review_states

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context of its own — nothing about pagination semantics, result limits, or interaction with the limit/offset parameters. Its content restates return values, which the output schema already carries, so it contributes little beyond the annotations.

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?

It is a single compact sentence with no wasted phrasing, which is good structure. But the brevity is under-specification rather than discipline — nothing is front-loaded because nothing beyond the bare purpose is provided.

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 five-parameter, zero-schema-coverage tool, the description is far too thin: it omits parameter meanings, filtering behavior, and any usage routing. The existence of an output schema excuses it from explaining return values, yet it spends its only sentence on return contents anyway, leaving the caller-facing gaps unfilled.

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 0% across five parameters, so the description must carry the burden and it does not. It only loosely implies that aspect_variant_ids selects the 'original aspect expressions' being queried, leaving query, product_ids, limit, and offset entirely unexplained in both schema and description.

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 names a clear verb (조회한다/retrieve) and resource (the state of selected original aspect expressions), and it enumerates the returned contents: status ID, review count, sentiment distribution, and examples. That is specific enough for an agent to know what the tool returns. It does not, however, distinguish this from siblings like find_review_attributes or get_review_evidence, which all operate in the same review-aspect space.

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, no stated alternatives, and no exclusions or prerequisites. The reader cannot tell from the text whether this is the right tool versus find_review_attributes or get_review_evidence. Only the required aspect_variant_ids hints at any precondition.

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