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

Beyond readOnlyHint/openWorldHint, it discloses that only public HTTPS targets are accepted, that no payment or request bodies are stored, that pricing is $0.05 USDC on Base, that a shared 3-calls-per-IP-per-UTC-day trial exists and is shared with HTTP trials, and that a generic MCP connector cannot complete a paid continuation. It also sets explicit expectations about the result (riskScore, flagged spans, rewrite suggestions) and states the important limitation that this is not Coinbase policy certification or guaranteed detection.

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 alias/routing statement is correctly front-loaded, but the body is roughly 350 words mixing purpose, screening scope, pricing, two illustrative output excerpts, payment-protocol steps and wallet-safety policy. The payment walkthrough and repeated 'illustrative only, not a live result' disclaimers are operational boilerplate that crowds out the tool's actual contract.

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 illustrative response excerpt (cdpPreflight, riskScore, flags, suggestedRewrite, screenComplete) valuably conveys the return shape, and the safety disclaimers and cost model are all present. The main gap is method-parameter behavior, but otherwise an agent has enough to call it correctly 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 0%, so the description must compensate, and it only partly does: 'Public HTTPS only' constrains the url parameter, the 'no request bodies stored' note hints at POST semantics, and one minimal input example is repeated from the schema. The method enum (GET/HEAD/POST) is never explained — what method means for the target fetch, or when to choose each — so half the parameter surface remains undocumented.

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 plainly that this is a compatibility alias of listing_guard performing the same operation, and then describes the resource concretely: CDP technical validation plus a heuristic metadata screen covering URLs, tool calls, invisible Unicode, long fields and outlier prices. An agent can distinguish it from listing_guard without opening either schema. It falls short of 5 only because the core purpose is buried mid-sentence inside a long single-sentence block.

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 an explicit routing rule: use listing_guard for a new detailed metadata check, keep this only for existing clients, and warns the two are 'the same operation, not two independent checks' so they should not both be called. It also spells out the exact escalation path (try the shared free allowance first; on payment required, stop; obtain approval; retry with the x402 payload) and explicitly forbids silent fallback to payment.

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