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

Annotations already declare this a safe read, but the description adds material context beyond them: auth plus the read:bids scope requirement, the critical caveat 'trust visible_to_buyers, not the state', the dollars interpretation of amount_usd, and an explicit precedence rule that sold-listing transfer obligations must be surfaced first. It also maps is_seller offer actions to accept_offer/reject_offer, which pre-wires the follow-up call.

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?

Almost every sentence carries operational value, and the fragmented phrasing ('From XP's connected resale order book') is minor. The structural weakness is front-loading a rare edge case (sold listing awaiting ticket transfer) ahead of the primary polling use, which buries the headline purpose.

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?

An output schema exists, yet the description still clarifies the few return fields an agent would misread (amount_usd currency, visible_to_buyers as ground truth, per-offer actions). Auth requirements, seller vs buyer scope, and the post-create_listing verification role are all covered, leaving no gap for correct invocation.

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?

Only one parameter and schema coverage is 100%, so the schema already documents identifier, including its source tools. The description doesn't add format, validation, or lookup-failure semantics beyond that. Baseline 3 is appropriate.

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 and resource ('poll their listing on XP') and enumerates what it returns: open bids, state, seats, plus the seller's view of the live offer book. It explicitly distinguishes itself from the buyer-side sibling ('A buyer browsing open listings uses list_open_listings') and from list_my_listings, so an agent can route correctly without opening the schema.

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?

Gives concrete when-to-use conditions: polling before deciding to accept/reject an offer, and confirming what XP stored after create_listing, complete with a worked example query. It also names the exclusion (buyer browsing) and the alternative sibling, which is the full when/when-not/alternative triad.

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