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

Beyond the annotations it discloses retry semantics ('a repeated request_id is treated as a retry of the same request'), the per-installation gate ('the start runs only after the matching installation has fresh verified callbacks'), the auth/feature prerequisites (paired server key, approval and execution features), and explicit non-behaviors ('sends nothing now, bypasses no checks'). Annotations give the safety profile; the description gives the operational contract.

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, then prerequisites, then exclusions; six dense sentences with little repetition. A few clauses are packed (the scope/key/feature sentence) but nothing is wasted for a destructive, multi-constraint tool.

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?

With no output schema and 0% parameter coverage, the description covers preconditions, gating, idempotency and exclusions well enough to call the tool safely. It leaves the digest/revision semantics and any post-call state expectation to inference.

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%, so the description must carry the load, and it does name all five inputs and pin required values for confirmed and customer_confirmation.scope, plus the identification triple and request_id retry meaning. It does not explain what revision or digest actually represent (e.g. the 64-hex plan hash), leaving some semantic gaps.

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 states a precise compound verb+resource: it records approval of an unchanged conversion plan proposal AND records one start request, identified by revision/digest/request_id. That distinguishes it in substance from approve_conversion_plan (approval only) and stage_conversion_installation, but no sibling is named explicitly, which is the 5-level criterion.

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 gives explicit preconditions for use ('after the customer explicitly accepted that scope in chat', requires confirmed:true and customer_confirmation with scope approve_and_start_after_checks) and negative conditions ('does not resume a paused, revoked, changed or restaged installation'). It stops short of naming the alternative tool to call when you want approval without a start request.

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