Check real-time availability and nightly pricing for a specific villa over a date range. Returns whether the property is available and the average nightly rate. For a binding total price including all fees and taxes, use get_quote.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Interhome accommodation code. | |
| checkIn | Yes | Check-in date (YYYY-MM-DD). | |
| checkOut | Yes | Check-out date (YYYY-MM-DD). Must be after checkIn. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It honestly describes the tool as checking availability and pricing (a read operation). It does not mention any destructive side effects. However, it could elaborate on how 'real-time' is handled or edge cases like overlapping bookings.
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 only two sentences, front-loaded with the core purpose and followed by a clear alternative. Every word earns its place with no wasted content.
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?
Given there is no output schema, the description sufficiently indicates the return values (availability and average nightly rate). It could be more detailed about the exact format or additional fields, but it is complete enough for a simple look-up tool with sibling context.
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 description does not add significant meaning beyond the schema. It mentions 'specific villa' and 'date range' which align with the parameters but does not provide additional semantics or examples.
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 checks real-time availability and nightly pricing for a specific villa over a date range. It specifies the return values (availability and average nightly rate), and distinguishes from sibling get_quote by noting that get_quote provides a binding total price.
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 outlines when to use this tool (for availability and nightly pricing) and what to use instead for a binding total price (get_quote). It also implies the tool is for a specific villa via the required 'code' parameter, providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool serves a distinct function: search, details, availability, and quoting. There is no overlap or ambiguity between them.
All tool names follow a consistent verb_noun pattern with underscores (check_availability, get_quote, get_villa_details, search_villas). No mixing of conventions.
4 tools are well-suited for a villa rental server, covering search, details, availability, and pricing without being too few or too many.
The toolset covers key operations: search, details, availability, and quotes. The only minor gap is a direct booking tool, but the provided booking link mitigates this.
