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

The annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the safety profile is partly covered. The description adds useful context with 'No Parser credits' and the queue-handoff note, but 'settle unconfirmed saved-run queue handoff' is opaque and does not clarify what gets changed or destroyed despite the destructive annotation.

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 short and front-loads the progress-check concept, but the second clause is dense jargon and the billing note is unexplained. It is concise in length, yet the fragmented phrasing makes the operational intent harder to parse.

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?

This is a destructive, non-read-only operation with no output schema and a cryptic description. An agent needs more context about what 'settle' means, what state is altered, and what the result indicates, especially given destructiveHint=true.

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%, so both required parameters (id and runId) are documented in the schema. The description adds no additional meaning about how those IDs are used or any constraints on them, so the baseline of 3 applies.

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 actions ('check re-read progress' and 'settle... queue handoff'), but it never identifies the resource as a contract reprocess run or explains what that run represents. An agent must infer the scope from the tool name rather than the description, and it is not clearly distinguished from related tools such as clm_reprocess_contract_document or clm_get_contract_type_reread.

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 explicit guidance on when to call this tool versus the many sibling contract tools. It implies a progress-check use case, but does not say when the 'settle' behavior is needed, when it should be avoided, or what alternatives exist.

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