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

With no annotations, the description carries the full burden and excels: it discloses preconditions (ownership, transferability not voted/attached), server-side fee injection, the exact deliverable (one-time NFT approval + EIP-712 typed data), and the non-custodial property (never signs or holds keys). This gives an agent a clear security and side-effect model.

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 three sentences with no wasted words, front-loading the primary purpose and then adding essential behavioral details. Every clause earns its place, and the final 'Never signs or holds keys' is a compact high-value security note.

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 complex 10-parameter tool with no output schema or annotations, the description covers the essential context: purpose, preconditions, process, and deliverable. It doesn't explain the exact return structure beyond the typed-data summary or error cases, and doesn't describe how the returned approval/signature should be used downstream, but it provides enough for an agent to decide and invoke Correctly.

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 description adds no direct parameter explanations and relies on the schema, which covers 60% of parameters. The 'SELL listing or Dutch auction' phrase indirectly maps to the kind enum, and the ownership check touches the seller parameter, but marketId, durationDays, and the relationship between startAsk/endAsk remain under-explained. This is adequate given the moderate schema coverage.

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 action (prepare), resource (SELL listing or Dutch auction), and key distinguishing behaviors (ownership verification, Seaport order, returns approval + typed data). The explicit 'SELL' clearly differentiates it from sibling prepare_offer and prepare_purchase, and the Dutch auction mention distinguishes it from prepare_cancel.

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 clearly implies when to use the tool: when a seller wants to list an NFT or start a Dutch auction. It doesn't explicitly name alternatives or exclusions, but 'SELL' and 'seller OWNS the position' route the agent away from buy-side or cancellation tools. Lacks an explicit 'use prepare_offer instead for bids', but the context is strong enough.

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