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

Goes well beyond the annotations: it discloses the paid URL price (0.10 USDC on Base via x402 exact), the 10 signed-wallet free calls per rolling 30 days, the X-Wever-Wallet-Proof binding to the exact JSON arguments and route, and the Ed25519 signed receipt. It also bounds the semantics honestly, saying the report matches words, figures, dates and named items and does not interpret meaning beyond that matching, and it enumerates what it does not do (no page fetch, no account access, no merchant contact, no money movement).

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 purpose and output shape are front-loaded, then scope limits, then pricing and auth, then caveats — a sensible order. It is dense and packs several concerns (payment, wallet proof, contract link, marketing URL) into one paragraph, but nearly every clause carries operational information an agent needs.

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 return-value burden and does so: verdicts per claim, the standard/type/level stated instead, validity dates before the check date, quotes, and a signed receipt. Combined with the disclosed pricing and auth requirements, an agent has enough to call this correctly and interpret the result.

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 claims, evidence and format are already fully documented, including splitting rules and size caps. The description reinforces the claim/evidence pairing but adds no syntax, format or validation detail beyond the schema. Baseline 3 is appropriate where the schema does the heavy lifting.

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?

States a specific verb and resource: submit certification/compliance/license claims plus their evidence, and receive a signed report marking each claim supported, contradicted or never mentioned. The verdict vocabulary and the named standards (ISO 27001, SOC 2 Type II, PCI DSS) make the operation concrete. It stops short of naming the nearest siblings such as wever_license-evidence-check or wever_terms-evidence-check, so an agent must infer the boundary itself.

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 by the framing ('DiligenceOps: submit ... claims and the evidence offered for them') and by the scope note that it reads only the material in the call, which tells the agent it need not fetch pages. There is no explicit when-to-use versus when-not guidance and no routing to the many sibling *-evidence-check tools, which is a real gap given how many near-identical checks exist.

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