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

With no annotations, the description carries the full burden and does well: real-time non-cached results, prices are final purchase values, BRL returns two distinct prices (card vs Pix) that must both be shown, and the search expires after a limited window. It omits auth/token semantics and any rate-limit or result-count behavior, which keeps it from a 5.

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-loaded with purpose, then questions to ask, then filters, then the search_id contract, then the security warning — a logical order. It is dense for nine parameters, though a few passages (the label/rotulo caveat, the repeated language-inheritance note) could be tightened.

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 9-parameter search with zero schema coverage, no annotations and no output schema, the description covers inputs, currency semantics, expiry, downstream chaining and even a prompt-injection warning about third-party hotel content. The only real gap is the undocumented `token` parameter.

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 compensate — and it documents 8 of 9 params: currency values and payment-provider implications, nationality as mandatory ISO2, destino_ou_hotel with the label/slug caveat, minimum one adult, children_ages as one age per child with an example, and dates as YYYY-MM-DD. Only `token` is left unexplained.

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 — live (never cached) rates from the global catalog, grouped by hotel with the lowest price per hotel. It also implicitly separates itself from `ver_quartos`, `get_quote` and `create_payment` by positioning itself as the producer of `search_id`.

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?

Explicitly tells the agent to ASK the guest for `currency` and `nationality` before calling when unknown, and names `list_destinations` as the alternative when the hotel name is ambiguous. It also spells out the downstream contract: `search_id` is required by `ver_quartos`, `get_quote` and `create_payment`.

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