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: Hotels MCP Server
Что нужно
Нужны 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?
No annotations are provided, so the description carries the behavioral burden. It discloses that this is a read-style 'Fetches' operation, that it returns real-time availability and pricing, and it summarizes the outputs including policies, ratings, photos, and room suites. It does not mention limiting behaviors such as rate handling or response failure conditions, but it is substantially transparent for a GET-like lookup.
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 a well-organized paragraph: what it does, what it returns, and when to use it. The first line 'Get Booking Hotel Details' is slightly redundant with the name, but the rest of the description avoids unnecessary noise and information is front-loaded.
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?
With no output schema and no annotations, the description compensates by listing the key return categories and explaining enriched use cases. It could include more detail about exact response structure or error conditions, but for the AI agent the combination of schema, use cases, and return summary is enough to select and invoke the tool 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 provides full descriptions for all 9 parameters, so the schema does most of the parameter work. The description adds context by tying the inputs to stay dates and guest composition, and by mentioning the URL origin flow from search, but it does not deepen the individual parameter semantics.
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 opens with a specific verb and resource: 'Fetches a single Booking.com property by its full URL.' It names the key inputs and outputs and distinguishes itself from the sibling by being a detail lookup for an already-known property URL rather than a discovery/search call.
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 gives concrete use cases: enrich property listings, monitor a competitor hotel, validate amenities/photos, and fetch details after a search. It does not explicitly state when not to use it versus the search endpoint, but it clearly implies this tool is for known URLs and detailed property data.
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?
With no annotations provided, the description carries the full burden, and it does a good job: it reports that this is an external Booking.com search, that pagination is page-based with 25 results per page, that language and currency control locale, and it enumerates the returned hotel data. It does not cover possible errors, rate limits, or authorization requirements, but for a read-oriented search tool the behavioral disclosure is sufficient.
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 long, but given the tool's 28 parameters and rich return payload, nearly every sentence adds useful information. It is front-loaded with the core search behavior and filters before covering output and use cases; only the list of use cases is somewhat optional, but it still helps an agent choose the tool.
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?
The description provides a complete picture for selecting and invoking the tool: required search inputs, available filters, pagination, locale handling, output contents, and the relationship with the Booking Place endpoint. Since there is no output schema, the explicit enumeration of return fields is especially valuable and covers what an agent needs to understand the result shape.
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 already documents all 28 parameters with 100% coverage, so the baseline is 3. The description restates filter categories and some behaviors (e.g., guest composition, price range, pagination), but it adds limited semantic value beyond what the schema already provides for each parameter.
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 a specific action ('Searches Booking.com for accommodations') and a specific resource (destination keyword, stay dates, guest composition). It also differentiates itself from the sibling tool by noting that the returned `hotelId` / URL can be fed into the Booking Place endpoint for full property details.
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 gives strong usage context: it is for travel-planning, price/inventory monitoring, competitor analysis, and lead generation, and it points to the Booking Place endpoint as a downstream step for full property details. However, it does not explicitly state when NOT to use this tool or offer a direct comparison between the search and place endpoints, so the alternative guidance is implied rather than fully explicit.
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_booking_place_getBookingPlaceDetails - First observed
hasdata_booking_search_getBookingSearchResults
TDQS
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.
AI marketplace — flights, tours, activities, transport & more via MCP. No auth required.
Live Booking.com hotel prices, plus per-country pricing for rate-parity monitoring.
Airbnb stays by location and dates, and full listing details, as structured JSON.
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
- FlicenseNot gradedqualityDmaintenanceA Model Context Protocol (MCP) server that allows LLMs to search for hotels and destinations using the Booking.com API.28-

Dida Hotel MCPofficial
AlicenseNot gradedqualityBmaintenanceEnables AI agents to search and book hotels globally with real-time pricing and inventory from over 2 million properties.81MIT- FlicenseNot gradedqualityCmaintenanceProvides two MCP servers: one for searching real-time flight prices via FlightAPI.io and another for hotel prices via Booking.com through RapidAPI, both accessible over Streamable HTTP.-
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/booking-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server