de en es ja ko ru zh

Booking MCP Server

Name: Booking MCP Server
Author: HasData

by HasData

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

Booking.com MCP Server

一个托管的模型上下文协议（MCP）服务器，为 Claude、Cursor、Windsurf 以及任何其他 MCP 客户端提供两个只读的 Booking.com 工具。搜索功能可按目的地和日期检索住宿，并支持丰富的筛选条件；读取功能可完整获取单个房源的信息，全部以结构化 JSON 返回，无需 Booking.com 账户，也无需托管任何内容。

它读取的是 Booking.com 上未登录访客也能看到的公共房源页面。

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

Glama score tool contract MCP Tools npm PyPI License

准备工作

你需要一个 MCP 客户端和一个从控制台获取的 HasData API 密钥，免费创建，无需银行卡，试用额度按 10 积分/次的标准可覆盖 100 次调用。这是一个远程服务器，因此最简单的路径是提供一个 URL 和一个 x-api-key 请求头，无需运行任何容器，整个流程中也无需 Booking.com 账户。只支持 stdio 的客户端可通过一个轻量启动器访问它，该启动器以 npm 上的 @hasdata/booking-mcp 和 PyPI 上的 hasdata-booking-mcp 发布，如下所示。

快速开始

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

字段	值
URL	`https://mcp.hasdata.com/api/mcp?apis=booking`
传输方式	HTTP, streamable
认证请求头	`x-api-key: HASDATA_API_KEY`

支持 OAuth 的客户端可以将相同的 URL 作为连接器添加，无需在配置文件中写入密钥即可登录。

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

打开设置，然后进入连接器，再选择添加自定义连接器，粘贴 https://mcp.hasdata.com/api/mcp?apis=booking 并登录。

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

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

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

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

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

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

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

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

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

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

示例提示词

这些是提示词，不是代码。粘贴一条进去，代理会自行选择工具。每条都标注了它所消耗的调用次数，因为每次成功调用消耗 10 积分。

在 Booking.com 上搜索巴黎 9 月 15 日至 18 日两位成人的酒店，并给出整个住宿费用在 700 美元以内、评价最好的十家。

一次调用，10 积分。价格、评分和位置会随搜索结果一起返回。

取第一条结果并获取其完整详情：设施、住客须知、房型选项和分类评分。

一次调用，10 积分。这些信息位于房源页面上，详情工具会按 URL 和日期读取。

查找巴黎市中心附近可免费取消的四星级酒店，并列出租金和评分。

一次调用，10 积分。星级、取消政策和距离都是这一次请求中的筛选条件。

比较同一日期巴黎与罗马最便宜的住宿。

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

房源工具需要与搜索相同的日期和入住人数，因为可订状态和价格取决于时间段。用一次搜索来筛选候选，再对三家房源各做一次详情调用，即一次搜索加三次房源调用。

工具

两个工具，均为只读。下面的示例取自真实调用并做了精简，价格随时在变动。请把它们当作结构示例来阅读。每个工具名称都链接到其端点参考文档，其中包含完整的字段列表。

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

获取 Booking.com 搜索结果

hasdata_booking_search_getBookingSearchResults

按目的地和日期返回一页住宿结果。

参数	类型	必填	说明
`keyword`	string	是	目的地，例如 `Paris` 或具体的房源名称
`checkInDate` / `checkOutDate`	string	是	`YYYY-MM-DD`，入住日期需晚于当前日期且早于退房日期
`rooms` / `adults` / `children`	number	是	住客组成。没有儿童时传入 `children: 0`
`childrenAges`	string		以逗号分隔的年龄，当 `children > 0` 时必填
`sort`	string		`priceLowestFirst`、`ratingHighToLow`、`bestReviewedAndLowestPrice`、`distanceFromDowntown` 等
`propertyType__` / `rating__` / `reviewScore__`	array		住宿类型、星级评分和住客评分区间
`facilities__` / `roomFacilities__` / `reservationPolicy__`	array		设施、客房设施和取消政策筛选
`price_min_` / `price_max_`	number		整个住宿的价格区间
`page`	number		每页约 25 条结果，`2` 表示下一页

参考文档列出了完整的筛选条件，包括距离、餐饮、无障碍设施、床型偏好和出行人群。

