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

Annotations only declare destructiveHint=true, so the description carries real weight and delivers: 'This never publishes anything' scopes the blast radius of an otherwise alarming destructive hint, 'Free; requires the act scope' discloses cost and authorization, and 'exactly as read' signals optimistic-concurrency semantics. It does not say what happens when the expected state no longer matches, which is the main remaining behavioral gap.

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?

Front-loaded with the action and only three short sentences, each carrying distinct information (what it does, what to pass, safety/cost/scope). The first sentence is a long nested clause that takes a second read, which is the only drag on structure.

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 destructive, 9-parameter mutation with no output schema, the definition covers the essentials an agent needs before calling: the precondition, the exact values to echo back, that nothing is published, and the scope/cost. What is missing is the failure mode on a stale expected state and any hint of what the call returns, which the absent output schema would otherwise have supplied.

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 only 11% across 9 parameters, so the description must compensate, and it largely does: it maps prepared_content/asset_url as the inspected payload and explains that the expected_* fields are the move's (and its job's) state and updated_at passed verbatim, which reveals their concurrency-check purpose rather than just restating the names. It leaves move_id and the free-text note unexplained, and 'and its job's, if any' is slightly ambiguous about which parameters belong to the job.

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?

States a specific verb (apply user's decision to keep) and a specific resource (pre-legacy prepared work with no attempt id), and the parenthetical '(it has no attempt id)' is precisely the trait that separates it from the tracked-attempt siblings such as accept_move. It stops short of naming the sibling it replaces, but the discriminating condition is explicit.

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 precondition is unambiguous: only when the user has made an explicit decision, and only for work prepared before AfterLaunch tracked attempts. That gives a clear context for use without spelling out an exclusion rule or naming accept_move as the alternative path.

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