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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description reinforces this with concrete specifics: 'Reads only the material in the call: no network request, fetch, money movement, message, sharing, configuration change or external write.' It goes further with cost and auth mechanics an agent cannot get from annotations — 0.10 USDC per call via x402 exact, 10 signed-wallet free calls per rolling 30 days, and the X-Wever-Wallet-Proof binding to the exact JSON arguments and route. It also discloses that the response carries an Ed25519 signed receipt.

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 description is a single run-on sentence of roughly 200 words that chains the entire input enumeration and every failure condition into one string of clauses. The information is relevant, but the lack of sentence breaks or grouping makes it hard to parse and the defect list ('names no authorizer, no limits, no price limit, limits with no value...') reads as an undifferentiated wall. Only the trailing operational sentences (pricing, proof binding, contract link) are cleanly separated.

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?

There is no output schema, and the description compensates by describing the report's content and the four verdicts (mandate_unbounded, mandate_gaps, mandate_unverified, mandate_bounded). For a nested-object validation tool with 7 parameters, it covers the input space, the failure taxonomy with 'the fix for each', the auth requirements, the cost, and where the contract lives. Nothing an agent needs to call this correctly is absent.

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 71%, so baseline 3, and the description meaningfully exceeds it: it expands the evidence enum as 'signed, written, a message, spoken or not at all' and direction as 'at most, at least or exactly', and explains walk_away as 'whether reaching it ends the negotiation'. It maps the mandate object (agent, principal, authorizer, authorization time, deal, expiry) and the escalation field ('who decides beyond the mandate'). The 'label' parameter is not mentioned at all, which keeps this from a 5.

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 the resource precisely (a negotiation mandate) and makes the checking behavior clear through 'The signed report says limit by limit and term by term whether the agent is bounded and whether the mandate is in force.' It also separates itself from adjacent tools (delegation-scope-check, authority-scope-check, delegated-authority). The only weakness is the opening verb 'submit one negotiation mandate', which frames it as a submission rather than a check, so the purpose lands slightly later than it should.

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 explicitly routes adjacent cases elsewhere: 'One delegation's scope is wever_delegation-scope-check, access against an authority grant is wever_authority-scope-check and issuing a signed mandate is wever_delegated-authority.' That gives an agent a clear boundary for when not to call this tool. What's missing is a positive trigger statement ('use this before negotiating when...'), so the when-to-use is inferred from the subject matter.

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