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

Annotations only provide generic flags (readOnly=false, idempotent=false, destructive=false), so the description carries the behavioral burden. It adds meaningful traits: the hold lasts 10 minutes, the price is fixed, and explicit user consent is required before proceeding. It does not contradict the annotations, though it does not mention expiry side effects or return shape.

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 two sentences with no filler. The first sentence states the core behavior, and the second provides parameter-mode selection and the required follow-up step. Information is front-loaded and every sentence earns its place.

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 a tool with 10 parameters and no output schema, the description covers the main invocation patterns and the surrounding workflow. It has some gaps around optional parameters like `qty`, `tickets`, and `resource_id`, and it does not describe the tool's return value, but it is sufficient for an agent to correctly initiate the hold and proceed to the confirmation step.

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 description coverage is only 40%, but the description compensates for the central time parameters by mapping `start`, `session_id`, and `from`/`to` to slot, session, and rental offerings. It does not explain `qty`, `party_size`, `tickets`, `resource_id`, or `offering_id`, so compensation is partial, but the most important usage distinctions are provided.

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 uses a specific verb and object: 'Reserves the chosen time, seats or units for 10 minutes and fixes the price.' It clearly identifies the action and its scope, and its mention of create_booking helps distinguish this hold operation from the final booking step.

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?

The description gives explicit parameter-mode guidance: 'Pass `start` (slots), `session_id` (sessions) or `from`+`to` (rentals).' It also prescribes the exact user-facing workflow: show time, price, and cancellation policy, then wait for an explicit yes before create_booking. This leaves little ambiguity about when and how to use the tool.

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