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

Annotations already cover the read-only, idempotent, open-world safety profile, so the bar is lower, yet the description still adds substantive behaviour: results render "in the Vuelo card," an empty result means the hotel has no inventory or is unsellable, and prices hold only about an hour. That price-freshness caveat is the kind of contextual trait annotations cannot express.

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 scope constraint is front-loaded in the first sentence and the operational caveats come last, which is the right ordering. It runs dense and slightly crowded, repeating the four accepted property reference forms that the schema already lists, so a small amount of text does not earn 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?

With no output schema, the description still tells the agent where results surface (Vuelo card), how to read an empty response, and how long prices are valid. For a single-hotel availability lookup that is everything needed to call it and act on the answer correctly.

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, and the description largely repeats the property reference types already documented verbatim in the schema field description. The date semantics (from/to) and traveller counts carry no extra explanation beyond what the schema states. Nothing is missing, but nothing is added either.

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 with a specific verb and resource ("Live rooms and prices") and immediately bounds the scope to "ONE hotel the traveller already has in mind... without searching the whole town," which sharply separates it from the town-wide search sibling. It never restates the name tautologically and gives the agent an unambiguous mental model.

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 explicit trigger conditions ("when the traveller shares a Vuelo hotel link or asks about the same hotel on other dates") and an explicit fallback for the empty case ("say so, and offer to search the town"). The absence of a result is turned into a directive rather than left to inference, which is exactly the routing behaviour the agent needs.

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