返回 searchInformation、一个 results 数组，以及包含 page、totalResults 和 totalPages 的 pagination。每条结果包含 hotelId、title、url、提供的 room 和 bedTypes、一个 location 对象、一个 policies 对象、一个 price 对象、星级 rating，以及一个带 score、count 和文本标签的 reviews 对象，还有一个 photo。

price 中的折扣字段拼写为 dicsount（dicsountRaw 和 dicsountParsed），这沿用了上游的键名。请按这个拼写读取，而不是 discount。另请注意，rating 是官方星级，而 reviews.score 是满分 10 分的住客评分，这是两个不同的数字。

{
  "hotelId": 50724,
  "title": "Hôtel du Jardin des Plantes",
  "url": "https://www.booking.com/hotel/fr/timjardindesplantes.html",
  "room": "Comfort Double Room",
  "location": { "city": "Paris", "address": "5 rue Linné", "mainDistance": "0.9 miles from downtown", "centrallyLocated": true },
  "policies": { "freeCancellation": true, "noPrepayment": true },
  "price": { "pricePerStayParsed": 451.36, "priceBeforeDiscountParsed": 885.03, "dicsountParsed": 433.66, "currency": "USD" },
  "rating": 3,
  "reviews": { "score": 7.5, "count": 1721, "text": "Good" }
}

获取 Booking.com 房源详情

hasdata_booking_place_getBookingPlaceDetails

通过房源 URL 和住宿时间段，完整获取单个房源的信息。

参数	类型	必填	说明
`url`	string	是	Booking.com 房源 URL，即搜索结果中的 `url` 字段
`checkInDate` / `checkOutDate`	string	是	`YYYY-MM-DD`，用于计价和查询可订状态的时间段
`rooms` / `adults` / `children`	number	是	住客组成，含义与搜索工具相同
`childrenAges`	string		以逗号分隔的年龄，当 `children > 0` 时必填

返回的页面以分节而非单个扁平对象的形式呈现：overview（包含 id、title、propertyType、结构化的 address、description、highlights、mostPopularFacilities 和 photos）、bookingDetails（价格所反映的时间段和币种）、由可用套房组成的 rooms 数组（每个套房包含 name、beds、facilities 和带价格的 variants）、facilities 列表、houseRules、由分类评分组成的 ratings 数组、reviews 和 questionsAndAnswers。

{
  "overview": {
    "id": "50724",
    "title": "Hôtel du Jardin des Plantes",
    "propertyType": "HOTEL",
    "address": { "country": "France", "zipcode": "75005" },
    "mostPopularFacilities": ["Non-smoking rooms", "Free Wifi", "24-hour front desk"]
  },
  "bookingDetails": { "checkIn": "2026-09-15", "checkOut": "2026-09-18", "adults": 2, "rooms": 1, "currency": "USD" },
  "ratings": [
    { "label": "Average", "value": 7.5, "votes": 1721 },
    { "label": "Cleanliness", "value": 7.8 }
  ]
}

错误与失败路径

你的客户端几乎不会在工具调用中看到 HTTP 错误码。MCP 层返回 200，并将失败信息放入结果中，isError 设为 true，原因以文本形式呈现。在你可能期待状态行的位置，代理读到的是消息。

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

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

破坏工具架构的参数会在变成抓取请求之前被拒绝。 服务器返回 isError: true 和文本 MCP error -32602: Input validation error，并指出违规字段。children 数量没有对应的 childrenAges，或退房日期不晚于入住日期，都会在这里被拦截。

没有可订结果的搜索会返回成功结果，results 数组为空，而不是错误。 即使目的地在所选时间段内没有任何可订房源，返回的 requestMetadata.status 仍为 ok。在遍历之前请先检查数组长度。

无法解析的房源 URL 会返回 400，且 requestMetadata.status 为 error。

返回数据的结果还会携带一个 requestMetadata.id，在支持工单中值得引用。

定价、免费额度与限制

每个 Booking.com 工具每次成功调用消耗 10 个积分。响应大小不会改变价格。包含 25 项住宿的搜索页与只包含 2 项的搜索页价格相同。

免费试用为 30 天内 1,000 积分且无需信用卡，相当于 100 次 Booking.com 调用。此后，活跃账户只要余额低于 100，每天都会补充 100 积分，因此低流量的智能体可以无限期地运行在免费层上。

付费方案起价为 每月 49 美元，包含 200,000 积分，即 20,000 次调用。单价随用量增加而下降：从入门方案的 每 1,000 次调用 2.45 美元，到 Business 方案的 0.99 美元、Growth 方案的 0.83 美元，再到最大型高用量方案的 0.75 美元。

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

