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

Annotations already cover the safety profile (readOnlyHint true, openWorldHint false, destructiveHint false), yet the description adds substantial context beyond them: no page fetch, no account access, no merchant contact, no money movement, matching is literal rather than interpretive, and a report carries an Ed25519 signed receipt. The pricing and auth mechanics (0.10 USDC per call on Base via x402 exact, 10 free signed-wallet calls per rolling 30 days, X-Wever-Wallet-Proof bound to exact JSON arguments and route) are disclosed, which explains why idempotentHint is false. This is genuinely additive behavioral disclosure.

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 purpose and payment terms are front-loaded in a single paragraph, which is good, but the text is a dense run-on that packs purpose, matching semantics, payment mechanics, auth binding, receipt format, contract path and human page into one block. Every element is relevant, yet the lack of sentence breaks makes the operative routing information harder to extract quickly.

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 carries the burden of describing results and does so: the report lists differing prices, limits and features with quotes, and includes an Ed25519 signed receipt. Inputs, cost, authentication binding, reading scope and matching limitations are all covered, so nothing an agent needs to call it correctly is missing.

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 100%, so the baseline is 3, but the description goes further by explaining how the tool classifies what it finds: a limit can be 'another figure, or a cap on an unlimited one', and a feature can be 'excluded, a paid add-on, or named for another tier'. That interpretive framing, plus the text-or-structured-tiers alternative for the main input, adds meaning the schema alone does not convey.

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 gives a specific verb and resource: submit a pricing page's tier descriptions plus plan terms and receive a signed report of price, limit and feature differences. The scope is precise enough that an agent can tell it apart from a generic evidence check. It does not, however, distinguish itself from the near-neighbour sibling wever_pricing-evidence-check or wever_terms-evidence-check, which an agent may confuse it with.

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?

Usage is implied rather than stated: the agent is told what to submit (page tiers as text or structured tiers, plus terms) and that the tool reads only the submitted material, which implies 'use when you already hold both texts'. There is no explicit when-not guidance and no named alternative for cases where the agent has a URL instead of text, leaving routing to inference.

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