opensea_collection_activity

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

With no annotation coverage at all, the description carries the behavioral burden, and it does so well: it discloses the response is cursor-paginated, lists the included marketplace events, and names the returned fields (counterparties, price, marketplace, transaction hash). It doesn't claim rate limits or auth, but for a read-only list endpoint the described behavior is clear and apparently non-mutating.

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?

Three sentences with no filler: the first anchors what the tool does, the second details the returned feed, and the third explains how to filter. Each sentence earns its place, and the most critical scoping information is front-loaded.

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?

For a four-parameter paginated list tool with no output schema, the description gives the essential response contract (event types and returned fields), the pagination mechanism, and a filtering example. It omits details like default behavior or how to resolve a slug, but the schema already covers parameter basics and the description compensates well for the missing output schema.

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 schema already documents all parameters (100% coverage), giving a baseline of 3. The description adds real meaning beyond the schema for the most ambiguous parameter, `event_types`, by listing the categories (sales, listings, offers, transfers, mints, collection/trait offers) and providing a concrete example value. Other parameters rely on the schema, which is adequate.

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 names an explicit verb and resource ('List an OpenSea collection's marketplace activity') and clarifies the scope as collection-level, not item-level or profile-level. It also enumerates the event types included, which differentiates it from sibling tools like opensea_item_activity, opensea_collection_top_sales, and opensea_collection_offers without opening their schemas.

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 provides concrete usage for narrowing with `event_types` and an example (`event_types=SALE`), but it never explicitly says when to choose this tool over its siblings or when not to use it. Usage is implied by the 'collection' scope, but alternatives are not named or compared.

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