Skip to main content
Glama
Sign In
enesjakoruzh
Airbnb MCP Server

Airbnb MCP Server

by HasData
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Airbnb MCP Server

一个托管的 Model Context Protocol (MCP) 服务器，为 Claude、Cursor、Windsurf 以及任何其他 MCP 客户端提供两个只读的 Airbnb 工具。按地点和日期搜索房源，并完整读取单个房源，全部以结构化 JSON 返回，无需 Airbnb 开发者账户，也无需合作伙伴审批。

它读取未登录访客可以查看的公开房源页面。

https://mcp.hasdata.com/api/mcp?apis=airbnb

Glama score tool contract MCP Tools npm PyPI License

目录

Related MCP server: @striderlabs/mcp-airbnb

你需要什么

你需要一个 MCP 客户端和一个来自 控制台 的 HasData API 密钥，免费创建，无需银行卡，试用额度按 5 积分每次的费率可覆盖约 200 次调用。这是一个远程服务器，因此最简单的路径是提供一个 URL 和一个 x-api-key 请求头，无需运行容器，整个流程中也无需 Airbnb 开发者账户。只支持 stdio 的客户端可以通过一个轻量启动器访问它，该启动器以 @hasdata/airbnb-mcp 发布在 npm 上，以 hasdata-airbnb-mcp 发布在 PyPI 上，如下所示。

快速开始

服务器 URL 对所有客户端都是相同的。我们在 Claude Code 和 Claude Desktop 中亲自运行过它。其他代码块均遵循各客户端文档中规定的远程服务器格式。

字段

值

URL

https://mcp.hasdata.com/api/mcp?apis=airbnb

传输方式

HTTP，可流式

认证请求头

x-api-key: HASDATA_API_KEY

支持 OAuth 的客户端可以将同一个 URL 添加为连接器并登录，无需在配置文件中放置密钥。

claude mcp add --transport http airbnb "https://mcp.hasdata.com/api/mcp?apis=airbnb" \
  --header "x-api-key: HASDATA_API_KEY"

依次进入 Settings、Connectors，然后选择 Add custom connector，粘贴 https://mcp.hasdata.com/api/mcp?apis=airbnb 并登录。

对于配置文件方式，Claude Desktop 只加载本地（stdio）服务器，因此它需要通过一个 stdio 启动器访问远程服务器。@hasdata/airbnb-mcp 包就是这个启动器，它会从环境中读取密钥。将其添加到 claude_desktop_config.json：

{
  "mcpServers": {
    "airbnb": {
      "command": "npx",
      "args": ["-y", "@hasdata/airbnb-mcp"],
      "env": { "HASDATA_API_KEY": "YOUR_KEY" }
    }
  }
}

如果使用 Python 而非 Node，请将启动器换成 PyPI 包，uvx 无需手动安装即可运行它：

{
  "mcpServers": {
    "airbnb": {
      "command": "uvx",
      "args": ["hasdata-airbnb-mcp"],
      "env": { "HASDATA_API_KEY": "YOUR_KEY" }
    }
  }
}

~/.cursor/mcp.json 用于所有项目，或 .cursor/mcp.json 用于单个项目：

{
  "mcpServers": {
    "airbnb": {
      "url": "https://mcp.hasdata.com/api/mcp?apis=airbnb",
      "headers": { "x-api-key": "HASDATA_API_KEY" }
    }
  }
}

~/.codeium/windsurf/mcp_config.json。Windsurf 将该字段称为 serverUrl，而不是 url：

{
  "mcpServers": {
    "airbnb": {
      "serverUrl": "https://mcp.hasdata.com/api/mcp?apis=airbnb",
      "headers": { "x-api-key": "HASDATA_API_KEY" }
    }
  }
}

工作区中的 .vscode/mcp.json：

{
  "servers": {
    "airbnb": {
      "type": "http",
      "url": "https://mcp.hasdata.com/api/mcp?apis=airbnb",
      "headers": { "x-api-key": "HASDATA_API_KEY" }
    }
  }
}

示例提示

这些是提示，不是代码。粘贴一条，智能体会自行选择工具。每条提示都标注了它需要多少次调用，因为每次成功调用消耗 5 积分。

搜索 9 月 15 日至 18 日两位成人的奥斯汀房源，给我评分最高且每晚低于 200 美元的十个。

