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

Annotations already cover safety and idempotency, and the description adds genuinely new operational context: the call is paid ($222.00 USDC on Base or Arbitrum One), requires POSTing inputs as JSON to a specific paid_url with an x402 v2 PAYMENT-SIGNATURE header, and returns a signed receipt. That is exactly the kind of auth/cost detail annotations cannot express; the only weakness is that payment failure behaviour and latency are not mentioned.

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 description is short and front-loads the bundle contents, which is good. But it is written in telegraphic fragments ('document_hash optional', 'One check: the tool alone') whose meaning is unclear, and payment mechanics are interleaved with capability description rather than separated, hurting scannability.

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, multi-check tool with a 100%-covered schema and an output schema, the description supplies what is missing: the composite nature of the result, the price and settlement chain, and the exact payment protocol. Only the cryptic single-check sentence and the absence of failure/payment-error behaviour keep it from a 5.

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 all four parameters are already documented, including the detailed idempotency-key semantics and the SHA256 pattern for document_hash. The description only reiterates that document_hash is optional, adding no meaning beyond the schema, 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 names the concrete checks bundled together (liveness, content, TLS fingerprint, trust verdict, doc timestamp) and states the output is a single signed receipt, which is far more specific than the bare name 'diligence_pack'. It does not, however, contrast itself with near neighbours such as trust_preflight, trust_report, or the check_url_* family, so the agent must infer which bundle is appropriate.

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?

The phrase 'One check: the tool alone' gestures at a rule of thumb (use individual tools for single checks) but never names a sibling or states the condition explicitly. Payment prerequisites and the price are spelled out, but there is no when-not-to-use guidance and no stated prerequisites for the target URL beyond the schema's HTTPS constraint.

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