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

Annotations already declare destructiveHint=true and openWorldHint=true, so the bar is lower, yet the description adds real substance: 'This creates a real order', no card link/charge for hotel billing, monthly Folio placement, hotel contract pricing, and the $49.99 order minimum. What it omits is reversibility — nothing about cancellation, cutoff times, or what happens after scheduling, which matters for a destructive mutation.

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 prerequisite is front-loaded and every clause carries operational content, but the middle is a dense run-on of billing and pricing details that could be split into shorter statements. No filler, though density costs some scannability.

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 an 11-parameter, 7-required mutation with no output schema, the description covers authentication context, billing modes, pricing tiers, minimums, and return timing. Gaps remain around order lifecycle (cancellation/reschedule via siblings, what the response contains), which an agent would need before committing a destructive real order.

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?

With 55% schema coverage the description does heavy lifting: it defines the default and business meaning of billTo (statement vs card link), the four returnPreference modes with timing and +$30 express pricing, and why guest contact fields are required even for hotel billing. It adds nothing for services (WASH_AND_FOLD/DRY_CLEANING/HANG_DRY) or notes, leaving some required parameters to 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?

States a specific verb and resource ('Schedules laundry pickup for a guest by room number at that hotel') and scopes it to a named audience (front-desk staff at a Fold partner hotel). It also implicitly separates itself from book_hotel_pickup by pointing to that sibling for guest-billed orders.

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 an explicit prerequisite (login must belong to the hotel's Fold business account), lays out the billTo decision with consequences for each branch, and points to book_hotel_pickup as the alternative for guest-rate pricing. returnPreference values are explained with timing windows and surcharges, so the agent can choose correctly.

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