@openbnb/mcp-server-airbnb
Enables searching Airbnb listings with advanced filters such as location, dates, guests, price range, and property type, and retrieving detailed property information including amenities, house rules, policies, and direct listing links.
Click on "Deploy 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., "@@openbnb/mcp-server-airbnbFind entire home rentals in Lisbon for 2 guests in June, under $150 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.
Airbnb Search & Listings - MCP Bundle (MCPB)
A comprehensive MCP Bundle for searching Airbnb listings with advanced filtering capabilities and detailed property information retrieval. Built as a Model Context Protocol (MCP) server packaged in the MCP Bundle (MCPB) format for easy installation and use with compatible AI applications.
π Prefer not to run a local server? Try openbnb.ai
π openbnb.ai is a hosted MCP server that solves the same problem β searching Airbnb listings β without any local setup.
If you don't want to deal with installing and running this server yourself, openbnb.ai is a separate, fully-hosted alternative you can connect to directly from your MCP client. It goes beyond what this open-source server offers:
β Zero setup β no Node, no
npx, no config files, no updates to manageβ Advanced filters β richer search controls beyond the base tools here
β MCP UI β interactive UI components for browsing results, not just plain text
β Managed & maintained β kept running for you
Head to openbnb.ai for setup instructions and the connection details for your MCP client.
If you'd rather self-host the open-source server, read on.
Related MCP server: Airbnb MCP Server
Features
π Advanced Search Capabilities
Location-based search with support for cities, states, and regions
International location support via client-side geocoding, so non-US queries (e.g. "Paris, France", "Copenhagen, Denmark") return results in the right city
Google Maps Place ID integration for precise location targeting
Property type filtering for entire homes, private rooms, shared rooms, or hotel rooms
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
π Detailed Property Information
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
π‘οΈ Security & Compliance
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 MCPB user settings
Installation
For Claude Desktop
This extension is packaged as an MCP Bundle (.mcpb) file. To install:
Download the
.mcpbfile from the latest releaseOpen the file β Claude Desktop will show an installation dialog
Configure the extension settings as needed
To ignore robots.txt, open Claude Desktop settings, navigate to the extension, and enable the Ignore robots.txt toggle.
For Cursor, etc.
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-txtargs{ "mcpServers": { "airbnb": { "command": "npx", "args": [ "-y", "@openbnb/mcp-server-airbnb", "--ignore-robots-txt" ] } } }Restart.
Configuration
The extension provides the following user-configurable options:
Ignore robots.txt
Type: Boolean (checkbox)
Default:
falseDescription: Bypass robots.txt restrictions when making requests to Airbnb
Recommendation: Keep disabled unless needed for testing purposes
Disable third-party geocoding
Type: Boolean (checkbox)
Environment variable:
DISABLE_GEOCODINGDefault:
falseDescription: Skip the Photon/Nominatim geocoding step and let Airbnb resolve the location string on its own. Enabling this restores the pre-PR behavior β every search goes only to
airbnb.com, no third-party calls.Recommendation: Keep disabled unless you specifically need zero third-party outbound traffic. With it enabled, non-US searches could return incorrect results. See External Services.
Tools
airbnb_search
Search for Airbnb listings with comprehensive filtering options.
Parameters:
location(required): Location to search (e.g., "San Francisco, CA"). When supplied withoutplaceId, the server geocodes this string client-side via Photon/Nominatim β see External Services.placeId(optional): Google Maps Place ID. Overrideslocationand skips client-side geocoding entirely (no third-party calls).checkin(optional): Check-in date in YYYY-MM-DD formatcheckout(optional): Check-out date in YYYY-MM-DD formatadults(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 nightmaxPrice(optional): Maximum price per nightcursor(optional): Pagination cursor for browsing resultspropertyType(optional): Filter by property type βentire_home,private_room,shared_room, orhotel_roomignoreRobotsText(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_details
Get detailed information about a specific Airbnb listing.
Parameters:
id(required): Airbnb listing IDcheckin(optional): Check-in date in YYYY-MM-DD formatcheckout(optional): Check-out date in YYYY-MM-DD formatadults(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, as
seeAllAmenitiesGroupsβ an object keyed by amenity category, so a category can be addressed directly. Amenities Airbnb shows struck through arrive under its own"Not included"category:{ "seeAllAmenitiesGroups": { "Bathroom": "Hair dryer", "Heating and cooling": "AC - split type ductless system, Heating", "Not included": "Dryer, Hot water" } }House rules and policies
Property highlights and descriptions
Direct link to the listing
Technical Details
Architecture
Runtime: Node.js 18+
Protocol: Model Context Protocol (MCP) via stdio transport
Format: MCP Bundle (MCPB) v0.3
Dependencies: Minimal external dependencies for security and reliability
External Services
In addition to airbnb.com, the server makes geocoding requests to two third-party services to translate location queries into accurate map bounding boxes. This bypasses Airbnb's own server-side geocoder, which produces incorrect results for many non-US queries (e.g. "Paris, France" lands in VendΓ©e; "Copenhagen, Denmark" lands in Wisconsin).
Service | Endpoint | Used for | Notes |
| Primary geocoder, called on every search without | Free OSM-based service hosted by Komoot. One request per search. | |
| Fallback geocoder, called only when Photon does not return a bounding box | Subject to the OSMF usage policy (max ~1 req/sec). |
Each search sends only the location string from the request to the geocoder β no other request fields, no IP geolocation, no tracking identifiers. The location string itself is, of course, the same string the user typed.
Opting out: there are two ways to skip the geocoders:
Per-request: supply an explicit
placeId. WhenplaceIdis present, the server uses Airbnb's own place lookup directly with no third-party calls.Globally: set the environment variable
DISABLE_GEOCODING=true. The server will skip Photon/Nominatim entirely and pass the raw location string to Airbnb. This restores the pre-PR behavior for every search and guarantees zero third-party outbound traffic β at the cost of broken results for non-US locations that Airbnb's own geocoder mishandles. Defaults tofalse.
If a geocoder is unreachable or returns no result, the server falls back to sending the location string to Airbnb directly, exactly as it did before β so the worst case for an outage is that international searches degrade to the previous (broken) behavior, not that the search fails entirely.
Error Handling
Comprehensive error logging with timestamps
Graceful degradation when Airbnb's page structure changes
Timeout protection for network requests
Detailed error messages for troubleshooting
Security Measures
Robots.txt compliance by default
Request timeout limits
Input validation and sanitization
Secure environment variable handling
No sensitive data storage
Performance
Efficient HTML parsing with Cheerio
Request caching where appropriate
Minimal memory footprint
Fast startup and response times
Compatibility
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
Development
Building from Source
# Install dependencies
npm install
# Build the project
npm run build
# Watch for changes during development
npm run watchTesting
# Build, then run both suites
npm testnpm test drives the built server over stdio and calls the tools for real:
test-extension.jsβ MCP handshake, tool listing, a search, listing details, and the geocoding paths (Photon, Nominatim fallback)test-amenities.jsβ amenity extraction across several live listings, checking that amenities Airbnb strikes through never appear as ones the listing offers
Both hit airbnb.com and the geocoders over the network, so they need connectivity and can fail if Airbnb changes its page structure β that's the point of them, but it also means they aren't suitable as an unattended CI gate.
The server can also be run directly:
# Run with robots.txt compliance (default)
node dist/index.js
# Run with robots.txt ignored (for testing)
node dist/index.js --ignore-robots-txtLegal and Ethical Considerations
Respect 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
Support
Issues: Report bugs and feature requests on GitHub Issues
Documentation: Additional documentation available in the repository
Community: Join discussions about MCP and MCPB development
License
MIT License - see LICENSE file for details.
Contributing
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.
Available Tools
2 toolsairbnb_listing_detailsC
Get detailed information about a specific Airbnb listing. Provide direct links to the user
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The Airbnb listing ID | |
| pets | No | Number of pets | |
| adults | No | Number of adults | |
| checkin | No | Check-in date (YYYY-MM-DD) | |
| infants | No | Number of infants | |
| checkout | No | Check-out date (YYYY-MM-DD) | |
| children | No | Number of children | |
| ignoreRobotsText | No | Ignore robots.txt rules for this request |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavior. It mentions that direct links are provided, but does not disclose side effects, whether the operation is read-only, permission requirements, error behavior, or any other behavioral traits. This is a significant gap for a tool expected to be called autonomously.
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 at two sentences and the primary purpose is front-loaded. The second sentence about providing direct links is an added behavior, which is useful but could be integrated more seamlessly. No wasted words, though the structure could be tightened.
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 8 parameters, no output schema, and no annotations, the description is not complete. It does not explain what 'detailed information' includes, how the optional parameters influence results, or what the expected response format looks like. An agent would have to guess many details about invocation and results.
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?
All 8 parameters have descriptions in the schema (100% coverage), so the baseline of 3 applies. The tool description itself adds no additional meaning beyond what the schema already provides; it does not explain how parameters like pets, adults, or checkin/checkout dates affect the returned details or links.
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 detailed information for a specific Airbnb listing and identifies that direct links are provided. It distinguishes implicitly from the sibling airbnb_search by focusing on a specific listing rather than searching, though it does not explicitly name the sibling.
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 given on when to use this tool versus airbnb_search. There is no mention of prerequisites (such as having a listing ID) or scenarios that would favor this tool over the search sibling. The description leaves usage entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
airbnb_searchA
Search for Airbnb listings with various filters and pagination. Provide direct links to the user
| Name | Required | Description | Default |
|---|---|---|---|
| pets | No | Number of pets | |
| adults | No | Number of adults | |
| cursor | No | Base64-encoded string used for Pagination | |
| checkin | No | Check-in date (YYYY-MM-DD) | |
| infants | No | Number of infants | |
| placeId | No | Google Maps Place ID (overrides the location parameter) | |
| checkout | No | Check-out date (YYYY-MM-DD) | |
| children | No | Number of children | |
| location | Yes | Location to search for (city, state, etc.) | |
| maxPrice | No | Maximum price for the stay | |
| minPrice | No | Minimum price for the stay | |
| propertyType | No | Filter by property type: 'entire_home' (entire homes/apartments), 'private_room' (private rooms in shared homes), 'shared_room' (shared/dorm-style rooms), 'hotel_room' (hotel rooms) | |
| ignoreRobotsText | No | Ignore robots.txt rules for this request |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It does disclose a meaningful behavior beyond the schema: the tool provides direct links to the user. However, it does not mention the notable behavior around 'ignoreRobotsText' (ignoring robots.txt rules), nor any rate limits or implications of performing these searches.
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, front-loading the core action and then stating the expected output. It is efficient, though 'various filters' is somewhat vague and adds little information beyond the schema.
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 13 parameters and no output schema, the description is minimal. It covers the main purpose and the direct-link output, but it does not explain pagination behavior, the significance of the robots-related parameter, or how this tool relates to its sibling. The schema covers parameters well, so it is adequate but not 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?
Schema description coverage is 100%, so the baseline is 3. The description only says 'various filters and pagination,' which adds no meaningful parameter semantics beyond what the schema already provides for each parameter.
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 uses a specific verb and resource ('Search for Airbnb listings') and adds scope with 'various filters and pagination' and an explicit output ('Provide direct links to the user'). This clearly distinguishes it from the sibling tool airbnb_listing_details, which is about retrieving details rather than searching.
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 this tool is for searching listings rather than fetching details, so the intended use is partially clear from the contrast with the sibling tool. However, it never explicitly states when to use this tool versus airbnb_listing_details, nor does it mention any search-specific prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.3.0- First observed
airbnb_listing_details - First observed
airbnb_search
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: one performs searches across listings, the other fetches details for a specific listing. There is no overlap in functionality, so an agent can easily select the appropriate tool based on the task at hand.
Both tools follow a consistent 'airbnb_' prefix followed by a descriptive noun phrase (search, listing_details). The snake_case convention is uniform, and the verb-noun structure is clear and predictable, making the naming highly coherent.
With only two tools, the server feels thin for the broad domain of Airbnb. While search and details are foundational, a typical Airbnb workflow might also require booking, reviews, or availability checks. The count is borderline, as it is minimal but not trivial.
The tool surface covers only discovery (search and details) but lacks any transactional or deeper interaction capabilities such as booking, cancellation, or managing reservations. This is a significant gap that will prevent agents from completing full user journeys, making the surface incomplete for its apparent purpose.
Maintenance
Related MCP Connectors
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.
Give AI assistants access to real-time data. Search the web, compare flights, find hotels, and more.
Related MCP Servers
- AlicenseAqualityCmaintenanceSearch for Airbnb listings and get detailed information about specific properties. Effortlessly plan your next trip with structured data and no API key required, while respecting Airbnb's guidelines.421,273527MIT
- AlicenseBqualityDmaintenanceEnables searching for Airbnb listings and retrieving detailed accommodation information with direct links to Airbnb pages.21MIT
- AlicenseBqualityDmaintenanceEnables searching for Airbnb listings and retrieving detailed property information including pricing, amenities, and host details without requiring an API key.21,273MIT
- AlicenseCqualityDmaintenanceEnables searching Airbnb listings with advanced filtering (location, dates, guests, price) and retrieval of detailed property information including amenities, policies, and booking links.41,2732MIT