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

Annotations already declare readOnlyHint=true, and the description reinforces this ('books nothing') while adding genuinely new behavioral detail: per-property unavailability reasons are returned, and the guest-capacity constraint surfaces as an error reason. Auth/token requirements and rate limits are not covered, keeping it short of 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 the primary purpose and the value-add (unavailability reasons) in a single dense sentence, followed by two short clauses. The 'Read-only, books nothing' clause partially restates the readOnlyHint annotation, a minor redundancy, but overall it is tight and earns its space.

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 carries the burden of explaining returns and does so: total price per property plus reasons for unavailability. Required inputs are clear from the schema. Minor gaps remain around response shape details and any per-property result structure, but nothing critical is missing.

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 100%, so the schema already documents all six parameters fully (including the customer_id lookup hint and apartment_ids omission semantics). The description adds little parameter-level meaning beyond the implicit scoping (availability for a given arrival/departure pair), so the baseline 3 applies.

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+resource (check bookable properties, quote total price) and goes further by describing the negative case with concrete reasons (minimum stay, too many guests, arrival day, lead time). It is clearly distinguishable from siblings like smoobu_create_reservation and smoobu_get_rates.

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?

Usage context is implied: 'Read-only, books nothing' signals this is a pre-booking check rather than a write, contrasting implicitly with smoobu_create_reservation. However, no sibling is named and no explicit when/when-not condition is stated, so the agent must infer the workflow placement.

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