返回非 200 状态的请求不会计费。成功调用但未找到任何结果，仍然算作一次调用。

工具选择

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

?apis=booking                    the two tools in this repo
?apis=booking,airbnb             add Airbnb stays
?apis=booking,google_travel      add Google Hotels and Flights

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

对比

Booking.com 自己的项目（Demand API 和联盟伙伴网络）面向的是经过批准的合作伙伴，他们通过输送预订赚取佣金，并不是一种自助读取公开市场的方式。要搜索住宿并读取任意房源，抓取公开页面才是可行之路，而本服务器正是通过一个稳定的 schema 来完成这件事。

	Booking.com 合作伙伴计划	本服务器
用途	作为经批准的联盟成员输送预订	读取公开市场数据
访问方式	需合作伙伴批准	一个密钥和一个 URL
跨市场搜索	受合作伙伴条款限制	支持，且带有丰富的筛选条件
设置	企业入驻流程	无需设置
输出	合作伙伴数据源	结构化 JSON，价格和评分已预先解析

本服务器不做什么。 不提供预订、不处理支付、不涉及合作伙伴佣金，也不提供账户数据。它只读取未登录访客在 Booking.com 上能看到的内容。

常见问题

有官方的 Booking.com MCP 服务器吗？

Booking.com 没有发布官方的服务器。这个服务器由 HasData 维护，读取的是公开页面，因此不需要 Booking.com 账户。

什么是 Booking.com MCP 服务器？

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

我需要 Booking.com 账户或合作伙伴批准吗？

不需要。唯一的凭证是你的 HasData 密钥。由于这些工具读取的是 Booking.com 的公开页面，因此无需合作伙伴入驻流程。

为什么住宿工具需要日期？

因为可订状态、房型选项和价格都取决于入住时间段。使用与搜索时相同的 checkInDate、checkOutDate 和住客人数，详情就会反映该时间段的实际情况。

评分（rating）和点评分数（review score）有什么区别？

rating 是住宿的官方星级评定。reviews.score 是住客点评分数，满分为 10 分。一家三星级酒店可能带有 9.0 的住客评分，所以请确保你读取的是你真正想用的那个字段。

我可以将它与其它 HasData API 一起使用吗？

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

HasData 与 Booking.com 有关联吗？

没有。HasData 是一项独立服务，与 Booking.com 不存在关联、认可或赞助关系。Booking.com 是其各自所有者的商标。

合规与个人数据

HasData 仅访问公开可用的数据。平台的条款可能限制自动化访问，你需要自行确保合规。如果你收集的数据包含个人信息，请确保你根据 GDPR、CCPA 或你所在司法辖区的同等规则拥有合法的处理依据。

HasData 链接


产品页面与请求构建器	Booking.com Scraper API
服务器文档	MCP 服务器文档
一个服务器中的全部 57 个工具	HasData/hasdata-mcp
客户端入门指南	MCP 客户端与集成
我们抓取的其他所有数据	Booking.com Scraper API 以及另外 54 个
方案与积分成本	方案与积分成本
密钥与用量	HasData 仪表盘
npm 上的 Node 启动器	@hasdata/booking-mcp
PyPI 上的 Python 启动器	hasdata-booking-mcp

开发

这个仓库是一个远程服务器的配置和文档。没有构建步骤，也没有需要容器化的东西。

test/ 中的测试用于断言工具契约，也就是那些即使这里没有提交也可能被破坏的部分。它们检查 ?apis=booking 是否恰好返回两个工具，每个工具是否仍声明其必填参数，名称是否都没有改变，以及当前使用的密钥是否确实被接受。最后一项检查会真实调用一次工具并消耗 10 个积分，这就是一只金丝雀的代价——它能因为正确的原因而失败报警。

# 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_booking_place_getBookingPlaceDetailsbooking_place: GET /AInspect

Get Booking Hotel Details

Fetches a single Booking.com property by its full URL for the given stay dates (checkInDate / checkOutDate) and guest composition (rooms, adults, children with ages). Returns the property identity (hotelId, title, address, coordinates), policies (free cancellation, no prepayment, child/pet stays), price, rating and review summary, photos, and the list of available room suites for the requested window. Use to enrich property listings with real-time availability and pricing, monitor a specific competitor hotel over time, validate amenities and photos before displaying venue details to end users, or fetch full details after discovering the property URL via the Booking Search endpoint.

