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

Annotations only declare safety hints; the description carries substantial extra behavioral load: the paid path (0.10 USDC per call on Base via x402 exact, 10 signed-wallet free calls per rolling 30 days), the auth binding requirement (X-Wever-Wallet-Proof bound to the exact JSON arguments and tool route), and the fact that it makes no network, wallet, merchant or payment call. It also discloses the return artifact (report plus Ed25519 signed receipt) and the three verdict values. 'submit'/'POST' plus readOnlyHint=true is reconciled by the explicit 'no external write' sentence, so there is no contradiction.

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?

Purpose is front-loaded in the first sentence and the sibling routing, payment and auth constraints each earn their place. The prose is dense and somewhat fragmentary in places ('Assembly from the supplied state:', 'Verdict not_resumable, resumable_with_gaps or resumable.'), which costs some readability but not correctness.

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 an 11-parameter nested tool with no output schema, the definition supplies enough to call it: what to submit, cost, auth binding, what comes back and the verdict taxonomy, plus contract and human-page URLs. The remaining gap is that several optional inputs (deadline, budget_remaining, asset, label) are neither described here nor in the schema, so an agent must guess whether they affect the completeness verdict.

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 high (82%), so the baseline is 3, but the description adds real semantic meaning beyond field names: it explains that open items are ordered 'blocking questions, then steps after their dependencies', which gives an agent the intent behind blocking and depends_on rather than just their types. It does not cover asset, deadline, budget_remaining or label, which are equally undocumented in the schema, so it is not fully compensatory.

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 opens with a concrete verb+resource ('submit one half-finished job's state') and then enumerates exactly what that state consists of: objective, work product reference, completed steps, open questions, artifacts, decisions and what remains. It also names three siblings and states how this tool differs from each, so an agent can disambiguate without opening any schema.

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 routing is given: 'a supplied handover is wever_handover-check, continuity risk is wever_continuity-check and signed sender-to-recipient packs are wever_agent-to-agent-handoff-pack.' That is a genuine alternatives-with-conditions statement. What is missing is an explicit when-not-to-use beyond those alternatives (e.g. when the job is complete, or when no resumption is intended), so it stops short of a perfect 5.

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