Enables searching for Airbnb listings with advanced filtering (location, dates, guests, price range) and retrieving detailed property information including amenities, policies, and house rules.
Supports Google Maps Place ID integration for precise location targeting when searching Airbnb listings.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Airbnb Search & Listings find a 2-bedroom apartment in Paris for 4 guests from June 15-22 under $200 per night"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A comprehensive Desktop Extension for searching Airbnb listings with advanced filtering capabilities and detailed property information retrieval. Built as a Model Context Protocol (MCP) server packaged in the Desktop Extension (DXT) format for easy installation and use with compatible AI applications.
Location-based search with support for cities, states, and regions
Google Maps Place ID integration for precise location targeting
Date filtering with check-in and check-out date support
Guest configuration including adults, children, infants, and pets
Price range filtering with minimum and maximum price constraints
Pagination support for browsing through large result sets
Comprehensive listing details including amenities, policies, and highlights
Location information with coordinates and neighborhood details
House rules and policies for informed booking decisions
Property descriptions and key features
Direct links to Airbnb listings for easy booking
Robots.txt compliance with configurable override for testing
Request timeout management to prevent hanging requests
Enhanced error handling with detailed logging
Rate limiting awareness and respectful API usage
Secure configuration through DXT user settings
Related MCP server: Airbnb MCP Server
This extension is packaged as a Desktop Extension (DXT) file. To install:
Download the .dxt file from the releases page
Open your compatible AI application (e.g., Claude Desktop)
Install the extension through the application's extension manager
Configure the extension settings as needed
Before starting make sure Node.js is installed on your desktop for npx to work.
Go to: Cursor Settings > Tools & Integrations > New MCP Server
Add one the following to your mcp.json:
{
"mcpServers": {
"airbnb": {
"command": "npx",
"args": [
"-y",
"@openbnb/mcp-server-airbnb"
]
}
}
} To ignore robots.txt for all requests, use this version with --ignore-robots-txt args
{
"mcpServers": {
"airbnb": {
"command": "npx",
"args": [
"-y",
"@openbnb/mcp-server-airbnb",
"--ignore-robots-txt"
]
}
}
}Restart.
The extension provides the following user-configurable options:
Type: Boolean (checkbox)
Default: false
Description: Bypass robots.txt restrictions when making requests to Airbnb
Recommendation: Keep disabled unless needed for testing purposes
airbnb_searchSearch for Airbnb listings with comprehensive filtering options.
Parameters:
location (required): Location to search (e.g., "San Francisco, CA")
placeId (optional): Google Maps Place ID (overrides location)
checkin (optional): Check-in date in YYYY-MM-DD format
checkout (optional): Check-out date in YYYY-MM-DD format
adults (optional): Number of adults (default: 1)
children (optional): Number of children (default: 0)
infants (optional): Number of infants (default: 0)
pets (optional): Number of pets (default: 0)
minPrice (optional): Minimum price per night
maxPrice (optional): Maximum price per night
cursor (optional): Pagination cursor for browsing results
ignoreRobotsText (optional): Override robots.txt for this request
Returns:
Search results with property details, pricing, and direct links
Pagination information for browsing additional results
Search URL for reference
airbnb_listing_detailsGet detailed information about a specific Airbnb listing.
Parameters:
id (required): Airbnb listing ID
checkin (optional): Check-in date in YYYY-MM-DD format
checkout (optional): Check-out date in YYYY-MM-DD format
adults (optional): Number of adults (default: 1)
children (optional): Number of children (default: 0)
infants (optional): Number of infants (default: 0)
pets (optional): Number of pets (default: 0)
ignoreRobotsText (optional): Override robots.txt for this request
Returns:
Detailed property information including:
Location details with coordinates
Amenities and facilities
House rules and policies
Property highlights and descriptions
Direct link to the listing
Runtime: Node.js 18+
Protocol: Model Context Protocol (MCP) via stdio transport
Format: Desktop Extension (DXT) v0.1
Dependencies: Minimal external dependencies for security and reliability
Comprehensive error logging with timestamps
Graceful degradation when Airbnb's page structure changes
Timeout protection for network requests
Detailed error messages for troubleshooting
Robots.txt compliance by default
Request timeout limits
Input validation and sanitization
Secure environment variable handling
No sensitive data storage
Efficient HTML parsing with Cheerio
Request caching where appropriate
Minimal memory footprint
Fast startup and response times
Platforms: macOS, Windows, Linux
Node.js: 18.0.0 or higher
Claude Desktop: 0.10.0 or higher
Other MCP clients: Compatible with any MCP-supporting application
# Install dependencies
npm install
# Build the project
npm run build
# Watch for changes during development
npm run watchThe extension can be tested by running the MCP server directly:
# Run with robots.txt compliance (default)
node dist/index.js
# Run with robots.txt ignored (for testing)
node dist/index.js --ignore-robots-txtRespect Airbnb's Terms of Service: This extension is for legitimate research and booking assistance
Robots.txt Compliance: The extension respects robots.txt by default
Rate Limiting: Be mindful of request frequency to avoid overwhelming Airbnb's servers
Data Usage: Only extract publicly available information for legitimate purposes
Issues: Report bugs and feature requests on GitHub Issues
Documentation: Additional documentation available in the repository
Community: Join discussions about MCP and DXT development
MIT License - see LICENSE file for details.
Contributions are welcome! Please read the contributing guidelines and submit pull requests for any improvements.
Note: This extension is not affiliated with Airbnb, Inc. It is an independent tool designed to help users search and analyze publicly available Airbnb listings.
Get detailed information about a specific Airbnb listing. Provide direct links to the user
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The Airbnb listing ID | |
| checkin | No | Check-in date (YYYY-MM-DD) | |
| checkout | No | Check-out date (YYYY-MM-DD) | |
| adults | No | Number of adults | |
| children | No | Number of children | |
| infants | No | Number of infants | |
| pets | No | Number of pets | |
| ignoreRobotsText | No | Ignore robots.txt rules for this request |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'Get[s] detailed information,' implying a read-only operation, but doesn't address critical aspects like authentication requirements, rate limits, error handling, or what 'detailed information' includes (e.g., pricing, availability, amenities). The mention of 'direct links' hints at output behavior but is vague. For a tool with 8 parameters and no annotation coverage, this is insufficient.
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 with two short sentences that are front-loaded with the core purpose. There's no wasted text, and it efficiently communicates the basic function. However, the second sentence ('Provide direct links to the user') is somewhat vague and could be integrated more smoothly, slightly reducing clarity.
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 complexity (8 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits (e.g., data sources, latency), output format (what 'detailed information' entails), and usage context. Without annotations or an output schema, the description should do more to guide the agent, such as explaining the return structure or common use cases, but it falls short.
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 description coverage is 100%, meaning all parameters are documented in the input schema (e.g., 'id' as listing ID, dates in YYYY-MM-DD format). The description adds no additional parameter semantics beyond what's in the schema, such as explaining how parameters interact (e.g., how dates affect pricing) or clarifying optional vs. required usage. Given the high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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's purpose as 'Get detailed information about a specific Airbnb listing,' which includes a specific verb ('Get') and resource ('Airbnb listing'). However, it doesn't explicitly differentiate from sibling tools like 'airbnb_search' (which likely searches multiple listings) or 'analyzeListingPhotos' (which focuses on photos). The mention of 'direct links' adds some specificity but doesn't fully distinguish it from siblings.
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 like 'airbnb_search' or 'analyzeListingPhotos.' It mentions providing 'direct links to the user,' which implies a use case for sharing information, but doesn't specify prerequisites, exclusions, or contextual triggers. This leaves the agent with minimal direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Airbnb listings with various filters and pagination. Provide direct links to the user
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | Location to search for (city, state, etc.) | |
| placeId | No | Google Maps Place ID (overrides the location parameter) | |
| checkin | No | Check-in date (YYYY-MM-DD) | |
| checkout | No | Check-out date (YYYY-MM-DD) | |
| adults | No | Number of adults | |
| children | No | Number of children | |
| infants | No | Number of infants | |
| pets | No | Number of pets | |
| minPrice | No | Minimum price for the stay | |
| maxPrice | No | Maximum price for the stay | |
| cursor | No | Base64-encoded string used for Pagination | |
| ignoreRobotsText | No | Ignore robots.txt rules for this request |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'pagination' (implied via the 'cursor' parameter) and 'Provide direct links to the user' which adds some context about output behavior. However, it lacks critical details such as rate limits, authentication requirements, error handling, or what the search results include (e.g., listing summaries vs. full details). For a search tool with 12 parameters, this is insufficient.
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, efficient sentence that front-loads the core purpose ('Search for Airbnb listings') and includes key features. It avoids unnecessary words, though it could be slightly more structured by separating functional aspects from output instructions. Every part earns its place, but it's not perfectly optimized for quick scanning.
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 complexity (12 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return format beyond 'direct links', leaving the agent uncertain about what data is provided (e.g., listings, prices, availability). For a search tool with rich filtering options, more context on results and behavior is needed to be fully helpful.
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 100%, so the schema already documents all 12 parameters thoroughly. The description adds minimal value by mentioning 'various filters and pagination', which aligns with parameters like 'minPrice', 'maxPrice', and 'cursor', but doesn't provide additional semantics beyond what the schema states. Baseline 3 is appropriate as the schema does the heavy lifting.
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 ('Airbnb listings'), and mentions key capabilities ('various filters and pagination'). It distinguishes from sibling tools like 'airbnb_listing_details' by focusing on search rather than detailed information retrieval. However, it doesn't explicitly differentiate from 'analyzeListingPhotos' or 'getListingPhotos' which might also involve search-related functions.
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 like 'airbnb_listing_details' for specific listings, or how it relates to photo analysis tools. It mentions 'Provide direct links to the user' which hints at output format but doesn't clarify usage context or exclusions. No explicit when/when-not statements are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze photos from an Airbnb listing
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Airbnb listing ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool analyzes photos but doesn't describe what the analysis entails (e.g., returns scores, detects objects), potential side effects (e.g., rate limits, data processing), or output format. This is a significant gap for a tool with no structured behavioral hints.
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, efficient sentence that directly states the tool's function without unnecessary words. It is appropriately sized for a simple tool, though it could be more front-loaded with key details like analysis type. There's no wasted text, earning a high score for conciseness.
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 has no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what the analysis returns, how results are structured, or any behavioral traits like error handling. For a tool that presumably performs non-trivial photo analysis, this leaves critical gaps in understanding its operation.
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 description coverage is 100%, with the single parameter 'id' documented as 'Airbnb listing ID'. The description doesn't add any meaning beyond this, such as format examples or constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though no extra value is added.
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 states the action ('analyze') and resource ('photos from an Airbnb listing'), which provides a basic understanding of purpose. However, it lacks specificity about what analysis is performed (e.g., quality assessment, content detection) and doesn't distinguish from sibling tools like 'getListingPhotos' that might retrieve photos without analysis. This makes it vague but not tautological.
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 alternatives. The description doesn't mention prerequisites, context (e.g., after fetching listing details), or comparisons to siblings like 'airbnb_listing_details' or 'getListingPhotos'. This leaves the agent without direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract photo URLs from an Airbnb listing
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Airbnb listing ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no information on rate limits, authentication needs, error handling, or what happens if the listing ID is invalid. For a tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized for a simple tool and front-loads the core purpose immediately.
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 tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., format of extracted URLs, whether it's a list or structured data), nor does it cover behavioral aspects like error conditions. Given the lack of structured data, the description should provide more context to be fully helpful.
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 description coverage is 100%, with the single parameter 'id' clearly documented as 'Airbnb listing ID'. The description doesn't add any parameter details beyond what the schema provides, so it meets the baseline for high schema coverage but doesn't enhance understanding of parameter usage or constraints.
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 ('Extract') and resource ('photo URLs from an Airbnb listing'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'analyzeListingPhotos' which might involve more complex photo analysis rather than just URL extraction.
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 like 'airbnb_listing_details' (which might include photos) or 'analyzeListingPhotos'. It doesn't mention prerequisites, constraints, or typical use cases, leaving the agent to infer usage context.
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. Dates show when Glama detected each change.
airbnb_listing_detailsairbnb_searchanalyzeListingPhotosgetListingPhotosThe tools have some overlap that could cause confusion, particularly between 'analyzeListingPhotos' and 'getListingPhotos' which both handle listing photos but with different purposes (analysis vs. extraction). However, 'airbnb_listing_details' and 'airbnb_search' are clearly distinct for specific listing retrieval and general search, respectively, and descriptions help clarify the photo-related tools.
Naming is inconsistent with mixed conventions: 'airbnb_listing_details' and 'airbnb_search' use snake_case with a prefix, while 'analyzeListingPhotos' and 'getListingPhotos' use camelCase without the prefix. This lack of a predictable pattern across all tools makes the set less coherent and harder for agents to navigate intuitively.
With 4 tools, the count is borderline for the server's purpose of Airbnb search and listings. It feels thin, as core operations like booking, user reviews, or price updates are missing, but it covers basic search and listing details, which might be sufficient for a limited scope. A typical server in this domain would benefit from more tools to handle a fuller lifecycle.
There are significant gaps in the tool surface for the Airbnb domain. While search and listing details are covered, essential operations like booking a listing, managing reservations, accessing user reviews, or updating pricing are missing. This incompleteness will likely cause agent failures when trying to perform common tasks beyond basic lookup and photo analysis.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Airbnb stays by location and dates, and full listing details, as structured JSON.
Searchable directory of Airbnb listings — discover properties and retrieve direct Airbnb links.
Vacation rental discovery, direct booking, and property protection for AI agents.
Booking.com stays by destination and dates, and full property details, as structured JSON.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/iclickfreedownloads/mcp-server-airbnb'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
