opensea_collection_rarest_items

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

No annotations exist, so the description carries the full burden. It discloses that the tool returns only items with current listings, each with rarity rank, traits, and asking price, and notes the 'buyable right now' constraint. This goes beyond a generic 'list' by describing scope and output composition. It doesn't contradict any annotations (none provided). Minor omissions like pagination or result limits exist but are not critical for a simple read tool.

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?

Exactly two sentences with no redundancy. The first sentence states the primary function, the second clarifies the return structure and scope. Every word earns its place; there is no filler.

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 no output schema, the description specifies exactly what each returned item includes (rarity rank, traits, asking price) and the constraint of being listed/buyable. This is sufficient for an agent to know what to expect. It lacks details on pagination or total count, but for a fairly simple 'rarest items' endpoint, this is adequate.

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?

The single parameter 'slug' is fully described in the schema as 'OpenSea collection slug' (100% coverage). The description doesn't add extra meaning to the parameter, but it's simple and self-explanatory. Baseline 3 is appropriate since the schema handles the parameter documentation.

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 specific verb-resource pair: 'List an OpenSea collection's rarest listed items.' It clearly defines the output content (rarity rank, traits, asking price) and explicitly differentiates from trait endpoints by focusing on buyable items. This leaves no ambiguity about what the tool does.

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?

Provides clear context for when to use this tool: it explicitly contrasts with 'the trait endpoints' and scopes to items with standing listings ('buyable right now'). While it doesn't name specific sibling tool names, it offers a concrete differentiator that an agent can act on. It could be more explicit with alternative names, but the guidance is sufficient.

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