opensea_drops

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

With no annotations, the description carries the burden of disclosing behavior. It clearly indicates this is a read-only list operation and highlights the two calendar windows, which is useful. But it does not state what happens when type is omitted, how pagination behaves, or any limits/errors, so an agent is left guessing about default behavior.

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 relatively short and puts the verb first, but it repeats 'drop calendar' twice in the opening sentence, creating redundancy. The first sentence 'List the OpenSea drop calendar' and the second 'Returns the NFT drop calendar' could be merged without losing information.

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?

The tool has no output schema, so the description must explain return values and invocation expectations. It does describe the returned fields (contract, chain, parent collection) and hints at pagination through the cursor schema, but it omits defaults for the optional type and limit parameters and doesn't describe the full response shape (e.g., presence of next_page_cursor). An agent could invoke it, but edge cases remain ambiguous.

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 input schema already describes all three parameters, so the baseline is 3. The description adds real semantic value for type by mapping the two accepted values to use cases ('watch for launches' vs 'ones that just went live'), which goes beyond the schema's terse 'Calendar window'. It does not add meaning to limit/cursor, but the schema already covers those.

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 a clear verb and resource: it lists the OpenSea drop calendar and returns NFT drops in either upcoming or recently minted windows, with contract, chain, and parent collection fields. This distinguishes it from sibling OpenSea tools like opensea_rankings or opensea_collection_activity, which serve different data. It doesn't explicitly name an alternative, so it doesn't earn a full 5.

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 concrete guidance for the type parameter ('Use type=UPCOMING to watch for launches and type=RECENTLY_MINTED for ones that just went live'), which tells an agent which mode to pick. However, it never says when to choose this tool over an alternative (e.g., a specific collection's drops), nor when not to use it. The guidance is parameter-level rather than tool-selection-level.

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