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

Beyond the readOnly/destructive/idempotent hints, the description discloses the payment model (0.10 USDC per call on Base via x402 exact, 10 signed-wallet free calls per 30 days), the required X-Wever-Wallet-Proof binding to the exact JSON and route, and the Ed25519 signed receipt. It also bounds the report's semantic power ('matches words, figures, dates and named items ... does not interpret meaning beyond that matching'), which is exactly the caveat an agent needs before relying on the output.

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 paragraph is dense with no filler sentences, and the core contract (inputs, computed mismatches, signed receipt) is front-loaded. It runs long and ends with low-value pointers (contract path, human page URL), but each substantive clause carries information.

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?

With no output schema, the description correctly explains what comes back (a report with deadlines in calendar or business days, mismatch list with days late and amount over, signed receipt). It omits error/validation behavior and currency-mismatch handling, which are the main remaining gaps for a two-object, nested-parameter tool.

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 description coverage is 67% and the nested fields (dispatch_within, delivery_within, delivery_by, cost, free_over, events, charged, order_total) are already documented inline. The description restates that list at a high level without adding formats, precedence rules, or defaults beyond what the schema says, so it lands at the baseline for partial coverage.

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 shipping promise ... and the delivery evidence') and states the output artifact ('signed report ... lists the dispatch, delivery and cost mismatches'). That distinguishes it from sibling write tools such as wever_boutique-record-shipment or wever_boutique-create-order without needing to open either 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 makes clear what the caller must supply (a promise plus order/dispatch/delivery evidence) and explicitly scopes it out from adjacent work: 'no page fetch, no account access, no merchant contact and no money movement.' It does not name an alternative tool or state the condition that should route an agent here over, say, a recording or dispute tool, so the guidance is contextual rather than routing-level.

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