Search French mountain holiday rentals and contact owners directly — commission-free.
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.4/5 across 4 of 4 tools scored.
Each tool has a distinct purpose: search, view details, check availability/price, and send inquiry. No overlap in functionality.
All tool names follow a consistent verb_noun pattern with underscores, e.g., search_rentals, get_rental_details, check_availability_and_price, send_rental_inquiry.
4 tools is well-scoped for a rental assistant, covering search, details, availability/price check, and inquiry initiation without being too few or too many.
Covers the main workflow of finding and contacting owners; lacks tools for managing user inquiries or post-inquiry actions, but fits the direct-rental model without booking.
check_availability_and_priceVérifier la disponibilité et le prix d'un séjourAVérifie en une seule fois la disponibilité ET le prix d'un séjour daté pour une location (id renvoyé par search_rentals). Répond : disponible / occupé / partiellement disponible, le prix total du séjour (toujours indicatif, à confirmer par le propriétaire), un indicateur de fraîcheur du planning, et si le séjour est indisponible, jusqu'à 3 périodes libres proches de même durée.
| Name | Required | Description | Default |
|---|---|---|---|
| guests | No | Nombre de voyageurs (information indicative). | |
| date_end | Yes | Date de départ (YYYY-MM-DD). | |
| rental_id | Yes | Identifiant de la location (champ « id » des résultats de search_rentals). | |
| date_start | Yes | Date d'arrivée (YYYY-MM-DD). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description discloses the possible statuses (available/occupied/partially available), that price is indicative, a freshness indicator, and fallback free periods if unavailable. This adds valuable behavioral context.
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 a single sentence but well-structured, front-loading the main action and listing return fields. While slightly long, it is efficient and contains 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?
Despite no output schema, the description fully documents the return values (availability status, total price, freshness indicator, fallback periods). Combined with annotations, the tool is well-defined for a read-only query.
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 inline descriptions. The tool description does not add new meaning to parameters beyond stating rental_id comes from search_rentals and guests are indicative. 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 checks both availability and price in one call for a specific rental ID from search_rentals. It distinguishes from siblings by focusing on a combined check for a dated stay, whereas siblings handle searching, details, or inquiries.
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 implies usage after obtaining a rental ID from search_rentals and for a specific date range. It warns that the price is indicative and needs confirmation, providing a caveat. No explicit when-not-to-use or alternatives, but the sibling list and context are sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_rental_detailsConsulter la fiche détaillée d'une locationAFiche détaillée d'une location identifiée par l'id renvoyé par search_rentals : description, capacité et chambres, équipements, conditions de location (arrivée/départ, caution, acompte, annulation, animaux), avis voyageurs et lien vers la page du site. Les coordonnées du propriétaire ne sont jamais fournies : la mise en relation passe par le formulaire de contact du site (lien inclus).
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Langue de la description et du lien. | fr |
| rental_id | Yes | Identifiant de la location (champ « id » des résultats de search_rentals). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reinforces the read-only nature (annotations already indicate readOnlyHint) and adds that owner coordinates are never provided, directing contact through the site form.
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 a single focused paragraph, front-loading purpose and enumerating contents and limitations without wasting words.
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 the tool's complexity and lack of output schema, the description adequately covers what the tool returns, what it excludes, and how it relates to siblings.
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%, but the description adds context that rental_id comes from search_rentals, which aids correct usage 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 states it provides detailed rental info including description, capacity, rooms, equipment, conditions, reviews, and a link, and distinguishes itself from siblings by referencing the id from search_rentals.
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?
It explains to use the rental_id from search_rentals and mentions that owner coordinates are not provided, suggesting using the contact form. However, it does not explicitly state when not to use this tool versus check_availability_and_price.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_rentalsRechercher une location de vacances à la montagneARecherche des locations de vacances à la montagne en France parmi des milliers d'annonces (chalets, appartements, studios) louées en direct par leurs propriétaires — sans commission de réservation. Sans dates, les prix renvoyés sont des tarifs à la semaine ; avec des dates, le prix est le total du séjour demandé. Les prix sont indicatifs, à confirmer par le propriétaire. Chaque résultat contient un « id » à réutiliser avec get_rental_details et check_availability_and_price, et un lien vers la page du site à proposer à l'utilisateur.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page de résultats (10 par page). | |
| sort | No | Tri des résultats. Défaut : pertinence. | |
| guests | No | Nombre de voyageurs (capacité de couchage minimale). | |
| locale | No | Langue des libellés et des liens renvoyés. | fr |
| date_end | No | Date de départ (YYYY-MM-DD). Requise si date_start est fournie. | |
| amenities | No | Équipements exigés (tous devront être présents). | |
| budget_max | No | Budget maximum en euros pour le séjour (ou pour la semaine si pas de dates). | |
| date_start | No | Date d'arrivée (YYYY-MM-DD). Recommandé : les prix deviennent exacts et la disponibilité est prise en compte. | |
| destination | No | Station, massif, département ou domaine skiable français, en texte libre. Ex : "Les Gets", "Haute-Savoie", "Portes du Soleil". En cas d'ambiguïté le serveur propose des choix. Omettre pour chercher dans toutes les destinations. | |
| bedrooms_min | No | Nombre minimum de chambres. | |
| pets_allowed | No | true = uniquement les locations acceptant les animaux. | |
| flexible_days | No | Tolérance en jours autour des dates (0 = dates strictes). | |
| property_types | No | Types d'hébergement souhaités. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world. The description adds behavioral details about pricing (weekly vs total, indicative) and the structure of results (id, link). It does not contradict 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?
The description is concise, covering purpose, pricing, and result format in a few sentences. It is front-loaded with the main action. Could be slightly more structured but is 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?
Given the 13 parameters and no output schema, the description explains the essential behavior (pricing, result contents) and links to sibling tools. It does not cover all parameters, but the schema does. Adequate for the complexity.
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?
Input schema has 100% description coverage, so baseline is 3. The description adds context about date-related pricing behavior, but does not provide additional detail on individual parameters beyond what the schema already offers.
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 searches for mountain vacation rentals in France, listing property types (chalets, apartments, studios) and mentioning it's direct from owners with no booking fee. It distinguishes from siblings by noting that results contain an 'id' for use with get_rental_details and check_availability_and_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 provides context on when to use the tool (searching for rentals) and explains pricing behavior with and without dates, implying that for detailed info the other tools should be used. However, it does not explicitly state when not to use this tool or compare directly with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
send_rental_inquiryEnvoyer une demande de location au propriétaireAInspectTransmet une demande de contact au propriétaire d'une location (id renvoyé par search_rentals). IMPORTANT : avant d'appeler cet outil, obtenir la confirmation explicite de l'utilisateur pour (1) l'envoi de la demande et (2) la transmission de ses coordonnées (nom, email, téléphone éventuel) au propriétaire, puis passer user_confirmed=true. Le propriétaire répond ensuite directement à l'utilisateur par email — mise en relation sans commission, AUCUNE réservation ferme ni paiement via cet outil. Le message personnel (min. 30 caractères) doit être rédigé avec l'utilisateur.
| Name | Required | Description | Default |
|---|---|---|---|
| pets | No | Nombre d'animaux. | |
| Yes | Email de l'utilisateur — le propriétaire y répondra directement. | ||
| phone | No | Téléphone de l'utilisateur (optionnel — minimisation des données). | |
| adults | Yes | Nombre d'adultes. | |
| babies | No | Nombre de bébés. | |
| locale | No | Langue de la fiche consultée. | fr |
| message | Yes | Message personnel au propriétaire, rédigé avec l'utilisateur (min. 30 caractères). | |
| children | No | Nombre d'enfants. | |
| date_end | Yes | Date de départ (YYYY-MM-DD). | |
| last_name | Yes | Nom de famille de l'utilisateur. | |
| rental_id | Yes | Identifiant de la location (champ « id » des résultats de search_rentals). | |
| date_start | Yes | Date d'arrivée (YYYY-MM-DD). | |
| first_name | Yes | Prénom de l'utilisateur. | |
| user_confirmed | Yes | DOIT être true : l'utilisateur a explicitement confirmé l'envoi ET le partage de ses coordonnées avec le propriétaire. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description accurately discloses behavior: forwards contact, no commission, owner responds by email. No contradiction with 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?
The description is concise (3 key sentences) and front-loaded: first sentence states purpose, then important usage note, then behavioral summary. Every sentence adds value with no redundancy.
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?
The description covers purpose, usage prerequisites, and behavioral outcome (owner replies by email) without an output schema. It lacks explicit mention of error scenarios or return value, but this is acceptable for a simple contact tool.
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 baseline is 3. The description adds meaningful context for key parameters: user_confirmed must be true after confirmation, email is where owner replies, and message minimum length. This goes beyond schema descriptions.
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 sends a contact request to the rental owner, referencing the ID from search_rentals. It distinguishes itself from siblings (check_availability_and_price, get_rental_details, search_rentals) as the only inquiry tool.
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 states prerequisites: obtain user confirmation for sending and sharing contact details, then pass user_confirmed=true. It also clarifies what the tool does NOT do (no reservation or payment) and that the owner replies directly.
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!
