luxury-lodging

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds the 93-day date range limit and that it returns open/blocked nights and minimum stay, which are behavioral details beyond the annotations. It does not describe the response format or error handling, but for a read-only calendar query, the added context is meaningful and raises it above baseline.

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, front-loaded with the primary purpose (open and blocked nights for one property over a date range up to 93 days, with minimum stay) and then gives usage guidance. Every word earns its place; there is no redundancy or 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?

For a simple read-only query with three well-documented parameters, the description covers the purpose, the output (open/blocked nights, minimum stay), the date range limit, and usage guidance. Annotations cover safety and idempotency, and there is no output schema requiring explanation. The tool is fully specified for an agent to call it 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 description coverage is 100%, with each parameter (property_id, start_date, end_date) having a clear description. The tool description does not add parameter-specific syntax or details beyond what the schema already provides. According to the rubric, when schema coverage is high, a baseline of 3 is appropriate.

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 retrieves open and blocked nights for one property over a date range, including the minimum stay. It explicitly differentiates from get_live_quote by noting that this tool is for suggesting alternative dates, while get_live_quote confirms and prices a specific stay. This provides a specific verb, resource, and scope, and distinguishes it from a key sibling.

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 usage guidance: 'Use this to suggest alternative dates; use get_live_quote to confirm and price a specific stay.' This tells the agent when to select this tool versus the sibling get_live_quote, leaving no ambiguity about the tool's role.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond those annotations: the quote includes cleaning, fees, taxes, a refundable deposit hold, cancellation/check-in terms, and delegates booking completion to Luxury Lodging's site. It also cautions against promising refunds or quoting nightly rates alone.

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 and every sentence earns its place: what the price includes, what the return value enables, and how the agent should report the result. It is front-loaded with the core purpose and uses no filler.

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 adequately covers both the return value and agent behavior: the quote composition, the booking_url, and the refund/display constraints. Combined with the rich annotations, an agent has enough to select and invoke the tool 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?

The input schema already provides descriptions for all five parameters, so the description does not need to repeat or enrich them. It reinforces one property/one stay semantics but adds nothing specific about parameter formats or constraints beyond the schema.

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 identifies the tool as producing a live total price for one property and one stay, including fees, taxes, deposit hold, and booking terms. It also distinguishes itself from sibling tools by emphasizing the single-property/single-stay scope and the booking_url it returns.

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 intended use case is clear: use this tool when the agent needs a complete quoted total for a specific property and date range. It does not explicitly name sibling tools or state when not to use it, so it misses the explicit exclusion guidance needed for a 5.

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

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

Annotations already mark readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds valuable context: location is at neighbourhood level, exact address shared only after booking, and policies are the 'real' ones as recorded by the property manager. This clarifies data granularity and source without contradicting annotations.

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?

One sentence, front-loaded with the core purpose, and packed with relevant specifics. It is efficient and free of redundancy, though slightly dense. Structure is clear and easy to scan.

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 simple one-parameter read tool with no output schema, the description covers what the agent will receive (full details, location granularity, policy authenticity). Nothing critical is missing for an agent to invoke it 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% – the single parameter property_id is described as 'Property id or the slug from a booking link.' The description adds no further detail about the parameter itself, so it relies entirely on the schema. Baseline 3 is appropriate.

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?

Description clearly states verb 'Get' with specific resource 'property details', and enumerates concrete content: bedrooms, capacity, amenities, photos, house rules, policies, and location. This distinguishes it from siblings like get_availability and search_properties, which serve different purposes.

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 phrase 'Full detail for one property' implies this tool is for a single specific property, contrasting with search_properties which presumably returns multiple. It doesn't explicitly name alternatives or exclusions, but the scope is clear enough for an agent to select it appropriately.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is established. The description adds meaningful behavioral context beyond those hints: the exact scope ('directly bookable'), the two data fields returned (home count and maximum sleeping capacity), and that it is a coverage lookup rather than a search.

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?

Two purposeful sentences with no fluff. The core statement of what is returned is front-loaded, followed by a clear usage trigger. 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 zero-parameter, read-only, idempotent listing tool, the description is complete. It tells the agent what data will be returned, the scope of the data, and the exact circumstances under which the tool should be invoked. No output schema exists, but the return shape is adequately described.

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?

The tool takes zero parameters, so the description has no parameter semantics burden. Baseline 4 is appropriate; the description correctly focuses on the response content instead of over-explaining inputs.

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's function: enumerating cities where Luxury Lodging has directly bookable homes, with key aggregate data (home count, max group size). It also distinguishes itself from the sibling search-oriented tools by framing this as a destination-coverage listing.

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 explicitly says when to use it: when the guest has not named a place, or to verify a destination is covered before searching. It does not explicitly name sibling alternatives or state when not to use it, so it misses the full exclusion guidance needed for a 5.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and non-destructive behavior. Beyond that, the description adds meaningful behavior: only properties actually available are returned when dates are provided, and the nightly rate should not be trusted as the stay total. This is useful context not captured by annotations.

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?

Three sentences, each earning its place: the first states what the tool searches, the second explains availability behavior with dates, and the third gives essential pricing guidance. It is front-loaded and free of filler.

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 11 parameters, no output schema, and no required fields, a complete description would ideally mention what fields appear in results or how ambiguous destinations are handled. However, the schema covers parameter semantics thoroughly, and the description adds the two most critical behavioral rules: date-based availability filtering and always using get_live_quote for the true total.

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 explains all 11 parameters in detail. The description adds only a high-level summary of search dimensions ('destination, dates, group size, bedrooms and amenities') and the date-dependent availability behavior, which slightly reinforces but does not materially extend the schema's parameter documentation.

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 states a specific verb and resource: 'Search Luxury Lodging's directly bookable vacation rentals.' It names the main search facets (destination, dates, group size, bedrooms, amenities), and this clearly distinguishes it from siblings like get_property_details and get_live_quote, which serve different purposes.

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 clear context for using the tool: provide dates to get truly available propertiescars, and never use the nightly rate as the final price. It points to get_live_quote as the correct quoting alternative. However, it does not explicitly state when not to use this tool in favor of get_availability or list_markets.

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