Booking MCP Server
Booking.com MCP Server
Хостируемый сервер Model Context Protocol (MCP), который предоставляет Claude, Cursor, Windsurf и любому другому MCP-клиенту два инструмента Booking.com только для чтения. Поиск вариантов размещения по направлению и датам с богатыми фильтрами и полное чтение отдельного объекта — всё в виде структурированного JSON, без аккаунта Booking.com и без необходимости что-либо хостить.
Он читает публичные страницы объектов на Booking.com, которые видит посетитель без входа в аккаунт.
https://mcp.hasdata.com/api/mcp?apis=booking
Содержание
Related MCP server: mydatavalue-mcp
Что нужно
Нужны MCP-клиент и ключ API HasData из дашборда, который создаётся бесплатно без карты, а пробный период покрывает 100 вызовов по тарифу 10 кредитов. Это удалённый сервер, поэтому самый простой путь — URL и заголовок x-api-key: не нужно запускать контейнер, и аккаунт Booking.com нигде в процессе не участвует. Клиент, который умеет только stdio, подключается к нему через тонкий лаунчер, опубликованный как @hasdata/booking-mcp на npm и hasdata-booking-mcp на PyPI, как показано ниже.
Быстрый старт
URL сервера одинаков для всех клиентов. Мы используем его напрямую в Claude Code и Claude Desktop. Остальные блоки следуют документированному формату каждого клиента для удалённого сервера.
Поле | Значение |
URL |
|
Транспорт | HTTP, streamable |
Заголовок авторизации |
|
Клиенты с поддержкой OAuth могут добавить тот же URL как коннектор и войти, не помещая ключ в конфигурационный файл.
claude mcp add --transport http booking "https://mcp.hasdata.com/api/mcp?apis=booking" \
--header "x-api-key: HASDATA_API_KEY"Настройки, затем Connectors, затем Add custom connector, затем вставьте 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 отели в Париже с 15 по 18 сентября для двух взрослых и покажи десять лучших по отзывам с ценой до $700 за проживание.
Один вызов, 10 кредитов. Цена, оценка по отзывам и местоположение возвращаются в результате поиска.
Возьми верхний результат и получи его полные детали: удобства, правила дома, варианты номеров и оценки по категориям.
Один вызов, 10 кредитов. Они находятся на странице объекта, которую инструмент деталей читает по URL и датам.
Найди четырёхзвёздочные отели в Париже с бесплатной отменой недалеко от центра и выведи цену и оценку по отзывам.
Один вызов, 10 кредитов. Звёздный рейтинг, условия отмены и расстояние — это фильтры в одном запросе.
Сравни самое дешёвое проживание в Париже и Риме на одни и те же даты.
Два вызова, 20 кредитов: по одному поиску на город.
Инструменту объекта нужны те же даты и количество гостей, что и поиску, потому что наличие и цена зависят от периода. Поиск для короткого списка плюс вызов деталей по трём объектам — это один поиск и три вызова объекта.
Инструменты
Два инструмента, только для чтения. Примеры ниже сокращены из реальных вызовов, а цены постоянно меняются. Воспринимайте их как структуру. Каждое имя инструмента ведёт на справочник endpoint'а с полным списком полей.
Примеры — это полезная нагрузка, а не весь ответ. Результат tools/call содержит один текстовый блок, и этот текст сам является JSON с полями url, status, text и json; данные, полученные со страницы, лежат в json. В сыром JSON-RPC ответе путь — result.content[0].text, затем парсинг и .json. Чат-клиент разворачивает это за вас, а код, работающий с endpoint'ом напрямую, — нет.
Получение результатов поиска Booking.com
hasdata_booking_search_getBookingSearchResults
Страница вариантов размещения по направлению и датам.
Параметр | Тип | Обязателен | Примечания |
| string | да | Направление, например |
| string | да |
|
| number | да | Состав гостей. Передайте |
| string | Возраст через запятую, обязателен при | |
| string |
| |
| array | Тип объекта, звёздный рейтинг и диапазоны оценок гостей | |
| array | Фильтры по удобствам, оснащению номера и отмене | |
| number | Диапазон цены за всё проживание | |
| number | Около 25 результатов на странице, |
В справочнике описан полный набор фильтров, включая расстояние, питание, доступность, предпочтения по кровати и группу путешествующих.
Возвращает searchInformation, массив results и pagination с page, totalResults и totalPages. Каждый результат содержит hotelId, title, url, предлагаемые room и bedTypes, объект location, объект policies, объект price, звёздный rating, объект reviews с score, count и текстовой меткой, а также 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 и периоду проживания.
Параметр | Тип | Обязателен | Примечания |
| string | да | URL объекта на Booking.com, поле |
| string | да |
|
| number | да | Состав гостей, то же значение, что и в инструменте поиска |
| string | Возраст через запятую, обязателен при |
Возвращает страницу в виде разделов, а не одного плоского объекта: 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 вариантами размещения стоит столько же, сколько страница с двумя.
Бесплатный пробный период — 1 000 кредитов на 30 дней без карты, то есть 100 вызовов Booking.com. После этого активный аккаунт продолжает получать по 100 кредитов ежедневно, когда его баланс опускается ниже 100, так что агент с низким объёмом запросов работает на бесплатном тарифе бессрочно.
Платные тарифы начинаются от $49 в месяц за 200 000 кредитов, то есть 20 000 вызовов. Цена за единицу снижается с объёмом: от $2,45 за 1 000 вызовов на начальном тарифе до $0,99 на Business, $0,83 на Growth и $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 и аффилиатская партнёрская сеть — предназначены для одобренных партнёров, которые отправляют бронирования и получают комиссию, а не для самостоятельного чтения публичного рынка. Для поиска вариантов размещения и просмотра произвольных объектов правильный путь — парсинг публичных страниц, и этот сервер делает это, предоставляя стабильную схему данных.
Партнёрские программы Booking.com | Этот сервер | |
Назначение | Отправка бронирований как одобренный аффилиат | Чтение публичного рынка |
Доступ | Одобрение партнёра | Один ключ и один URL |
Поиск по рынку | В рамках партнёрских условий | Да, с расширенными фильтрами |
Настройка | Бизнес-онбординг | Не требуется |
Вывод | Партнёрские фиды | Структурированный JSON, цена и оценка уже разобраны |
Чего этот сервер не делает. Никаких бронирований, никаких платежей, никаких партнёрских комиссий, никаких данных аккаунта. Он читает то, что видит посетитель без входа на Booking.com.
FAQ
Существует ли официальный MCP-сервер Booking.com?
Booking.com не публикует такой сервер. Этот сервер поддерживается HasData и читает публичные страницы, поэтому ему не нужен аккаунт Booking.com.
Что такое MCP-сервер Booking.com?
Это сервер, который предоставляет данные Booking.com в виде инструментов, которые может вызывать ИИ-клиент. Клиент отправляет вызов инструмента по протоколу Model Context Protocol, сервер получает данные и возвращает структурированный JSON, а модель работает с результатом. Этот сервер предоставляет два инструмента и работает удалённо.
Нужен ли мне аккаунт Booking.com или одобрение партнёра?
Нет. Единственное, что нужно, — ваш ключ HasData. Никакого партнёрского онбординга нет, потому что инструменты читают публичные страницы Booking.com.
Почему инструменту для объектов нужны даты?
Потому что наличие, варианты номеров и цена зависят от периода проживания. Передайте те же checkInDate, checkOutDate и количество гостей, с которыми вы искали, и детали будут соответствовать этому периоду.
В чём разница между рейтингом и оценкой отзывов?
rating — это официальный звёздный рейтинг объекта. reviews.score — это оценка гостей по десятибалльной шкале. Трёхзвёздочный отель может иметь гостевую оценку 9.0, так что читайте ту, которую имеете в виду.
Можно ли использовать это вместе с другими API HasData?
Да. Параметр apis принимает список, и ?apis=booking,airbnb даёт вашему агенту Booking.com плюс Airbnb. Уберите параметр — и вы получите всё.
Связана ли HasData с Booking.com?
Нет. HasData — независимый сервис и не связан с Booking.com, не одобрен им и не спонсируется им. Booking.com является товарным знаком своего владельца.
Соответствие требованиям и персональные данные
HasData получает доступ только к общедоступным данным. Условия платформы могут ограничивать автоматический доступ, и вы несёте ответственность за собственное соответствие требованиям. Если собираемые вами данные включают персональную информацию, убедитесь, что у вас есть законное основание для её обработки в соответствии с GDPR, CCPA или эквивалентными правилами в вашей юрисдикции.
Ссылки HasData
Страница продукта и конструктор запросов | |
Документация сервера | |
Все 57 инструментов в одном сервере | |
Клиентские руководства | |
Всё остальное, что мы собираем | |
Тарифы и стоимость кредитов | |
Ключи и использование | |
Node-лаунчер на npm | |
Python-лаунчер на PyPI |
Разработка
Этот репозиторий — конфигурация и документация для удалённого сервера. Здесь нет шага сборки и нечего контейнеризировать.
Тесты в 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 при каждом пуше и раз в неделю по расписанию, потому что список инструментов на стороне API может измениться без изменений в этом репозитории. Сбой означает, что список инструментов сдвинулся, ключ перестал работать или эндпоинт был недоступен, и сообщение проверки говорит, что именно.
Участие в разработке
Самый полезный вклад — исправления в таблицах инструментов и примерах ответов, потому что именно эти части расходятся с реальностью. Приложите выполненный вызов и полученный ответ. Пул-реквесты из форков запускают набор тестов без ключа, а живые проверки пропускаются вместо того, чтобы падать.
Лицензия
MIT. См. LICENSE.
Available Tools
2 toolshasdata_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 | Default |
|---|---|---|---|
| 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
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.
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.
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.
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.
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.
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 | Default |
|---|---|---|---|
| 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
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.
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.
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.
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.
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.
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 updates
v1.0.0- First observed
hasdata_booking_place_getBookingPlaceDetails - First observed
hasdata_booking_search_getBookingSearchResults
TDQS
Scored across 2 tools
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.
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.
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.
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
Related MCP Connectors
Hotel booking MCP server. Search, book, and manage reservations across 250K+ properties worldwide.
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.
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.
Live hotel prices worldwide, sourced destination guides, prebooking. No key needed for reads.
Related MCP Servers
- 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
- FlicenseNot gradedqualityBmaintenanceMCP 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.-
- AlicenseAqualityAmaintenanceEnables 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.1050 npm77 PyPI17MIT
- AlicenseAqualityBmaintenanceA 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.248 npm88 PyPI8MIT