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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds real value: it confirms the call never mutates state (no apply, no period extension, no new proposal) and gives a recovery pattern for lost responses. It does not say what the response contains or how an unknown/expired review_id behaves, which keeps it below 5.

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 read-only constraint and the recovery tip are front-loaded and each sentence earns its place. The English lead line duplicates the first Korean sentence almost verbatim, which is mild waste but does not obscure anything.

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 single-parameter read with rich annotations and no output schema, the definition covers what the call does, what it will not do, and the retry pattern. The one remaining gap is the shape of the returned result, which the description characterizes only loosely as 'the actual result' / whether the change was applied.

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?

There is one parameter with 0% schema description coverage; the schema only supplies a regex pattern, so the description must carry the semantics. It partially does by framing review_id as the handle to a specific change review that can be safely re-queried, but it never says where the id comes from (presumably prepare_consultation_change) or what an invalid id yields.

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 gives a specific verb (read/query) and resource (the result of a change review, i.e. whether the proposal was applied), which separates it from the prepare/apply/discard siblings through explicit negation ('does not apply, extend, or create'). It stops short of naming a sibling tool, so an agent must infer the routing from the negated actions rather than being pointed at apply_consultation_change directly.

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?

'After a lost response, query the same review_id first' is a concrete when-to-use rule that most definitions would omit, and the negation clause implicitly excludes the write siblings. There is no explicit 'when not to use' or named alternative for the apply path, so it falls short of a 5.

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