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

With no annotations, the description carries the full burden and does useful work: it states the data is read directly on-chain (and enumerates what the report contains) and discloses the payment model ('x402 price $0.05/call (USDC, eip155:8453)'). It stops short of covering error behavior, latency/caching, or rate limits, so it is good but not complete.

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 report contents are front-loaded effectively, but the 'Carfax' framing is stated twice (once as a metaphor, once restated as 'the Carfax for NFT collections — holders, concentration, wash signals'), and the second occurrence contains a grammatical error ('needs to the Carfax'). Two sentences are redundant rather than earning their place.

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?

There is no output schema, so the description compensates by enumerating the delivered fields (supply, holders, concentration verdict, wash signals, trend), which is what an agent needs to judge fitness. It omits failure modes (invalid contract, unsupported chain) and pagination/response shape, leaving a small gap.

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% and the chain enum is fully specified in-schema, so the structured fields already do the heavy lifting. The description adds only the general claim 'any NFT collection' and does not clarify contract address format or per-chain quirks. 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?

Names a specific verb and resource ('Full on-chain due-diligence report for any NFT collection') and enumerates the exact contents: mint supply, unique holders, top-10 concentration with verdict, wash-trading indicators, activity trend. This is clearly distinguishable from siblings like nft_holder_distribution or nft_collection_activity, which cover only a subset of these fields.

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 a scenario ('the check an agent runs before its human buys') which implies the pre-purchase use case, but never names or excludes alternatives such as nft_holder_distribution, nft_collection_activity, or nft_collection_compare. An agent must infer when this aggregate report is preferable to the narrower sibling tools.

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