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

The description adds real behavioral context beyond the annotations: the change is prepared but not applied, the user must give explicit consent, and the agent must follow the returned next_action. However, annotations declare readOnlyHint=false and idempotentHint=false, and the description never explains that a preparation record persists and can be cancelled or discarded (siblings cancel_consultation_preparation / discard_consultation_change exist) — that residual gap keeps it at 4 rather than 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 English one-liner front-loads the essential distinction, and the Korean sentences each carry operational content (prerequisite lookup, edit/withdraw field rules, quoting rule, confirmation flow). It is dense but not padded; the bilingual duplication costs a little density but not enough to drop below 4.

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?

There is no output schema, and the description compensates by explaining the key returned field (next_action) and its two enum values with the required follow-up for each. It stops short of describing what the preview payload itself contains or what an infeasible change returns, which would be needed for a full 5 on a mutation-adjacent tool.

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?

With 0% schema description coverage the description must carry the load, and it does for the conditional fields: for edit, summary/category/stage must be supplied and after.summary quoted; for withdraw, all three are omitted and before.summary is quoted verbatim. It does not explain request_id (format) or revision (the 'current version' it tells the agent to fetch first) beyond implication, so it falls short of complete coverage.

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 opening sentence states a specific verb and resource ('prepare an edit or withdrawal preview') plus the critical qualifier 'without applying it', which immediately separates it from apply_consultation_change. The Korean body reinforces scope by naming the two change modes (edit/withdraw) explicitly.

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?

It states the triggering condition (user requests a modification/withdrawal of a submitted consultation), a prerequisite step (check feasibility and current version first), and the exact downstream routing: after explicit consent call apply_consultation_change, or guide the user to the confirmation link when next_action is confirm_on_web. Both branches of the returned next_action are spelled out, leaving little to inference.

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