Search and book luxury villa rentals across Europe with real-time availability and pricing.
Scored across 4 tools
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.
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.
Get a binding price quote for a villa stay including full breakdown of accommodation cost, cleaning fee, tourist tax, and security deposit. Always use this for final price — never estimate or calculate prices manually. Provides a direct booking link with dates pre-filled.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Interhome accommodation code. | |
| guests | Yes | Total number of guests. | |
| checkIn | Yes | Check-in date (YYYY-MM-DD). | |
| checkOut | Yes | Check-out date (YYYY-MM-DD). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that quote is binding and includes full breakdown and booking link. No side effects or auth needs mentioned, but for a read-only price query this is sufficient.
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 sentences with no wasted words. First sentence states purpose and output, second provides usage guidance. Front-loaded and efficient.
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?
Tool has 4 well-documented required params with no output schema. Description covers output contents (breakdown, booking link) and usage context. Complete for its purpose.
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% with good descriptions for all 4 parameters. The description does not add new meaning to parameters beyond what's in schema; it focuses on output (breakdown, booking link). 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?
The description clearly states the tool provides a binding price quote with full breakdown, and explicitly distinguishes it from manual estimation by saying 'Always use this for final price — never estimate or calculate prices manually.'
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 advises to use this tool for final pricing instead of manual calculation, providing clear when-to-use guidance. It lacks explicit exclusions or alternatives, but the sibling context (check_availability, etc.) implies when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for a specific villa including description, all photos, amenities, house rules, and check-in/check-out times. Call this when the user wants more information about a property found via search_villas.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Interhome accommodation code from a search result, e.g. "IH-123456". |
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 discloses that the tool returns full details (including specific fields). However, it does not mention idempotency, authentication requirements, or any side effects. For a read-only tool, the disclosure is adequate but not exceptional.
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 sentences with no wasted words. The first sentence states the purpose and contents; the second provides usage context. Front-loaded and efficient.
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?
No output schema exists, so the description must cover return values. It lists key items (description, photos, amenities, house rules, times). For a simple read tool, this is fairly complete, though it could mention response structure or pagination (unlikely needed).
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 schema already documents the single parameter 'code' with pattern and description. The description does not add additional meaning beyond the schema, achieving baseline 3.
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 full details for a specific villa, listing specific content (description, photos, amenities, house rules, times). It distinguishes from sibling tools like search_villas (which finds properties) and check_availability/get_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?
Explicitly tells when to use: 'when the user wants more information about a property found via search_villas.' This provides clear context for usage relative to the search flow, though it does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search self-catering villa rentals with real-time availability. Filter by destination, check-in/check-out dates, guests, bedrooms, and amenities (pool, pet-friendly, sea view, wifi, parking, air conditioning). Returns matching villas with nightly price and a link to book. Always pass checkIn, checkOut, and guests when the user has specified dates and party size.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | Region or area, e.g. "Costa del Sol", "Tuscany", "Algarve". | |
| pool | No | Private swimming pool required. | |
| sort | No | Result ordering. | relevance |
| wifi | No | WiFi required. | |
| airCon | No | Air conditioning required. | |
| cursor | No | Pagination cursor from a previous response. | |
| guests | No | Total number of guests including children. | |
| checkIn | No | Check-in date (YYYY-MM-DD). Required for availability filtering. | |
| country | No | Country name in English, e.g. "Spain", "France", "Italy". | |
| parking | No | On-site parking required. | |
| seaView | No | Sea or ocean view required. | |
| bedrooms | No | Minimum number of bedrooms required. | |
| checkOut | No | Check-out date (YYYY-MM-DD). Required with checkIn. | |
| location | No | Town or resort name, e.g. "Marbella", "Positano", "Lagos". | |
| maxPrice | No | Maximum nightly price in GBP. | |
| minPrice | No | Minimum nightly price in GBP. | |
| pageSize | No | ||
| petFriendly | No | Pets accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions real-time availability and return fields but lacks details on pagination limits, rate limits, or data freshness.
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 sentences covering purpose, filters, and critical usage guidance with no redundant information.
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 18 parameters and no output schema, description omits details on pagination cursor and sort behavior, leaving some gaps for complete understanding.
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 94%, so description adds limited value beyond emphasizing checkIn, checkOut, and guests usage.
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 verb 'Search' and resource 'self-catering villa rentals', and lists key filters, differentiating it from sibling tools like check_availability and get_villa_details.
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?
Provides explicit guidance to pass checkIn, checkOut, and guests when relevant, but does not explicitly distinguish when to use this tool versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_availabilityget_quoteget_villa_detailssearch_villasBook vacation rentals direct: search homes, check live availability, get a real total.
Search vacation rentals in La Palma, Canary Islands with real-time availability and pricing.
Search real estate auction properties across Europe with filtering by country, price, and ROI.
Search French mountain holiday rentals and contact owners directly — commission-free.
Add one secure layer between your agents and this server.