Name	Required	Description
`url`	Yes	Full Booking.com URL of the property page. Only `booking.com` and `www.booking.com` hosts are accepted.
`rooms`	Yes	Number of rooms to book.
`adults`	Yes	Number of adult guests across all rooms.
`children`	Yes	Number of child guests across all rooms (0–10). Pass `0` if there are no children.
`currency`	No	Currency of the prices returned in the response. Use `hotelCurrency` to keep each property's native currency. Provide one exact documented value (52 allowed), e.g. `hotelCurrency`, `usd`.
`language`	No	Language of the Booking.com interface and localized fields in the response.
`checkInDate`	Yes	Check-in date in `YYYY-MM-DD` format. Must be in the future and earlier than `checkOutDate`.
`checkOutDate`	Yes	Check-out date in `YYYY-MM-DD` format. Must be later than `checkInDate`.
`childrenAges`	No	Comma-separated list of child ages, one entry per child (each `0`–`17`). Required when `children > 0` and the number of ages must equal `children`. Example: `1,3,7`

TDQS

A4.4/5.0

Behavior4/5

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 specifies that the tool fetches real-time availability and pricing and returns a comprehensive set of fields, implying a read-only operation. It does not explicitly state it is safe or non-mutating, but the language 'fetches' and 'returns' strongly implies read-only behavior. It lacks explicit mention of error conditions or rate limits, but these are not typical in tool descriptions, so a 4 is appropriate.

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

Conciseness5/5

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

The description is three sentences, with the purpose front-loaded in the first sentence, a concise enumeration of return fields in the second, and a list of use cases in the third. Every sentence adds value, and there is no redundant or filler content. The structure is ideal for quick comprehension.

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 the tool has 9 parameters, 6 required, and no output schema, the description compensates by listing the categories of returned data (identity, policies, price, rating, photos, room suites). It also explains the input context (dates, guests) and references the search endpoint as the discovery path. It does not cover error handling or edge cases, but for a read-only fetch tool, the description is sufficiently complete for an agent to invoke it correctly.

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% description coverage for all 9 parameters, so the description adds little beyond what the schema already documents. It does reiterate key input groups (stay dates, guest composition) but without additional syntax or format details. Per the baseline for high schema coverage, a score of 3 is correct.

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 clearly states the tool fetches a single Booking.com property by its full URL with stay dates and guest composition, returning a rich set of fields. It explicitly contrasts with the sibling search tool by noting it is used after discovering a property URL via the Booking Search endpoint, making it easy to distinguish.

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

Usage Guidelines5/5

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

The description provides explicit use cases: enriching listings, monitoring competitor hotels, validating amenities, and fetching full details after a search. It implies the tool is for single-property lookups rather than broad searches, and references the sibling tool as the discovery step, leaving no ambiguity about when to choose this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

hasdata_booking_search_getBookingSearchResultsbooking_search: GET /AInspect

Get Booking Search Results

Searches Booking.com for accommodations by destination keyword and stay dates (checkInDate / checkOutDate) with guest composition (rooms, adults, children with ages) and rich filtering: property type, star rating, review score, hotel and room facilities, distance from center, reservation policy, bed preference, travel group, online payment, accessibility, plus optional price range and bedroom/bathroom counts. Pagination is page-based with 25 results per page; locale is controlled by language and currency. Returns each hotel's hotelId, title and Booking URL, location info (city, address, coordinates, distance to center / nearest beach), policies (free cancellation, no prepayment, child/pet stays), price (per stay, before discount, discount, currency), rating, review summary and main photo. Use to power travel-planning agents, OTA price/inventory monitoring, hotel competitor analysis, lead-generation in the hospitality vertical, or to feed hotelId / URL into the Booking Place endpoint for full property details.

