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

Beyond the annotations (readOnly, non-destructive, closed-world), it states the tool reads only the material in the call with no network request, fetch, money movement, message, sharing, configuration change or external write. It discloses the payment model (0.10 USDC per call on Base via x402 exact, 10 signed-wallet free calls per rolling 30 days), the required X-Wever-Wallet-Proof binding to the exact JSON arguments and tool route, and the Ed25519 signed receipt returned with the report. This is well beyond what the annotations carry and is exactly the auth/cost/side-effect context an agent needs before calling.

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 opening is front-loaded with the core action, but the second sentence is a very long run-on enumerating report outputs, and the tail piles on URLs, route, contract path and human page. Most sentences carry information, yet the same points (route, weverlabs.com) recur and the density hurts scanability. It could be tightened without losing meaning.

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 nested four-parameter tool with no output schema, the description covers input shape, output contents (per-term classification, limits crossed, fixed terms changed, silent drops, unlimited additions, fixes), the four verdict values, and cost/auth mechanics. What it does not do is define the operational meaning of each verdict, leaving an agent to infer e.g. counter_gaps versus counter_unverified from the names alone.

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 only 25%, so the description does real work: it explains that terms are recorded 'as written', that each mandate limit carries a term, a direction (at most, at least, exactly) and a value, and that 'fixed' lists terms that may not change. It also clarifies the value space that limits are evaluated against (amount, date, span, percentage, count, exact text). The optional 'label' parameter is left to the schema, which documents it, so the gap is minor.

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 action and resource: submit an original offer plus a counteroffer with the mandate limits it is read against, and receive a report classifying each term as kept, changed or added and each limit as crossed or not. It explicitly separates itself from three siblings (wever_contract-diff-check for two contract versions, wever_quote-compare for quotes, wever_negotiation-mandate-check for the mandate's own bounds). An agent can identify this tool without opening the 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?

It gives explicit routing: use wever_contract-diff-check when comparing two contract versions, wever_quote-compare for quotes on one job, and wever_negotiation-mandate-check for bounds alone, which by elimination defines when this tool applies. It also points to a worked sample (wever_negotiation-playbook-sample) for format guidance. Both the positive case and the alternatives are stated.

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