holidayforever
Server Details
Searchable directory of Airbnb listings — discover properties and retrieve direct Airbnb links.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 3.5/5 across 6 of 6 tools scored.
Each tool targets a distinct operation on listings (add, get, list, remove, search, update), with no functional overlap.
All tools follow a consistent verb_noun pattern using lowercase and underscores (e.g., add_listing, search_listings).
6 tools is an ideal size for a directory service, covering all essential CRUD operations plus search without unnecessary bloat.
The set provides full lifecycle management for listings (create, read, update, delete) and search, with no obvious gaps.
Available Tools
6 toolsadd_listingBInspect
Add an Airbnb listing to the directory.
Provide at minimum the Airbnb URL, a name, and a location. Extra metadata (price, guests, amenities, tags) improves search quality.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| name | Yes | ||
| tags | No | ||
| bedrooms | No | ||
| location | Yes | ||
| amenities | No | ||
| bathrooms | No | ||
| max_guests | No | ||
| description | No | ||
| property_type | No | ||
| price_per_night | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It does not mention side effects, idempotency, authorization needs, or what happens on duplicate submissions. The description is insufficient for safe agent decision-making.
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 three concise sentences with no superfluous content. It front-loads the purpose and immediately addresses minimum requirements, making it efficient 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?
Despite having an output schema, the description does not mention return values, error handling, or confirmation behavior. With 11 parameters and no detailed guidance on many of them, the description is incomplete for a complex creation 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 description coverage is 0%, so the description must compensate. It only partially explains parameters (required ones: url, name, location; optional extras like price, guests). It does not detail each parameter's meaning or constraints, leaving many parameters unexplored.
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 action ('Add an Airbnb listing to the directory') with a specific verb and resource. It distinguishes from sibling tools like get_listing, list_listings, etc., which perform different operations.
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 minimum required inputs ('URL, name, location') and encourages extra metadata, giving clear context for when to use the tool. However, it does not mention when not to use it or alternatives, limiting guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_listingBInspect
Get full details of an Airbnb listing by its ID, including the direct link.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation without explicit mutation warnings, but with no annotations, it provides minimal behavioral context. It notes the return includes a direct link but does not disclose any potential side effects or prerequisites.
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, front-loaded sentence with 14 words, efficiently conveying the core purpose without 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?
For a simple get-by-id tool with an output schema, the description is adequate but lacks guidance on parameter nuances and usage context, making it minimally complete.
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 has 0% description coverage for the 'id' parameter, and the description merely refers to 'its ID' without explaining the format, source, or constraints, leaving the agent to infer meaning.
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 'get' and the resource 'full details of an Airbnb listing by its ID', and distinguishes it from siblings like search_listings and list_listings by specifying retrieval of a single listing with a direct link.
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?
No guidance is provided on when to use this tool versus siblings. For instance, the description does not mention that this tool is ideal when you have a specific ID, while search_listings is for query-based lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_listingsAInspect
List all Airbnb listings in the directory with optional pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions pagination but does not disclose read-only nature, auth requirements, or behavior with large datasets. The behavior is simple, so score is adequate.
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 sentence of 8 words with no fluff. Every word is necessary and front-loaded.
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 a simple tool (2 optional params) and an output schema, the description is largely complete. It could mention that it returns all listings without user/workspace filtering, but the existence of output schema compensates.
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 0%, yet the description only vaguely references 'optional pagination' without defining limit or offset semantics. It adds minimal value beyond the schema's defaults.
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 'list', the resource 'Airbnb listings', and the scope 'in the directory', with optional pagination. This distinguishes it from sibling tools like 'search_listings' and 'get_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 implies use for getting all listings but does not explicitly guide when to use this vs 'search_listings' or other alternatives. No exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_listingBInspect
Remove an Airbnb listing from the directory by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only states 'Remove', implying mutation. It does not disclose whether the removal is permanent, reversible, or requires permissions, nor does it describe the output behavior.
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 concise sentence that immediately conveys the action and resource. No extraneous words or 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?
Despite having an output schema and low complexity, the description omits key details such as whether the removal is permanent, any side effects, or the output format. It fails to provide a complete picture for an agent.
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 schema has no description for the 'id' parameter (0% coverage). The description adds 'by its ID', clarifying the parameter's role. However, it does not specify the format or source of the ID, which is minimal compensation.
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 'Remove' and the resource 'Airbnb listing', and the phrase 'by its ID' specifies the input. This distinctly differentiates it from sibling tools like add_listing, update_listing, etc.
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 no guidance on when to use this tool versus alternatives. It does not mention when not to use it or suggest sibling tools for other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_listingsAInspect
Search the Airbnb directory. Returns matching listings with their URLs.
Combine any filters: location, price range, guest capacity, amenities,
tags, or a free-text query across name/description/location.| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| limit | No | ||
| query | No | ||
| location | No | ||
| amenities | No | ||
| min_guests | No | ||
| min_bedrooms | No | ||
| property_type | No | ||
| max_price_per_night | No | ||
| min_price_per_night | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions returning listings with URLs and lists filter types, but omits details like pagination, response format, or whether filters are combined with AND logic. Adequate but not thorough.
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 concise sentences with front-loaded purpose. First sentence states action and output, second explains versatility. 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 10 parameters and an output schema, the description covers main search functionality and filter combinations. It could mention optionality or default values, but is decent for a search 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 description coverage is 0%, so the description must compensate. It maps many parameters to categories (e.g., location, price range, guest capacity), adding meaning. However, parameters like min_bedrooms, property_type, and limit are not mentioned.
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 'Search the Airbnb directory' and specifies it returns listings with URLs. It distinguishes from sibling tools like add_listing, get_listing, etc., by being the search/filter 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?
The description says 'Combine any filters' indicating multiple parameters can be used, but does not explicitly differentiate from list_listings or provide when-to-use guidance. It implies usage but lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_listingBInspect
Update one or more fields of an existing Airbnb listing.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| url | No | ||
| name | No | ||
| tags | No | ||
| bedrooms | No | ||
| location | No | ||
| amenities | No | ||
| bathrooms | No | ||
| max_guests | No | ||
| description | No | ||
| property_type | No | ||
| price_per_night | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'update fields' without disclosing whether it performs a partial or full replacement, any side effects, authorization needs, or return behavior. The description lacks essential behavioral context for a mutation tool.
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, well-formed sentence that gets straight to the point. Every word serves a purpose, making it concise and front-loaded with the core action and resource.
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 12 parameters, 0% schema coverage, no annotations, and an output schema that could explain return values, the description is incomplete. It omits crucial details like partial update behavior, required id, and response format, leaving the agent to infer from the schema alone.
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 0%, and the description adds no detail beyond property titles (which are self-explanatory). It only generically mentions 'one or more fields' without explaining constraints, formats, or usage for each of the 12 parameters. The schema retains the burden of meaning.
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 'Update' and the resource 'existing Airbnb listing'. It distinguishes itself from sibling tools like add_listing (create), get_listing (read), list_listings (bulk), remove_listing (delete), and search_listings (query) by focusing on modification of an existing 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 implies usage when modifying a listing but provides no explicit guidance on when to use it versus alternatives. It does not mention that only specified fields are updated (partial update) or exclude scenarios like adding a new listing.
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.
Discussions
No comments yet. Be the first to start the discussion!