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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds behavioral context beyond that: it mentions the wash overlay is Solana-only (the only wash graph), while Base and Polygon listings carry wash_unknown and remain wash_unknown. It also states the query parameters mirror GET /v1/intel/x402-directory, which signals expected API alignment. It doesn't fully describe output shape or pagination, but output schema exists and the behavioral semantics of filtering/overlay are clearly disclosed.

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 reasonably concise and front-loaded with the core purpose, but it includes some potentially over-technical detail (e.g., EIP-3009 corpus membership, settlement reputation on pay_to) that may be useful but somewhat dense. It earns its place because it explains the tool's role and exclusions, but several sentences could be tightened for clarity without losing meaning.

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?

Given the tool has an output schema and full schema descriptions for its 3 parameters, the description provides adequate operational context: it clarifies the data domain, the indexing key (payTo), the wash-flag semantics across chains, and explicitly routes the caller away from the wrong endpoints. It doesn't mention response shape or error cases, but the output schema covers return values, and the description's exclusions plus schema are sufficient for correct invocation.

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 all three parameters (limit, source, flagged_only) with defaults and ranges. The description adds high-level context that query params mirror the HTTP endpoint but doesn't add deeper semantics beyond what the schema provides. Baseline 3 is appropriate because the schema does the heavy lifting.

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 clearly states the tool's function: it provides a wash overlay on ingested PayAI/CDP/Agentic listings indexed by payTo, and explicitly distinguishes this from the HTTP GET /v1/intel/resources resource join surface and from GET /v1/intel/bazaar/offers (TWZRD Bazaar catalog) and 402 extensions.bazaar. This differentiates it well from sibling tools and gives an agent a specific action and resource.

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 description gives explicit guidance: 'Use this tool when you need the ingested listing overlay indexed by payTo', and explicitly states what not to use ('Not GET /v1/intel/bazaar/offers (TWZRD Bazaar catalog) and not 402 extensions.bazaar'). It names alternatives (GET /v1/intel/resources) and gives the reason those alternatives exist, so an agent knows when this tool is appropriate.

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