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

Annotations already cover the safety profile, yet the description adds substantial context they cannot carry: paid pricing at 0.10 USDC per call on Base via x402 exact, a shared quota of 10 signed-wallet free calls per rolling 30 days, and the requirement to bind X-Wever-Wallet-Proof to the exact JSON arguments and route. It also declares an important epistemic limit — matching of words, figures, dates and named items without interpreting meaning — plus the Ed25519 signed receipt, so an agent knows both the cost and the trust boundary.

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?

Purpose is front-loaded in the first sentence, followed in a sensible order by report contents, side-effect exclusions, payment/auth, and return shape. The density is justified for a paid, wallet-authenticated call, though the trailing contract route and human page URL contribute little to tool selection and could be trimmed.

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 supplies the return contract itself (signed report plus Ed25519 receipt) and explains what the report asserts. Combined with the side-effect exclusions, payment terms, and wallet-proof binding, an agent has everything needed to invoke this correctly on the first attempt.

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 100% and the schema already documents format auto-detection, the 256 KB material limit, and the omit-to-self-search behavior for disclosure. The description restates the optional-disclosure semantics and the 256 KB ceiling but adds no new syntax, format, or validation guidance beyond that.

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 states a specific verb and resource — submit material plus a disclosure, and receive a signed report on whether AI involvement is disclosed. It goes further by enumerating what the report covers (placement, wording, generated/assisted/human-review clauses), which cleanly separates it from adjacent siblings such as security-disclosure-check or terms-evidence-check.

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 the call context explicit: the disclosure can be supplied or omitted, and when omitted the material is scanned for its own disclosure. It also scopes what the tool will not do (no page fetch, no account access, no merchant contact, no money movement), which implicitly routes agents away from tools that fetch or transact. It stops short of naming a specific alternative tool to use instead.

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