Search and book luxury villa rentals across Europe with real-time availability and pricing.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 4 of 4 tools scored.
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_availabilityAInspectCheck 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_quoteAInspectGet 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_villa_detailsAInspectGet 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_villasAInspectSearch 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
