checkout

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

With no annotations, the description carries the full burden. It discloses the two-step nature, the requirement for explicit user approval, the effect of changed price/terms, and the eligibility confirmation conditions. It also warns against retrying unknown outcomes, which is a key behavioral constraint. It does not mention side effects like booking finalization, but the token flow implies that.

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 compact yet information-dense, front-loading the purpose and then logically sequencing the workflow, conditions, and a warning. Every sentence adds value, and there is no fluff.

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 tool is complex with 16 parameters and no output schema. The description explains the two-step process and key flags, but it omits details on which parameters are needed in each call, error handling beyond unknown outcomes, and what the preview response contains. An agent might not know exactly what to supply for the first call without additional inference.

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 0%, so the description must explain parameters. It explains confirmationToken, governmentEligibilityConfirmed, and specialRateEligibilityConfirmed, which are critical. However, it does not clarify the roles of the other 13 parameters (email, phone, dates, guest counts, etc.) beyond the general phrase 'guest details.' It does not indicate which are required for the first call versus the token-only call, leaving some ambiguity.

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 states the tool prepares a checkout preview for a given offerId, which is a specific verb-resource pair. It distinguishes itself from siblings like select_room or add_extras by focusing on the checkout step, though it does not explicitly name alternatives.

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 provides explicit workflow guidance: call once to get a token, then call again with that token after user approval. It also specifies conditions for eligibility flags and warns against retrying unknown outcomes. However, it does not state when to prefer this over other booking tools or what precedes it in the flow.

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