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

Annotations already declare destructiveHint, idempotentHint, and openWorldHint, but the description adds substantial context: the fixed tombstone text, non-refundable fee, preservation of completed sales, halting of new purchase attempts, the x402 payment window nuance, and the city-ownership sub-rules. This goes well beyond what the annotations convey.

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 long but dense, with each sentence contributing a distinct behavioral fact. It front-loads the most critical information ('permanent and idempotent') before covering edge cases. For an irreversible operation with multiple special cases, the length is justified, though slightly heavier than minimal.

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 description thoroughly covers the major behavioral edge cases: fee non-refundability, completed sales preservation, accepted payment finishing, x402 claimability windows, maintainer-removed, sold city-ownership, and unsold city-ownership. It even points to the returned city_cancel_url. The only small gap is not describing what the normal success response looks like, but given the absence of an output schema and a single parameter, this is nearly complete.

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 only describes the id as 'listing id' (100% coverage). The description adds meaningful semantic constraints: the id must reference a listing you own, and only that id is to be sent — there is no custom reason parameter. This clarifies ownership and parameter exclusivity beyond the schema.

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 clearly identifies the action as withdrawing a listing and immediately establishes its defining property: permanence and idempotency. It also implicitly distinguishes itself from siblings like list_item and edit_item by describing the withdrawal's specific effects and exclusions.

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 explicit conditions for when the tool applies ('a listing you own') and when it does not ('maintainer-removed listing cannot be withdrawn', 'sold city-ownership listing cannot be withdrawn'). It also provides a direct alternative by saying to use the returned city_cancel_url for unsold city-ownership listings, though it does not compare against all sibling tools.

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