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

Annotations already state non-destructive, idempotent, and not read-only, so the bar is lower. The description still adds genuine content beyond them: it discloses that the tool produces an owner-review draft rather than an immediate outcome, and it explicitly rules out payment and dispatch. It does not describe what state changes occur to the view or what happens if the revision is stale.

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?

Roughly 25 words, tight, and front-loaded with the three action modes before the constraints. The imperative 'Retain the exact view, revision and retry key' is slightly compressed to the point of ambiguity about which values must be carried over.

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 non-read-only mutation with five required parameters, zero schema description coverage, a free-form nested input object, and no output schema to explain results. The description covers the action modes and one safety boundary but leaves the input payload contract, revision-conflict behavior, and success/return semantics entirely unaddressed, which is too thin for this complexity.

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 only partly does: 'retain the exact view, revision and retry key' loosely signals view_ref, expected_revision, and idempotency_key must be passed through unchanged. The required `input` object is completely opaque (typed object, additionalProperties=false, no properties defined), and the description gives no hint of its shape or how it varies per action_id. Two of five parameters, including the only nested one, are effectively undocumented.

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 three concrete actions (select an offered option, prepare an owner-review draft, resume after owner approval) that map onto the action_id enum, and it identifies the resource as an app view action. The 'Never pays or dispatches' line separates it from siblings such as evuun_delegated_pay. It loses a point because 'its' and 'the view' are never defined for an agent unfamiliar with this surface.

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 negative boundary ('Never pays or dispatches') implicitly steers payment work toward evuun_delegated_pay, and 'resume after owner approval' indicates a sequencing precondition. However, no sibling is named and there is no guidance on when to pick this versus evuun_app_open or evuun_app_prepare_plan, so selection still requires inference.

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