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

Beyond the annotations (readOnly, non-open-world, non-destructive, non-idempotent), it discloses the resource profile ('no network request, fetch, money movement, message, sharing, configuration change or external write'), the pricing model (0.10 USDC per call on Base via x402 exact, 10 signed-wallet free calls per rolling 30 days), the auth binding (X-Wever-Wallet-Proof bound to the exact JSON arguments and tool route), and that the result carries an Ed25519 signed receipt. That is substantial context annotations cannot express.

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 content is front-loaded correctly — purpose first, then report behavior, siblings, verdict, endpoint, cost, return. However, the body is a single sprawling run-on sentence with long comma-chained enumerations that make it hard to scan, and the pricing/auth block is buried at the end rather than set apart.

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-object submission tool with no output schema, the description covers what gets submitted, what the report inspects, the four possible verdicts (trail_broken, trail_gaps, trail_unverified, trail_complete), the cost and auth requirements, and where the contract lives. It does not name the report's field structure, but with the verdicts and check list stated, an agent has enough to call and interpret it.

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 50% on a deeply nested object, so the description must compensate, and it largely does: it explains that an offer carries its maker, its time, the offer it answers and its terms, and that the agreement carries the offer it accepts, agreed terms and the parties that confirmed it. The optional 'label' parameter is never mentioned, which is the one gap.

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 specific verb and resource ('submit one negotiation record') and immediately enumerates the record's contents: parties with ids/roles, offers with id, maker, timestamp, responds_to and terms, and the agreement with time, accepted offer, terms and confirming parties. It then states precisely what the signed report does ('reads the trail from the first offer to the agreement and says whether the agreement matches a recorded offer term for term'). An agent can distinguish this from record-check siblings 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?

It explicitly routes three other record types away ('An approval record is wever_approval-record-check, a buyer's record of paid calls is wever_purchase-record-check and delegation records are wever_delegation-record-check'), which is real when-to-use guidance. It does not differentiate against the many other negotiation-* analyzers (terms, counteroffer, fairness, mandate), leaving the agent to infer that this one validates a whole negotiation record rather than a single dimension.

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