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

Annotations already declare this a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds substantial context on top: the paid URL at 0.10 USDC per call on Base via x402 exact, the shared 10 signed-wallet free calls per rolling 30 days, the X-Wever-Wallet-Proof binding requirement, an Ed25519 signed receipt, and an explicit limitation that matching is literal (words, figures, dates, named items) with no interpretation. Those are exactly the non-obvious operational facts an agent cannot get from annotations.

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 and input modes are front-loaded, then the report contents, then endpoint/pricing/auth. It is dense and long (roughly 180 words), and the pricing-and-wallet-proof material competes for attention with the semantic description, but no sentence is pure repetition — each adds a distinct fact.

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 complex nested-schema tool with no output schema, the description carries the return-value burden well by enumerating what the signed report contains and, importantly, what it does not establish. It also discloses costs, auth binding, and the literal-matching limitation, leaving no major gap an agent would need filled before calling it.

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 schema already documents every parameter, including the fields-vs-evidence precedence and the format enum default. The description adds only light reinforcement — grouping the field set by name and giving the ACORD 25 example — without new syntax or constraint detail, so the baseline of 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 states a specific verb and resource — submit an insurance certificate or policy excerpt and receive a signed report — and enumerates exactly what the report establishes ('coverage by coverage with its limits and dates') versus what it flags ('a required coverage type absent, a limit below the requirement, a policy expired...'). That level of specificity distinguishes it from the many other *-evidence-check siblings without needing to name them.

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 gives implied usage context (send text, fields, or both, with optional requirements so the evidence can be held against them) and defines the read-only scope, but never says when to choose this over a sibling such as certification- or license-evidence-check, nor any precondition or exclusion. An agent must infer the routing from the insurance-specific wording.

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