Name	Required	Description
`page`	No	Page number of the search results. Booking.com returns 25 results per page; pass `2` for results 26–50, `3` for 51–75, etc.
`sort`	No	Sort order applied by Booking.com to the results page.
`rooms`	Yes	Number of rooms to book.
`adults`	Yes	Number of adult guests across all rooms.
`keyword`	Yes	Free-text destination query. Usually a city, region or neighborhood (e.g. `Paris`, `Manhattan, New York`); a specific property name is also accepted.
`meals__`	No	Filter by available meal plans. Multiple values are combined with OR.
`bedrooms`	No	Minimum number of bedrooms in the property.
`children`	Yes	Number of child guests across all rooms (0–10). Pass `0` if there are no children.
`currency`	No	Currency of the prices returned in the response. Use `hotelCurrency` to keep each property's native currency. Provide one exact documented value (52 allowed), e.g. `hotelCurrency`, `usd`.
`language`	No	Language of the Booking.com interface and localized fields in the response.
`rating__`	No	Filter by official star rating. Multiple values are combined with OR.
`bathrooms`	No	Minimum number of bathrooms in the property.
`price_max_`	No	Maximum total price for the stay, in the requested `currency`. Must be `>= 20` and greater than `price[min]`. Required if `price[min]` is omitted.
`price_min_`	No	Minimum total price for the stay, in the requested `currency`. Must be `>= 10`. Required if `price[max]` is omitted.
`checkInDate`	Yes	Check-in date in `YYYY-MM-DD` format. Must be in the future and earlier than `checkOutDate`.
`checkOutDate`	Yes	Check-out date in `YYYY-MM-DD` format. Must be later than `checkInDate`.
`childrenAges`	No	Comma-separated list of child ages, one entry per child (each `0`–`17`). Required when `children > 0` and the number of ages must equal `children`. Example: `1,3,7`
`facilities__`	No	Filter by property-level facilities. Multiple values are combined with OR.
`reviewScore__`	No	Filter by minimum guest review score bucket. Multiple values are combined with OR.
`travelGroup__`	No	Filter by travel-group oriented stay options. Multiple values are combined with OR.
`propertyType__`	No	Filter by property type. Multiple values are combined with OR.
`bedPreference__`	No	Filter by bed configuration. Multiple values are combined with OR.
`onlinePayment__`	No	Filter by online payment options.
`roomFacilities__`	No	Filter by in-room facilities. Multiple values are combined with OR.
`reservationPolicy__`	No	Filter by reservation flexibility. Multiple values are combined with OR.
`roomAccessibility__`	No	Filter by in-room accessibility features. Multiple values are combined with OR.
`distanceFromCenter__`	No	Filter by distance from the destination center. Multiple values are combined with OR.
`propertyAccessibility__`	No	Filter by property-level accessibility features. Multiple values are combined with OR.

TDQS

A4.2/5.0

Behavior3/5

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

The description indicates a read-only search operation through 'Searches' and 'Returns', and summarizes the output fields. However, with no annotations provided, it does not explicitly state that the operation is side-effect-free, whether it modifies any data, or mention rate limits or authentication behavior.

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 front-loaded with the main purpose and use cases, and the long middle section is dense with essential detail about filters and returned fields rather than being padded. It is long but efficient given the number of parameters and output categories.

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?

Although there is no output schema, the description clearly summarizes the returned hotel fields, pagination behavior, locale controls, and relationship to the Booking Place endpoint. It does not enumerate the exact response shape or error cases, but it provides enough context for a caller to understand what the tool does and how to chain it with the sibling tool.

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

Parameters5/5

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

Every parameter has a description that goes beyond the raw schema, including constraints such as page size, date ordering, price minimums/maximums, childrenAges required when children > 0, currency value guidance, and OR semantics for array filters.

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?

Clearly identifies this as a Booking.com accommodation search endpoint, states the core search inputs (destination, dates, guests), and explicitly positions it as the entry point before the Booking Place details endpoint via the mention of feeding hotelId/URL there.

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?

Provides concrete use cases such as travel planning, price monitoring, and competitor analysis, and explicitly connects to the sibling Booking Place endpoint for full property details. It does not formally state when not to use the tool, but the practical guidance is sufficient.

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 updatesv1.0.0Aug 24, 2026
- First observedhasdata_booking_place_getBookingPlaceDetails
- First observedhasdata_booking_search_getBookingSearchResults

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

A4.3/5.0

Scored 2026-08-24 14:15 across 2 tools

Disambiguation5/5

Search and place details have clear boundaries: search accepts destination criteria and returns property lists, while place details consumes a single property URL and returns full property information. The overlap in returned pricing/rating fields is expected, not confusing.

Naming Consistency5/5

Both tool names follow the same hasdata_booking_<endpoint>_get... pattern, using place and search as distinct resource endpoints. The naming is consistent across the set, even though the operation suffix uses camelCase.

Tool Count3/5