一次调用，5 积分。评分和每晚价格会随搜索结果一起返回。

取第一个结果，提取其完整设施、客人与卧室数量，以及房东详情。

一次调用，5 积分。这些信息位于房源页面上，详情工具通过 URL 读取该页面。

比较两位客人在奥斯汀住三晚与在纳什维尔住三晚的每晚价格。

两次调用，10 积分，每个城市一次搜索。

对于这个房源 URL，告诉我它有几张床、几个浴室，以及房东是否是 Superhost。

一次调用，5 积分。

搜索结果刻意保持精简，足以用于排名和筛选。设施、床、房东和完整描述来自房源调用，因此，一个先筛选再查看三处房源的提示，需要一次搜索加三次房源调用。

工具

两个工具，均为只读。下面的示例来自真实调用并做了精简，数字会随 Airbnb 更新而变化。请把它们视为结构示例。每个工具名称都链接到其端点参考文档，其中包含完整字段列表。

示例是载荷，不是完整响应。tools/call 结果包含一个文本块，该文本本身是 JSON，包含 url、status、text 和 json，抓取的数据位于 json 下。从原始 JSON-RPC 响应来看，路径是 result.content[0].text，解析后取 .json。聊天客户端会为你解包这些内容，而直接与端点通信的代码则不会。

获取 Airbnb 房源列表

hasdata_airbnb_listing_getAirbnbListings

按地点和日期返回一页搜索结果。

参数

类型

必填

说明

location

string

是

要搜索的地点，例如 Austin, Texas

checkIn

string

是

入住日期，YYYY-MM-DD

checkOut

string

退房日期，YYYY-MM-DD

adults / children / infants / pets

number

入住人构成，每项为人数

nextPageToken

string

上一响应中的 pagination.nextPageToken

返回 properties 数组和 pagination，其 nextPageToken 和 pageTokens 用于遍历结果集。每个房源包含 id、url、title、latitude、longitude、一句简短的 description 标语、photos 数组、rating、reviews、badges 数组（例如 Guest favorite 或 Superhost）以及 price 对象。price 包含 originalPrice、当房源有折扣时可选的 discountedPrice、类似 for 3 nights 的 qualifier，以及 breakdown。

搜索结果刻意保持精简。床、浴室、设施、房东和完整描述都不在这里，它们来自下面的房源工具。不要指望搜索结果中会有卧室数量。

{
  "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" }]
  }
}

获取 Airbnb 房源详情

hasdata_airbnb_property_getAirbnbPropertyDetails

通过 URL 完整读取一个房源。

参数

类型

必填

说明

url

string

是

一个 Airbnb 房源 URL，即搜索结果中的 url 字段

返回 title、类似 ["4 guests", "2 bedrooms", "2 beds", "2 baths"] 的 overview 数组、完整的 description、rating、reviews、address、latitude、longitude、photos 数组、guestCapacity、host 对象、amenities 数组和 safetyAndPropertyInfo。host 对象包含 name、isSuperhost、isVerified，以及房东自己的 reviews、rating 和 yearsHosting。每个设施条目包含 title、type、可选的 description 和 available 标志，因此过滤器读取的是 available，不会假定列出的每个设施都存在。

{
  "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 }
  ]
}

错误与失败情形

你的客户端几乎不会在工具调用中看到 HTTP 错误码。MCP 层返回 200，并将失败信息放在结果内部，isError 设为 true，原因以文本形式给出。智能体读取到的是一条消息，而不是你可能预期的状态行。

错误的密钥会以工具输出的形式显现，而不是连接失败。 tools/list 接受任何非空密钥并返回两个工具，因此客户端完成握手并显示绿色。第一次工具调用随后会返回 isError: true 以及文本 HasData API error: 401 Unauthorized。请注意这个字符串，因为流程中之前没有任何环节会报告该问题。

缺少密钥是唯一一个真正的 HTTP 错误。 授权在任何工具之前执行，连接本身会以 401 失败。CORS 头存在，浏览器客户端读取到的是状态码，而不是不透明的网络错误。

破坏工具 schema 的参数会在成为一次抓取之前被拒绝。 服务器返回 isError: true 以及文本 MCP error -32602: Input validation error，并指出有问题的字段。不会抓取任何内容，也不会产生任何费用。

