mcp-server-airbnb: an MCP server that puts Airbnb search inside your AI client
Search Airbnb using your AI Agent
At a glance
- What is it?
- A JavaScript MCP server from openbnb-org that exposes two tools, airbnb_search and airbnb_listing_details, to any MCP-compatible client. The useful part is the filtering and pagination; the awkward part is that it scrapes a site whose robots.txt it also asks you to respect.
- Who is it for?
- Adopt this if you already run an MCP client and want Airbnb search results inside it without building a scraper, and if you accept that the server reads a public site rather than a documented API. Do not adopt it if you need booking, availability guarantees or any write operation: the two tools are read-only search and detail lookups.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 41 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap this fills: Airbnb has no public search API for agents
Airbnb does not publish a general-purpose search API that an AI agent can call. If you want an agent to answer "find a two-bedroom in Copenhagen for four adults under 200 a night," you either build a scraper yourself or you hand the agent a browser and hope. This project takes the first route and wraps it in the Model Context Protocol, so an MCP-compatible client can call it as a tool rather than driving a browser session. The audience is narrow and specific: developers and technically comfortable users who already run an MCP client such as Claude Desktop or Cursor and want listing data available inside that client. It is not aimed at end users who just want to book a trip, and the README is explicit about that, pointing readers who do not want to run a local server at the hosted openbnb.ai service instead. The repository is MIT licensed and written in JavaScript, distributed on npm as @openbnb/mcp-server-airbnb.
Two tools, and the parameters that actually shape a query
The server exposes exactly two tools. airbnb_search takes a required location string plus optional filters, and airbnb_listing_details takes a required listing id plus optional stay parameters. The search filters cover the ground you would expect: checkin and checkout in YYYY-MM-DD format, adults, children, infants and pets as separate counts, minPrice and maxPrice per night, a propertyType limited to entire_home, private_room, shared_room or hotel_room, and a cursor for pagination. The returns include property details, pricing, direct links, pagination information and the search URL that was used. Listing details return location with coordinates, amenities and facilities, house rules and policies, description and a link back to the listing. The amenities field is worth noting because the README describes it as seeAllAmenitiesGroups, an object rather than a flat list, which means any consumer of that field has to handle a nested structure. The README text supplied here is truncated mid-sentence at that point, so treat the exact shape of seeAllAmenitiesGroups as something to confirm against the live documentation before you write parsing code against it.
Geocoding is the design decision that matters most
The interesting mechanism is client-side geocoding. When you pass a location string without a placeId, the server resolves that string itself through Photon or Nominatim before querying Airbnb. The stated reason is international support: the README gives "Paris, France" and "Copenhagen, Denmark" as examples where non-US queries otherwise return results in the wrong city. There are two ways to avoid that third-party hop. You can pass a Google Maps placeId, which the README says overrides location and skips client-side geocoding entirely, so no third-party calls happen. Or you can set the DISABLE_GEOCODING environment variable to true, which the README describes as restoring pre-PR behaviour where every search goes only to airbnb.com. The README's own recommendation against disabling it is blunt: with geocoding off, non-US searches could return incorrect results. That is a real trade-off, not a hypothetical one. If your threat model or your network policy forbids outbound calls to Photon or Nominatim, you are choosing between a placeId you have to source yourself and degraded international accuracy.
Installing it: an MCPB file for Claude Desktop, npx for everything else
There are two installation paths and they are genuinely different. For Claude Desktop the project ships an MCP Bundle, a .mcpb file attached to the latest release. You download it, open it, and Claude Desktop presents an installation dialog, after which you configure the extension settings. The robots.txt override is a toggle in the extension settings rather than a config file edit. For Cursor and similar clients you install Node.js first, because npx is the launch mechanism, then add an entry under Cursor Settings, Tools & Integrations, New MCP Server. The README gives this mcp.json block: a mcpServers object with an airbnb key whose command is npx and whose args are "-y" and "@openbnb/mcp-server-airbnb". To bypass robots.txt for every request, append "--ignore-robots-txt" as a third argument. Two configuration surfaces exist and they do not overlap: the MCPB bundle exposes an Ignore robots.txt checkbox defaulting to false, and DISABLE_GEOCODING is documented as both a checkbox and an environment variable, also defaulting to false. The README's recommendation for both is to leave them alone unless you have a specific reason.
Robots.txt compliance is a toggle, which tells you what the server is doing
The project lists robots.txt compliance as a security and compliance feature, with a configurable override for testing. Read that alongside the --ignore-robots-txt flag and the per-request ignoreRobotsText parameter, and the architecture becomes clear: this server retrieves Airbnb pages on your behalf, and Airbnb's robots.txt is the thing that would otherwise stop it. The README frames the override as a testing measure and recommends keeping it disabled. That framing is honest, but it also means the default configuration may produce empty or partial results depending on what Airbnb's robots.txt currently permits. The README does not state what happens when a request is blocked, and the supplied text does not include a failure example, so the behaviour on a disallowed path is something you would have to observe yourself. The other stated safeguards are request timeout management, enhanced error handling with detailed logging, and rate limiting awareness. Those are described rather than specified: no default timeout value appears in the material, and no rate limit number is given.
Where it stops being the right tool
The obvious limitation is that there is no booking. Both tools read. You can search and you can inspect a listing, and the listing details include policies and house rules, but nothing in the documented surface reserves, holds or books anything. If your agent's job is to complete a transaction, this server gets you to the listing page and no further. The second limitation is the dependency on page structure. Nothing in the README describes a stable contract with Airbnb, and the release history (v0.1.4 in April 2026, v0.2.0 the same month, v0.3.0 in August 2026) suggests a project that is still adjusting, which is what you would expect from something that reads a site it does not control. The third is the geocoding dependency discussed above. The fourth is subtler: the README's own framing points at a hosted alternative with richer filters and interactive MCP UI components, so the open-source server is positioned as the base tier. That is a legitimate business model, but it means feature development may concentrate on the hosted product. Nothing in the material confirms or denies that, so weigh it as a question rather than a finding.
The alternative: run your own fetch and parsing layer
The realistic alternative is not another MCP server; it is a small script or service you write yourself that fetches Airbnb search pages and parses them, exposed to your agent however you prefer. The difference in approach is about where the maintenance burden sits. This project centralises the parsing, the geocoding step, the pagination cursor handling and the tool schemas, and you get all of that by adding four lines to mcp.json. A homegrown fetcher gives you control over the request headers, the caching, the retry policy and exactly which fields you extract, and it makes robots.txt handling an explicit decision in your own code rather than a checkbox in someone else's settings panel. It also means you own the breakage when Airbnb changes its markup. For a one-off internal tool, writing the fetcher is often less work than evaluating someone else's. For a team that wants the same capability in three different MCP clients, the server's packaging is the reason to use it. The hosted openbnb.ai service is the third option, and it removes the local process entirely at the cost of routing your queries through someone else's infrastructure.
Licence, maintenance and what to check before you commit
The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence and it does not impose copyleft obligations on your own code. It says nothing about Airbnb's terms of service, which are a separate question and not one this review can answer; if you plan to use the server in a product, that is a question for your own legal review rather than something the MIT grant resolves. On maintenance, the material shows three releases between April and August 2026 and a last push date matching the most recent release, so the project is active as of that date. The upgrade cost is low in the normal case: for Cursor-style installs, npx with the -y flag pulls the current version, so you get updates by restarting the client rather than by editing a lockfile. Claude Desktop users get updates through the .mcpb release file and have to reinstall. The two settings that can silently change your results are the robots.txt override and DISABLE_GEOCODING, and both default to false, so an upgrade that changes geocoding behaviour would show up as different search results rather than as an error. Pin a version if result stability matters more to you than fixes.
Editorial conclusion
Adopt this if you already run an MCP client and want Airbnb search results inside it without building a scraper, and if you accept that the server reads a public site rather than a documented API. Do not adopt it if you need booking, availability guarantees or any write operation: the two tools are read-only search and detail lookups. Before installing, check the current README for the geocoding behaviour, since the DISABLE_GEOCODING flag changes whether non-US results come back correctly, and confirm whether you are comfortable with the Photon/Nominatim outbound call or prefer to supply a placeId instead.
Community notes