Airbnb MCP Server
This server gives MCP clients two read-only Airbnb tools for searching stays and reading full listing details from public pages.
Search Airbnb listings by location, check-in/check-out dates, and guest composition (adults, children, infants, pets).
Paginate through search results with
nextPageTokenand get structured data: listing id/url, title, coordinates, photos, rating, review count, badges, and price details.Fetch full property details by listing URL, including room/bed/bath counts, full description, address, amenities with availability, safety info, and host profile (Superhost status, verification, rating, years hosting).
Use the server remotely via a URL and HasData API key, with integrations for Claude, Cursor, Windsurf, VS Code, and other MCP clients.
No Airbnb developer account or partner approval is needed; all data comes from public Airbnb pages.
Provides read-only tools for searching Airbnb stays by location and dates, and retrieving full listing details including amenities, host information, pricing, and property overview.
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 MCP ServerFind me an Airbnb in Paris for next weekend under $150 a 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 MCP Server
A hosted Model Context Protocol (MCP) server that gives Claude, Cursor, Windsurf and any other MCP client two read-only Airbnb tools. Search stays by location and dates, and read a single listing in full, all as structured JSON, with no Airbnb developer account and no partner approval.
It reads public listing pages that a signed-out visitor can see.
https://mcp.hasdata.com/api/mcp?apis=airbnb
Contents
Related MCP server: lilo-vacation-rentals
What you need
An MCP client and a HasData API key from the dashboard, free to create with no card, and the trial covers about 200 calls at the 5-credit rate. This is a remote server, so the simplest path is a URL and an x-api-key header, with no container to run and no Airbnb developer account anywhere in the flow. A client that only speaks stdio reaches it through a thin launcher, published as @hasdata/airbnb-mcp on npm and hasdata-airbnb-mcp on PyPI, shown below.
Quick start
The server URL is the same for every client. We run it hands-on in Claude Code and Claude Desktop. The other blocks follow each client's own documented format for a remote server.
Field | Value |
URL |
|
Transport | HTTP, streamable |
Auth header |
|
Clients with OAuth support can add the same URL as a connector and sign in without putting a key in a config file.
claude mcp add --transport http airbnb "https://mcp.hasdata.com/api/mcp?apis=airbnb" \
--header "x-api-key: HASDATA_API_KEY"Settings, then Connectors, then Add custom connector, then paste https://mcp.hasdata.com/api/mcp?apis=airbnb and sign in.
For the config-file route, Claude Desktop loads only local (stdio) servers, so it reaches a remote server through a stdio launcher. The @hasdata/airbnb-mcp package is that launcher, and it reads the key from the environment. Add this to claude_desktop_config.json:
{
"mcpServers": {
"airbnb": {
"command": "npx",
"args": ["-y", "@hasdata/airbnb-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}For Python instead of Node, swap the launcher for the PyPI package, which uvx runs without a manual install:
{
"mcpServers": {
"airbnb": {
"command": "uvx",
"args": ["hasdata-airbnb-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}~/.cursor/mcp.json for every project, or .cursor/mcp.json for one:
{
"mcpServers": {
"airbnb": {
"url": "https://mcp.hasdata.com/api/mcp?apis=airbnb",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}~/.codeium/windsurf/mcp_config.json. Windsurf calls the field serverUrl, not url:
{
"mcpServers": {
"airbnb": {
"serverUrl": "https://mcp.hasdata.com/api/mcp?apis=airbnb",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}.vscode/mcp.json in the workspace:
{
"servers": {
"airbnb": {
"type": "http",
"url": "https://mcp.hasdata.com/api/mcp?apis=airbnb",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}Example prompts
Prompts, not code. Paste one in and the agent picks the tool itself. Each is annotated with the calls it takes, because every successful call costs 5 credits.
Search Austin stays for two adults from September 15 to 18 and give me the ten highest-rated under $200 a night.
One call, 5 credits. Rating and nightly price come back on the search result.
Take the top result and pull its full amenities, the guest and bedroom count, and the host details.
One call, 5 credits. Those live on the property page, which the details tool reads by URL.
Compare the nightly price of a three-night stay for two guests in Austin against Nashville.
Two calls, 10 credits, one search per city.
For this listing URL, tell me how many beds and baths it has and whether the host is a Superhost.
One call, 5 credits.
A search result is deliberately light, enough to rank and shortlist. The amenities, beds, host and full description come from the property call, so a prompt that shortlists then inspects three homes is one search plus three property calls.
Tools
Two tools, read-only. Samples below are trimmed from real calls, and the numbers move as Airbnb updates. Read them as shapes. Each tool name links to its endpoint reference, which carries the full field list.
The samples are the payload, not the whole response. A tools/call result carries one text block, and that text is itself JSON holding url, status, text and json, with the scraped data under json. From a raw JSON-RPC response the path is result.content[0].text, parsed, then .json. A chat client unwraps that for you and code talking to the endpoint directly does not.
Get Airbnb listings
hasdata_airbnb_listing_getAirbnbListings
A page of search results by location and dates.
Parameter | Type | Required | Notes |
| string | yes | The place to search, such as |
| string | yes | Check-in date, |
| string | Check-out date, | |
| number | Guest composition, each a count | |
| string | The |
Returns a properties array and pagination, whose nextPageToken and pageTokens walk the result set. Each property carries id, url, title, latitude, longitude, a short description tagline, a photos array, rating, reviews, a badges array such as Guest favorite or Superhost, and a price object. price holds originalPrice, an optional discountedPrice when the stay is discounted, a qualifier like for 3 nights, and a breakdown.
A search result is intentionally light. Beds, baths, amenities, the host and the full description are not here, they come from the property tool below. Do not expect a bedroom count on a search result.
{
"id": "17545365",
"url": "https://www.airbnb.com/rooms/17545365",
"title": "Home in East Austin",
"latitude": 30.25741,
"longitude": -97.73366,
"description": "Downtown Casa - neighborhood feel, close to it all",
"rating": 4.87,
"reviews": 601,
"badges": ["Guest favorite"],
"price": {
"originalPrice": "$607",
"discountedPrice": "$447",
"qualifier": "for 3 nights",
"breakdown": [{ "description": "3 nights x $149.00", "price": "$447.00" }]
}
}Get Airbnb property details
hasdata_airbnb_property_getAirbnbPropertyDetails
One listing in full, by its URL.
Parameter | Type | Required | Notes |
| string | yes | An Airbnb listing URL, the |
Returns title, an overview array like ["4 guests", "2 bedrooms", "2 beds", "2 baths"], the full description, rating, reviews, address, latitude, longitude, a photos array, guestCapacity, a host object, an amenities array, and safetyAndPropertyInfo. The host object carries name, isSuperhost, isVerified, the host's own reviews, rating and yearsHosting. Each amenity carries a title, a type, an optional description and an available flag, so a filter reads available, it does not assume every listed amenity is present.
{
"id": "17545365",
"title": "Downtown Casa - neighborhood feel, close to it all",
"overview": ["4 guests", "2 bedrooms", "2 beds", "2 baths"],
"rating": 4.87,
"reviews": 601,
"address": "Austin, Texas, United States",
"guestCapacity": 4,
"host": { "name": "Deanna", "isSuperhost": true, "isVerified": true, "reviews": 1273, "rating": 4.86, "yearsHosting": 11 },
"amenities": [
{ "title": "Wifi", "type": "SYSTEM_WI_FI", "available": true },
{ "title": "Free washer – In unit", "type": "SYSTEM_WASHER", "available": true }
]
}Errors and failure paths
Your client almost never sees an HTTP error code from a tool call. The MCP layer answers 200 and puts the failure inside the result, with isError set to true and the reason as text. The agent reads a message where you might expect a status line.
A wrong key surfaces as tool output, not as a failed connection. tools/list accepts any non-empty key and returns both tools, so the client completes its handshake and shows green. The first tool call then comes back with isError: true and the text HasData API error: 401 Unauthorized. Watch for that string, because nothing earlier in the flow reports the problem.
A missing key is the one real HTTP error. Authorization runs before any tool, and the connection itself fails with 401. CORS headers are present, and a browser client reads the status and not an opaque network failure.
An argument that breaks a tool's schema is rejected before it becomes a scrape. The server answers with isError: true and the text MCP error -32602: Input validation error, naming the offending field. Nothing is fetched and nothing is charged.
A search with no availability returns a successful result with an empty properties array, not an error. A location and date range with nothing open still comes back with requestMetadata.status set to ok. Test for the array length before you iterate.
A listing that has been removed returns 400 with requestMetadata.status set to error. A URL from an old search can point at a home that is gone.
Results that carry data also carry a requestMetadata.id worth quoting in support.
Pricing, free tier and limits
Each Airbnb tool costs 5 credits per successful call. Response size does not change the price. A search page with dozens of stays costs the same as one with two.
The free trial is 1,000 credits over 30 days with no card, which is 200 Airbnb calls. After that an active account keeps getting 100 credits topped up each day whenever its balance drops below 100, so a low-volume agent runs on the free tier indefinitely.
Paid plans start at $49 a month for 200,000 credits, which is 40,000 calls. The unit price falls with volume, from $1.23 per 1,000 calls on the entry plan to $0.50 on Business, $0.42 on Growth and $0.37 on the largest high-volume plans.
Your plan also sets concurrency. The free trial allows 1 request at a time, Startup 15, Business 30, Growth 50, and the high-volume plans run from 200 to 1,500. Handle the overflow case defensively in anything unattended.
A request that comes back non-200 is not billed. A successful call that finds nothing is still a call.
Tool selection
The apis query parameter decides which tools your agent sees. Fewer tools means less context spent on tool definitions, and fewer chances for the model to reach for the wrong one.
?apis=airbnb the two tools in this repo
?apis=airbnb,booking add Booking.com stays
?apis=airbnb,google_maps add Google Maps placesThe parameter takes provider names like airbnb and individual API names like airbnb_listing. Misspelled names are ignored. If every name is wrong the request fails with 400, and the body lists both what it did not recognise and every valid value. Drop the parameter and the same endpoint exposes all 57 HasData tools.
How it compares
Airbnb has no public search API. Its API program is a partner and co-host integration for managing your own listings, not a way to read the market. For searching stays and reading arbitrary listings, scraping the public pages is the only route, and this server does that behind a stable schema.
Airbnb partner API | This server | |
Purpose | Manage your own listings | Read the public market |
Access | Partner approval | One key and one URL |
Search across the market | No | Yes |
Setup | Business onboarding | None |
Output | Partner payloads | Structured JSON, price and rating pre-parsed |
What this server does not do. No booking, no messaging, no host dashboard, no guest data. It reads what a signed-out visitor can see.
FAQ
Is there an official Airbnb MCP server?
Airbnb does not publish one. This one is maintained by HasData and reads public pages, which is why it needs no Airbnb developer account.
What is an Airbnb MCP server?
A server that exposes Airbnb data as tools an AI client can call. The client sends a tool call over the Model Context Protocol, the server fetches the data and returns structured JSON, and the model works with the result. This one exposes two tools and runs remotely.
Do I need an Airbnb API key or partner account?
No. The only credential is your HasData key. There is no partner onboarding, because the tools read public Airbnb pages.
Why does the search result not show beds or amenities?
Because Airbnb does not put them on the search card. They live on the property page, which the details tool reads by URL. Search to shortlist, then call the property tool for depth.
Can I filter by guests, pets or dates?
Yes. The listing tool takes checkIn, checkOut and the adults, children, infants and pets counts, and returns availability and pricing for that party and window.
Can I use this together with other HasData APIs?
Yes. The apis parameter takes a list, and ?apis=airbnb,booking gives your agent Airbnb plus Booking.com. Drop the parameter and you get everything.
Compliance and personal data
HasData accesses publicly available data only. A platform's terms may restrict automated access, and you are responsible for your own compliance. Where the data you collect includes personal information, make sure you have a lawful basis for it under GDPR, CCPA or the equivalent rules in your jurisdiction.
HasData links
Product page and request builder | |
Server documentation | |
All 57 tools in one server | |
Client walkthroughs | |
Everything else we scrape | |
Plans and credit costs | |
Keys and usage | |
Node launcher on npm | |
Python launcher on PyPI |
Development
This repository is configuration and documentation for a remote server. There is no build step and nothing to containerize.
The tests in test/ assert the tool contract, the part that can break without a commit here. They check that ?apis=airbnb returns exactly two tools, that every tool still declares its required parameters, that no name changed, and that the key in use is actually accepted. That last check calls a tool for real and costs 5 credits, which is the price of a canary that can fail for the right reason.
# macOS and Linux
HASDATA_API_KEY=your_key_here npm test
# Windows PowerShell
$env:HASDATA_API_KEY="your_key_here"; npm testThe same suite runs in CI on every push and once a week on a schedule, because the upstream tool list can change without anyone touching this repository. A failure means the tool list moved, the key stopped working, or the endpoint was unreachable, and the assertion message says which.
Contributing
Corrections to the tool tables and the response samples are the most useful contribution, because those are the parts that drift. Include the call you made and the response you got. Pull requests from forks run the suite without a key, and the live checks skip instead of going red.
License
MIT. See LICENSE.
Available Tools
2 toolshasdata_airbnb_listing_getAirbnbListingsairbnb_listing: GET /AInspect
Get Airbnb Listings
Searches Airbnb for available stays by location and date range (check-in/check-out) with guest composition (adults, children, infants, pets) and nextPageToken pagination. Returns listing id/url, title, price per night and total, rating, review count, coordinates, photos, host info, room/bed/bath counts, and amenities summary. Use for travel planning agents, short-term rental market analysis, pricing/occupancy research, and lead lists for property management.
| Name | Required | Description | Default |
|---|---|---|---|
| pets | No | Number of pets. | |
| adults | No | Number of adults. | |
| checkIn | Yes | The check-in date for the listings. | |
| infants | No | Number of infants. | |
| checkOut | No | The check-out date for the listings. | |
| children | No | Number of children. | |
| location | Yes | The location to search for listings. | |
| nextPageToken | No | The token used to retrieve the next page of results. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it explains that the tool searches Airbnb and returns a broad set of listing fields, including pagination via nextPageToken. However, it does not disclose behavioral limits such as page size, data freshness, errors, or any hidden constraints.
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 mostly compact and front-loaded, listing the purpose, inputs, return attributes, and use cases. The opening 'Get Airbnb Listings' is slightly redundant with the tool name/title, but not enough to hurt the overall presentation seriously.
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 read-style tool with no output schema and no annotations, the description covers all essential aspects: what triggers it, what it returns, and examples of appropriate usage. Limitations such as default page size, location/date formats, and error handling are missing, but not critical for correct invocation.
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%, and the description only paraphrases already-documented inputs (location, date range, guests, pets, pagination). It adds no real additional syntax, formats, or nuances beyond schema descriptions for the 8 parameters, so the baseline of 3 applies.
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 how to search for listings and what it returns. It is specific about the resource (Airbnb listings) and verbs (searches/listings), but it does not explicitly distinguish itself from the sibling tool 'property details', leaving the boundary slightly implicit.
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 names several concrete use cases including travel planning, rental market analysis, pricing/occupancy research, and property management. It does not give exclusion criteria or explicitly compare with the property details sibling, so it receives a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hasdata_airbnb_property_getAirbnbPropertyDetailsairbnb_property: GET /AInspect
Get Airbnb Property Details
Fetches the full Airbnb property page by listing URL. Returns title, description, location, coordinates, price breakdown, cleaning/service fees, rating and review distribution, host profile, room/bed/bath counts, photos, amenities list, house rules, cancellation policy, and availability calendar hints. Use for travel-planning agents, deep-dive rate research, photo/amenity enrichment of listings discovered via the listing-search endpoint, and LSTR compliance or market-quality audits.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the Airbnb listing. Must be a valid Airbnb listing URL. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description itself communicates read-only fetch behavior: 'Fetches the full Airbnb property page' and the title 'GET /' reinforce that no state change occurs. It also documents the expected response scope, though it does not cover optional caveats such as rate limits, stale data, or invalid URL handling.
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 efficient and front-loaded with the primary behavior, followed by a compact but useful list of returned fields and use cases. The long return-value list earned to be somewhat dense, but it is made of specific useful information rather than 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?
For a one-parameter fetch tool without output schema, this description supplies strong coverage of what the tool returns and why it should be used. It could be even more complete with an explicit 'if you need richer listing search, use getAirbnbListings' condition, but overall it gives the agent nearly everything needed to route and invoke it correctly.
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 single `url` parameter is already fully described in the schema. The description adds meaning by connecting the URL to the action ('fetches by listing URL'), but it does not provide example formats, normalization rules, or other parameter-level insight beyond what the schema already exposes.
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 explicitly states what the tool does: it fetches a complete Airbnb property details by listing URL and gives a concrete list of returned fields. It also contrasts itself with the listing-search sibling by framing the request as an enrichment of listings found via the listing-search endpoint.
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 identifies concrete use cases: travel planning, deep-dive rate research, listing enrichment, and compliance/audit checks. It also hints at the relationship to the listing-search endpoint, but it does not give an explicit 'do not use this when...' instruction or name the sibling alternative.
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. Dates show when Glama detected each change.
2 tool updates
v1.0.0- First observed
hasdata_airbnb_listing_getAirbnbListings - First observed
hasdata_airbnb_property_getAirbnbPropertyDetails
TDQS
The two tools have clearly distinct purposes: one searches for available listings based on location/date/guests, while the other fetches complete details for a specific property URL. An agent would not struggle to choose between them.
Both tools follow the same structured pattern: hasdata_airbnb_<resource>_get<Resource>Details/Listings. The naming convention is consistent and predictable.
Two tools is thin for an Airbnb MCP server, but the pair forms a coherent, minimal workflow: search for listings then get more detail on a specific property. The count feels acceptable but smaller than ideal.
The core read-only Airbnb use cases are covered: discovering stays by search filters and retrieving a full property detail view. Missing operations like availability calendar lookups or review breakdowns are minor gaps, not dead ends.
Maintenance
Related MCP Connectors
Hosted Amazon Seller Central and Amazon Ads MCP server for Claude, ChatGPT, Cursor, and agents.
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
- UnifAPIOAuthcom.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables users to search Airbnb listings with advanced filtering options and retrieve detailed property information through an MCP server interface.22,792MIT
- AlicenseCqualityDmaintenanceThe only MCP server with AI guest risk scoring and extortion detection. Search properties, book instantly, protect hosts. 41 tools across 5 layers. Instant API key, 10 free credits.6MIT
- AlicenseNot gradedqualityDmaintenanceMCP server for Airbnb — lets AI agents search listings, check availability, manage reservations, and book stays via browser automation.19MIT
- AlicenseNot gradedqualityBmaintenanceMCP server for searching stays, comparing prices across Booking.com, Airbnb, Vrbo, and Google Hotels, and fetching reviews via natural language in AI assistants.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/HasData/airbnb-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server