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

Well beyond the annotations, the description discloses that no network request, fetch, money movement, external write, or data movement occurs, that the report carries an Ed25519 signed receipt, and that the paid endpoint costs 0.10 USDC per call on Base via x402 with 10 signed-wallet free calls per rolling 30 days. It also names the auth mechanism (bind X-Wever-Wallet-Proof to the exact JSON arguments and route) and enumerates the verdict values, which are exactly the operational facts an agent needs before spending money on a 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 core specification is delivered as one enormous run-on sentence stitched together with semicolons, burying the tool's purpose, the defect logic, the routing, the cost and the contract link in a single block. The pricing and auth details, which are highly actionable, only surface near the end. The content is largely worth keeping, but the structure makes it expensive 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?

For a tool with nested objects, four verdicts, a signed receipt and a paywall, the description covers the major unknowns: the verdict vocabulary, the shape of the returned report (return path, its window, early-closing steps, permanent steps with status), payment and wallet-proof requirements, and where the contract and human docs live. Without an output schema this is doing necessary work; only the exact report field layout is left unpinned.

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 67%, so the schema carries much of the load, but the description adds evaluation meaning rather than restating: it explains what the checker looks for in presented_as, exists, window, cost and rehearsed, and flags the specific defect pattern — a move presented as reversible with no written way back, or a permanent step landing before the return window closes. That interpretation of the nested fields (including kinds like source data deleted or key revoked relative to days_after_cutover) is genuine value the schema alone does not convey.

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 a specific verb and resource — submit a return-path assessment for one agent migration move, covering the return path, irreversible steps, or both — and the closing verdict list (return_path_closed, return_path_gaps, return_path_unverified, return_path_open) makes the output concrete. It is distinguishable from siblings, but the opening clause ('submit whether one move can be reversed, as its return path, the steps that cannot be undone, or both') is grammatically tangled and forces a re-read.

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?

Explicit sibling routing is present: wever_rollback-path-check is named for the general rollback path of one action's external effects, and wever_kill-switch-check for halting a running agent system, which tells the agent when this tool is the wrong pick. What's missing is a positive cue for when this tool itself is the right call (e.g. pre-cutover planning versus post-cutover audit), so usage is implied by the field set rather than stated.

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