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

Annotations already declare destructive=true, idempotent=false, and not read-only. The description adds one genuinely useful behavioral fact beyond that — withdraw refunds the buy_now escrow in full — plus the seller/buyer role split. It says nothing about the consequences of accept or decline (escrow transfer, what happens to competing offers, irreversibility), so the added context is partial.

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 text is short and the WHEN condition is packed densely into one sentence with the alternative called out right after. The leading 'bazaar_resolve_proposal.' duplicates the tool name and the placeholder example ("<offer_id>","<action>") is low-value filler, which keeps it from a 5.

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, so return values need no explanation, and the description covers the trigger and role semantics adequately. For a destructive, non-idempotent mutation it leaves a real gap: the effects of accept/decline are never described, so an agent cannot predict outcomes of the most consequential actions.

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?

Schema coverage is 100% and the action enum already documents the accept/decline/withdraw roles, so the schema is doing the heavy lifting. The description restates the same role mapping and adds only the escrow-refund consequence for withdraw; the trailing Example uses bare placeholders and contributes no semantic detail.

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 opens by restating the tool name, which adds nothing, but immediately follows with a concrete enumeration of states: 'seller accepts/declines an offer on your listing, OR the buyer withdraws their own pending offer.' Combined with the action enum this makes the operation identifiable, and it explicitly contrasts with booth_accept. It falls short of a 5 because the verb 'resolve' alone is opaque and the real meaning only lands after the WHEN clause.

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?

It gives an explicit trigger ('WHEN: seller accepts/declines... OR the buyer withdraws') and names an alternative tool, booth_accept, with a brief differentiator ('booth swaps'). What it lacks is a when-not-to-use condition or any note on which pending offers are eligible.

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