没有可用房源的搜索会返回成功结果，properties 数组为空，而不是错误。即使某个地点和日期范围内没有任何可订房源，响应仍会带有 requestMetadata.status 为 ok。在迭代之前先检查数组长度。

已被移除的房源会返回 400，requestMetadata.status 设为 error。来自旧搜索的 URL 可能指向一个已不存在的房源。

包含数据的结果还带有 requestMetadata.id，在联系支持时值得引用。

定价、免费额度与限制

每个 Airbnb 工具每次成功调用消耗 5 积分。响应大小不影响价格。包含几十个房源的搜索页与只有两个房源的搜索页价格相同。

免费试用为 30 天内 1,000 积分，无需银行卡，即 200 次 Airbnb 调用。之后，活跃账户只要余额低于 100 积分，每天都会获得 100 积分补充，因此低用量智能体可以无限期运行在免费层级上。

付费套餐起价为 每月 49 美元，包含 200,000 积分，即 40,000 次调用。单价随用量下降，从入门套餐的 每 1,000 次调用 1.23 美元，到 Business 的 0.50 美元、Growth 的 0.42 美元，以及最大的 高用量套餐 的 0.37 美元。

你的套餐还决定了并发数。免费试用允许同时 1 个请求，Startup 为 15，Business 为 30，Growth 为 50，高用量套餐为 200 到 1,500。在任何无人值守的程序中，都要对溢出情况做防御性处理。

返回非 200 的请求不会计费。一次成功但未找到任何内容的调用仍然算一次调用。

工具选择

apis 查询参数决定你的智能体能看到哪些工具。工具越少，用于工具定义的上下文就越少，模型选错工具的机会也越少。

?apis=airbnb                     the two tools in this repo
?apis=airbnb,booking             add Booking.com stays
?apis=airbnb,google_maps         add Google Maps places

该参数接受类似 airbnb 的提供商名称，以及类似 airbnb_listing 的单个 API 名称。拼写错误的名称会被忽略。如果所有名称都错误，请求将返回 400 失败，响应体会列出它无法识别的名称以及所有有效值。去掉该参数后，同一个端点会暴露全部 57 个 HasData 工具。

对比

Airbnb 没有公开的搜索 API。其 API 计划是用于管理你自己房源的合作伙伴和联合房东集成方案，而不是了解市场的途径。要搜索住宿并读取任意房源列表，抓取公开页面是唯一途径，而本服务器通过一个稳定的 schema 来实现这一点。

Airbnb partner API

本服务器

目的

管理你自己的房源

读取公开市场

访问权限

合作伙伴批准

一个密钥和一个 URL

搜索整个市场

无

有

设置

企业入驻流程

无需

输出

合作伙伴数据负载

结构化 JSON，价格和评分已预解析

本服务器不做什么。 不提供预订、消息、房东控制面板或房客数据。它只读取未登录访客所能看到的内容。

常见问题

有官方的 Airbnb MCP 服务器吗？

Airbnb 没有发布官方版本。本服务器由 HasData 维护，读取公开页面，因此不需要 Airbnb 开发者账户。

什么是 Airbnb MCP 服务器？

它是一种将 Airbnb 数据以工具形式暴露给 AI 客户端调用的服务器。客户端通过 Model Context Protocol 发送工具调用，服务器获取数据并返回结构化 JSON，模型再处理结果。本服务器提供两个工具，并以远程方式运行。

我需要 Airbnb API 密钥或合作伙伴账户吗？

不需要。唯一的凭证是你的 HasData 密钥。没有合作伙伴入驻流程，因为这些工具读取的是 Airbnb 的公开页面。

为什么搜索结果不显示床位或设施？

因为 Airbnb 不会把它们放在搜索卡片上。这些信息位于房源详情页，details 工具会通过 URL 读取该页面。先用搜索进行筛选，再调用 property 工具获取详细信息。

我可以按房客、宠物或日期筛选吗？

可以。listing 工具接受 checkIn、checkOut 以及 adults、children、infants 和 pets 的数量，并返回该入住群体和时间窗口的可用性与定价。

我可以将它和 HasData 的其他 API 一起使用吗？

可以。apis 参数接受一个列表，?apis=airbnb,booking 会让你的智能体同时获得 Airbnb 和 Booking.com 的数据。去掉该参数 即可获取全部。

合规与个人数据

