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

Goes well beyond the annotations: discloses that no Fold account is needed, that the card is NOT charged at scheduling time (only after intake), that the guest must visit the Stripe URL, that the server enforces cut-offs on its own clock, and that it will never silently add a surcharge or shift the day. This is exactly the mutation-safety context a destructiveHint tool needs.

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?

Front-loads purpose, account requirement, and return values, then organizes pricing and tier rules under clear headers and bullets. It is long, and the return-tier block restates the schema's returnPreference description nearly verbatim, which is the main wasted payload.

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?

With 11 parameters, no output schema, and a destructive mutation, the description covers everything an agent needs: the booking prerequisite (hotel Place ID from search_hotels, stated in schema), payment flow, what is returned (FHL code + Stripe URL), pricing/minimums, tier cut-offs, and retry behavior. The only residual gap is sibling differentiation, scored elsewhere.

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%, so the baseline is 3, but the description adds meaning the schema lacks: how pricing interacts with services (wash & fold flat vs per-garment dry cleaning), the $49.99 minimum, the $9.99 hotel service charge, and which surcharges do/don't count toward the minimum. That informs real parameter choices, though the return-tier text largely duplicates the returnPreference schema description.

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 ('Schedule a laundry pickup for a hotel guest') plus a concrete side effect (creates an order, returns FHL tracking code + Stripe setup URL). However, a sibling named 'book_for_hotel_guest' exists and the description never distinguishes the two, leaving the agent to guess which hotel booking tool to call.

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 strong operational guidance for the return-time tiers (which to pick given drop-off time) and explicitly tells the agent how to handle server refusals (confirm the $30 express surcharge with the guest before retrying, fall back to next_day after noon). It does not address when to use this tool versus the near-identical book_for_hotel_guest sibling, so exclusivity is missing.

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