Two tools is a minimal but reasonable set for a search-then-detail workflow. However, the count sits at the thin edge of the expected 3-15 tool range, leaving little room for exploration beyond the two core endpoints.

Completeness5/5

The tool surface covers the intended read-only Booking.com workflow: search for accommodations, then fetch a single property's full details. There are no dead ends for travel-planning or OTA data monitoring use cases.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

Related MCP Connectors

1stay A
com.stayker
Hotel booking MCP server. Search, book, and manage reservations across 250K+ properties worldwide.
Travel & Transportation E-commerce & Retail App Automation
843
https://mcp.stayker.com/mcp
Booking.com Hotel Search (Live Prices)AOAuth
com.flightpowers
Real-time Booking.com rates for agents. Three things people do with this server. Scan for rate gaps: price_as_seen_from prices the same room from another market, so an agent can sample a property across countries and compare. Put live search in your app: search a destination or look a property up by name, no internal IDs, room-level rates as flat JSON. Run a 24/7 AI travel agent: add the server, sign in with Google, and schedule it. No ads, no sponsored content. You bring your own RapidAPI key, so every search is billed to your plan and never to anyone else's. Add https://hotels.flightpowers.com/mcp , click Sign in, sign in with Google, and paste your RapidAPI key once on the page that opens. Scripts and clients without a sign-in button send the key as x-rapidapi-key on the same URL.
E-commerce & Retail Travel & Transportation
411
https://hotels.flightpowers.com/mcp
MAQAMI Travel B
co.maqami.mcp
Official MCP server for MAQAMI, a hotel and flight booking platform with 3M+ hotels. Search live hotel rates and flights, look up places, airports and hotel details, then prebook and book. Remote Streamable HTTP endpoint, no API key required.
E-commerce & Retail Travel & Transportation
411
https://mcp.maqami.co/
Quub hotel search and booking A
rent.quub
Live hotel prices worldwide, sourced destination guides, prebooking. No key needed for reads.
Travel & Transportation Location Services E-commerce & Retail
81
https://quub.rent/mcp

Related MCP Servers

com.stayingapi/hotel-vacationofficial
Travel & Transportation Search
stayingapi
A
license
Not graded
quality
B
maintenance
MCP server for searching stays, comparing prices across Booking.com, Airbnb, Vrbo, and Google Hotels, and fetching reviews via natural language in AI assistants.
Updated 6 days ago (2026-10-25 18:06 UTC)
MIT
mydatavalue-mcp
Real Estate Travel & Transportation
Elev8-OS
F
license
Not graded
quality
B
maintenance
MCP server for querying MyDataValue's Booking.com and Airbnb property data, including pricing, promotions, reviews, and performance metrics, via a read-only connector with automatic OAuth token rotation.
Updated 3 months ago (2026-08-06 05:10 UTC)
-
Google Search MCP Server
Marketing Research & Data Web Scraping
HasData
A
license
A
quality
A
maintenance
Enables MCP clients to perform live Google searches and retrieve structured SERP data including organic results, AI Overviews, People Also Ask, AI Mode answers, news, shopping, and short-video results via eight read-only tools.
Updated 2 days ago (2026-10-29 15:58 UTC)
10
144 npm
59 PyPI
17
MIT
Airbnb MCP Server
Real Estate Travel & Transportation Web Scraping
HasData
A
license
A
quality
B
maintenance
A hosted MCP server that lets Claude, Cursor, Windsurf, and other clients search Airbnb stays by location and dates, and read full listing details as structured JSON, with no Airbnb developer account or partner approval required.
Updated 2 days ago (2026-10-29 15:55 UTC)
2
110 npm
135 PyPI
8
MIT

Booking.com MCP Server

目录

准备工作

快速开始

示例提示词

工具

获取 Booking.com 搜索结果

获取 Booking.com 房源详情

错误与失败路径

定价、免费额度与限制

工具选择

对比

常见问题

有官方的 Booking.com MCP 服务器吗？

什么是 Booking.com MCP 服务器？

我需要 Booking.com 账户或合作伙伴批准吗？

为什么住宿工具需要日期？

评分（rating）和点评分数（review score）有什么区别？

我可以将它与其它 HasData API 一起使用吗？

HasData 与 Booking.com 有关联吗？

合规与个人数据

HasData 链接

开发

贡献

许可证

Available Tools

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

com.stayingapi/hotel-vacationofficial

mydatavalue-mcp

Google Search MCP Server

Airbnb MCP Server