HasData 仅访问公开可获取的数据。平台的服务条款可能对自动化访问做出限制，你有责任确保自身合规。当你收集的数据包含个人信息时，请确保你依据 GDPR、CCPA 或你所在司法辖区的同等规则拥有合法的处理依据。

HasData 链接

产品页面与请求构建器

Airbnb Scraper API

服务器文档

MCP 服务器文档

一台服务器中的全部 57 个工具

HasData/hasdata-mcp

客户端入门指南

MCP 客户端与集成

我们抓取的其他所有数据

Airbnb Scraper API 及另外 54 个

套餐与积分费用

套餐与积分费用

密钥与用量

HasData 控制台

npm 上的 Node 启动器

@hasdata/airbnb-mcp

PyPI 上的 Python 启动器

hasdata-airbnb-mcp

开发

本仓库是远程服务器的配置和文档。没有构建步骤，也不需要容器化。

test/ 中的测试验证工具契约，也就是即使本仓库没有提交也可能出问题的部分。它们会检查 ?apis=airbnb 是否恰好返回两个工具、每个工具是否仍声明其必需参数、名称是否未变，以及正在使用的密钥是否确实被接受。最后一项检查会真实调用一次工具并消耗 5 个积分，这正是金丝雀的代价——它会因正确的原因而失败。

# macOS and Linux
HASDATA_API_KEY=your_key_here npm test

# Windows PowerShell
$env:HASDATA_API_KEY="your_key_here"; npm test

同一套测试会在每次推送时以及每周一次的定时任务中于 CI 运行，因为上游工具列表可能会在无人改动本仓库的情况下发生变化。失败意味着工具列表发生了变动、密钥失效或端点无法访问，断言消息会明确指出是哪一种情况。

贡献

对工具表格和响应示例的更正最有价值，因为这些部分最易过时。请附上你发起的调用以及收到的响应。来自 fork 的拉取请求会在没有密钥的情况下运行测试套件，实时检查会跳过而不是报红。

许可证

MIT。参见 LICENSE。

Available Tools

2 tools
hasdata_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.

NameRequiredDescriptionDefault
petsNoNumber of pets.
adultsNoNumber of adults.
checkInYesThe check-in date for the listings.
infantsNoNumber of infants.
checkOutNoThe check-out date for the listings.
childrenNoNumber of children.
locationYesThe location to search for listings.
nextPageTokenNoThe token used to retrieve the next page of results.

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

NameRequiredDescriptionDefault
urlYesThe URL of the Airbnb listing. Must be a valid Airbnb listing URL.

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of disclosing behavior. It says 'Fetches' which implies a read operation, and the title indicates GET. However, it does not explicitly state it is read-only, nor does it mention rate limits, latency, or any side effects. The detailed field list is helpful, but behavioral expectations beyond a straightforward fetch are not disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but not bloated. It front-loads the purpose and then lists the returned fields and use cases. Every sentence adds value, though the field list could be trimmed slightly. It remains efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is no output schema, the description compensates by enumerating the returned fields thoroughly (title, description, location, coordinates, fees, ratings, host, counts, photos, amenities, rules, policy, calendar hints). It also covers typical use cases. It does not address error handling, pagination, or timeouts, but for a single-URL fetch those are minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage for the single 'url' parameter, which is described as a valid Airbnb listing URL. The description confirms this by saying 'by listing URL' but adds no new semantics (e.g., format, validation rules, or URL variants). With full schema coverage, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb+resource ('Get Airbnb Property Details') and immediately specifies the input (listing URL). It enumerates the full set of returned fields, which leaves no ambiguity about what the tool does. It also explicitly ties it to the sibling listing-search endpoint, making differentiation straightforward.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lists concrete use cases: travel-planning, deep-dive rate research, photo/amenity enrichment, and compliance audits. It references the listing-search endpoint as the source of discovered listings, which implies the sibling is for searching while this is for detail retrieval. It does not explicitly state when not to use it, but the use cases and the mention of the sibling provide adequate guidance.

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.

  1. 2 tool updatesv1.0.0
    • First observedhasdata_airbnb_listing_getAirbnbListings
    • First observedhasdata_airbnb_property_getAirbnbPropertyDetails
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency5/5

Both tools follow the same structured pattern: hasdata_airbnb_<resource>_get<Resource>Details/Listings. The naming convention is consistent and predictable.

Tool Count3/5

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.

Completeness4/5

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

ActivityActive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers