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

Annotations only cover the safety profile (readOnly, openWorld, non-destructive, non-idempotent); the description goes well beyond by disclosing the price ($0.05 USDC on Base via x402, no free tier), the payment/auth mechanism, and the post-call verification obligation against the sha256 digest with a docs link. Payment-per-call context also explains the non-idempotent/read-only annotation pairing rather than contradicting it.

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?

Two sentences, front-loaded with the price and the value proposition, then the invocation instruction. It is dense but every clause carries information; the deeply nested first sentence and long docs URL slightly reduce 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?

With no output schema, the description carries the burden and does it: it names the returned artifacts (revealed {snapshot, nonce}, diffs of payment terms with from/to values, full hygiene checks). Combined with the annotations and 100%-covered schema, an agent has everything needed to invoke 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 all three parameters are already documented, including where commitment_ref originates ('locked_commitments.ref from the free check'). The description reinforces the linkage as part of a workflow but adds no syntax, format, or validation detail beyond the schema, so 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?

States a concrete resource and scope: the exact committed snapshots behind endpoint_spot_check's locked teasers, covering which payment terms changed in the last 30 days, when, from what to what, plus full hygiene checks. It explicitly positions itself against the sibling endpoint_spot_check, so an agent can distinguish paid reveal from free teaser without opening either 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?

Gives a clear prerequisite workflow: pass the url and the commitment_ref taken from the free answer's locked_commitments, implying endpoint_spot_check must run first. It also warns there is no free tier, which affects tool choice via cost. No explicit when-not-to-use case or fallback alternative is stated, 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.