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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds substantial context beyond them: 0.10 USDC per call on Base via x402 exact, 10 free signed-wallet calls per rolling 30 days, the 64 KB input ceiling, the requirement to bind X-Wever-Wallet-Proof to the exact JSON arguments plus tool route, and an Ed25519 signed receipt on the report. None of this is derivable from the annotations, and it does not contradict idempotentHint=false since each call is separately billed.

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 input shape are front-loaded in the first two sentences, and the operational details (billing, wallet proof, contract link) trail correctly. It is dense but largely earns its length, with the main redundancy being the re-listing of declaration formats already present in the schema.

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 paid, read-only validator with no output schema, the description supplies everything an agent needs: what is validated, that only the supplied declaration is examined, the payment and authentication mechanics, the return type (signed report with Ed25519 receipt), and links to the contract and human page.

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% and the 'declaration' property description already enumerates the accepted shapes (402 body, route declaration, bazaar extension alone) and encodings (JSON, JSON text, base64 PAYMENT-REQUIRED header). The description largely repeats that enumeration, adding only the 64 KB limit and the fact that the checks are against CDP's own validation. With the schema carrying this load, baseline 3 applies.

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: 'check a CDP Bazaar discovery declaration before you publish it.' It names the exact artefact being validated and the validation standard (the checks CDP applies), which lets an agent distinguish this from the many other '-check' siblings without opening the 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 states the trigger condition clearly ('before you publish it') and bounds scope with 'It evaluates the supplied declaration only and fetches nothing,' which implicitly separates it from tools that retrieve live endpoint data. It does not name a specific sibling alternative or state when not to use it, so it falls short of a 5.

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