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

Annotations already declare destructive=true and openWorld=true, yet the description still adds real substance beyond them: 0.10 USDC per call with 10 shared free calls, a required signed wallet ownership proof on every call, immutable parties, EIP-712 policies, release-only-to-payee and refund-only-to-payer, a durable public log, and the fact that the adapter supplies no server credentials. It stops short of saying plainly that a release is irreversible and loses the principal, which is the one thing an agent most needs before a destructive call.

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 first thing an agent reads is the price and a wallet address, with the actual purpose buried in a third paragraph. The immutable-parties / EIP-712 / public-log points are repeated across two paragraphs, and 'escrow principal and API-fee wallet are separate' is restated almost verbatim. It is dense but badly front-loaded and redundant.

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 five-mode, deeply nested, high-value custody tool with no output schema, the description does convey the domain model, the funding-versus-fee split and who must sign. It still leaves the agent unable to complete a call: no mode-by-mode input contract, no description of what prepare/fund/release/refund return, and no guidance on assembling the mandate context object.

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 carries the full burden, and it explains no parameter at all. The five-valued mode enum that drives every branch is never documented, nor is idempotency_key, nor the three release_policy kinds (payer_signed, mutual, delivery_attestation) whose signature requirements differ. Vague phrases like 'signed release policy' add nothing to the nested schema an agent must actually populate.

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 operating-boundary paragraph states a specific verb and resource: create escrows with a fixed payer, payee, amount and expiry, fund with Base USDC, then release or refund. That is far more precise than the title alone. It never names a sibling (e.g. workorder-release, payout-execute, x402-payment-gateway), so an agent cannot tell from the description alone which of the ~50 neighbouring money tools this one replaces.

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 lifecycle is spelled out (create -> fund -> release-or-refund) and the human-in-the-loop boundary is stated explicitly: agents call the escrow tools while humans review and sign funding and release terms. That is useful implied usage guidance. There is no explicit 'when not to use this' and no routing to any alternative despite many overlapping payment siblings, and 'Work-order grants do not authorize payment' is the only negative boundary given.

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