Booking MCP Server
Servidor MCP de Booking.com
Un servidor alojado del Model Context Protocol (MCP) que ofrece a Claude, Cursor, Windsurf y cualquier otro cliente MCP dos herramientas de solo lectura de Booking.com. Busca estancias por destino y fechas con filtros avanzados, y lee una propiedad concreta completa, todo como JSON estructurado, sin cuenta de Booking.com y sin nada que alojar.
Lee las páginas públicas de propiedades en Booking.com que puede ver un visitante sin sesión iniciada.
https://mcp.hasdata.com/api/mcp?apis=booking
Contenido
Related MCP server: mydatavalue-mcp
Qué necesitas
Un cliente MCP y una clave de API de HasData del panel de control, que puedes crear gratis sin tarjeta; la prueba incluye 100 llamadas a la tarifa de 10 créditos. Este es un servidor remoto, por lo que la vía más sencilla es una URL y una cabecera x-api-key, sin contenedor que ejecutar y sin cuenta de Booking.com en ninguna parte del proceso. Un cliente que solo hable stdio llega a él mediante un lanzador ligero, publicado como @hasdata/booking-mcp en npm y hasdata-booking-mcp en PyPI, que se muestra abajo.
Inicio rápido
La URL del servidor es la misma para todos los clientes. Lo hemos probado en la práctica en Claude Code y Claude Desktop. Los demás bloques siguen el formato que cada cliente documenta para un servidor remoto.
Campo | Valor |
URL |
|
Transporte | HTTP, streamable |
Cabecera de autenticación |
|
Los clientes con soporte de OAuth pueden añadir la misma URL como conector e iniciar sesión sin poner una clave en un archivo de configuración.
claude mcp add --transport http booking "https://mcp.hasdata.com/api/mcp?apis=booking" \
--header "x-api-key: HASDATA_API_KEY"Ajustes, luego Conectores, luego Añadir conector personalizado, y pega https://mcp.hasdata.com/api/mcp?apis=booking e inicia sesión.
Para la vía del archivo de configuración, Claude Desktop solo carga servidores locales (stdio), por lo que accede a un servidor remoto mediante un lanzador stdio. El paquete @hasdata/booking-mcp es ese lanzador, y lee la clave desde el entorno. Añade esto a claude_desktop_config.json:
{
"mcpServers": {
"booking": {
"command": "npx",
"args": ["-y", "@hasdata/booking-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}Para Python en lugar de Node, sustituye el lanzador por el paquete de PyPI, que uvx ejecuta sin instalación manual:
{
"mcpServers": {
"booking": {
"command": "uvx",
"args": ["hasdata-booking-mcp"],
"env": { "HASDATA_API_KEY": "YOUR_KEY" }
}
}
}~/.cursor/mcp.json para cada proyecto, o .cursor/mcp.json para uno solo:
{
"mcpServers": {
"booking": {
"url": "https://mcp.hasdata.com/api/mcp?apis=booking",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}~/.codeium/windsurf/mcp_config.json. Windsurf llama al campo serverUrl, no url:
{
"mcpServers": {
"booking": {
"serverUrl": "https://mcp.hasdata.com/api/mcp?apis=booking",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}.vscode/mcp.json en el espacio de trabajo:
{
"servers": {
"booking": {
"type": "http",
"url": "https://mcp.hasdata.com/api/mcp?apis=booking",
"headers": { "x-api-key": "HASDATA_API_KEY" }
}
}
}Ejemplos de prompts
Son prompts, no código. Pega uno y el agente elige la herramienta por sí mismo. Cada uno indica las llamadas que requiere, porque cada llamada correcta cuesta 10 créditos.
Busca en Booking.com hoteles en París del 15 al 18 de septiembre para dos adultos y dame los diez mejor valorados por menos de $700 para la estancia.
Una llamada, 10 créditos. El precio, la puntuación de las reseñas y la ubicación se devuelven en el resultado de la búsqueda.
Toma el primer resultado y obtén todos sus detalles: instalaciones, normas de la casa, las opciones de habitación y las valoraciones por categoría.
Una llamada, 10 créditos. Esos datos están en la página de la propiedad, que la herramienta de detalles lee mediante URL y fechas.
Encuentra hoteles de cuatro estrellas en París con cancelación gratuita cerca del centro, y lista el precio y la puntuación de las reseñas.
Una llamada, 10 créditos. La categoría por estrellas, la política de cancelación y la distancia son filtros en una única solicitud.
Compara la estancia más barata en París con la de Roma para las mismas fechas.
Dos llamadas, 20 créditos, una búsqueda por ciudad.
La herramienta de propiedades necesita las mismas fechas y el mismo número de huéspedes que la búsqueda, porque la disponibilidad y el precio dependen del período. Una búsqueda para preseleccionar y una llamada de detalles sobre tres propiedades son una búsqueda y tres llamadas de propiedad.
Herramientas
Dos herramientas, de solo lectura. Los ejemplos siguientes están abreviados a partir de llamadas reales, y los precios cambian constantemente. Léelos como esquemas. Cada nombre de herramienta enlaza con su referencia de endpoint, que incluye la lista completa de campos.
Los ejemplos son el payload, no la respuesta completa. Un resultado de tools/call lleva un bloque de texto, y ese texto es en sí mismo JSON que contiene url, status, text y json, con los datos extraídos en json. Desde una respuesta JSON-RPC sin procesar, la ruta es result.content[0].text, que se parsea y luego .json. Un cliente de chat te lo desempaqueta, y el código que habla directamente con el endpoint no lo hace.
Obtener resultados de búsqueda de Booking.com
hasdata_booking_search_getBookingSearchResults
Una página de estancias por destino y fechas.
Parámetro | Tipo | Obligatorio | Notas |
| string | Sí | Destino, como |
| string | Sí |
|
| number | Sí | Composición de los huéspedes. Pasa |
| string | Edades separadas por comas, obligatorio cuando | |
| string |
| |
| array | Tipo de propiedad, categoría por estrellas y tramos de puntuación de los huéspedes | |
| array | Filtros de instalaciones, de habitación y de cancelación | |
| number | Banda de precio total de la estancia | |
| number | Unos 25 resultados por página, |
La referencia documenta el conjunto completo de filtros, incluidos distancia, comidas, accesibilidad, preferencia de cama y grupo de viaje.
Devuelve searchInformation, un array results y pagination con page, totalResults y totalPages. Cada resultado incluye hotelId, title, url, la room ofrecida y bedTypes, un objeto location, un objeto policies, un objeto price, el rating de estrellas, un objeto reviews con score, count y una etiqueta de texto, y una photo.
El campo de descuento en
pricese escribedicsount(dicsountRawydicsountParsed), que refleja la clave del origen. Lee esa grafía, nodiscount. Ten en cuenta también queratinges la categoría oficial por estrellas, mientras quereviews.scorees la puntuación de los huéspedes sobre 10, dos números distintos.
{
"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" }
}Obtener detalles de la propiedad de Booking.com
hasdata_booking_place_getBookingPlaceDetails
Una propiedad completa, a partir de su URL y el período de la estancia.
Parámetro | Tipo | Obligatorio | Notas |
| string | Sí | La URL de una propiedad de Booking.com, el campo |
| string | Sí |
|
| number | Sí | Composición de los huéspedes, con el mismo significado que en la herramienta de búsqueda |
| string | Edades separadas por comas, obligatorio cuando |
Devuelve la página en secciones, no como un único objeto plano: overview (id, title, propertyType, una address estructurada, una description, highlights, mostPopularFacilities y photos), bookingDetails (el período y la moneda que reflejan los precios), un array rooms de las habitaciones disponibles, cada una con name, beds, facilities y variants con precio, una lista facilities, houseRules, un array ratings de puntuaciones por categoría, reviews y 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 }
]
}Errores y casos de fallo
Tu cliente casi nunca ve un código de error HTTP en una llamada de herramienta. La capa MCP responde con 200 y coloca el fallo dentro del resultado, con isError establecido en true y el motivo como texto. El agente lee un mensaje cuando cabría esperar una línea de estado.
Una clave incorrecta aparece como salida de la herramienta, no como una conexión fallida. tools/list acepta cualquier clave no vacía y devuelve ambas herramientas, por lo que el cliente completa su handshake y se muestra en verde. La primera llamada a una herramienta devuelve entonces isError: true y el texto HasData API error: 401 Unauthorized. Busca esa cadena, porque nada anterior en el flujo notifica el problema.
La ausencia de clave es el único error HTTP real. La autorización se ejecuta antes que cualquier herramienta, y la conexión en sí falla con 401. Las cabeceras CORS están presentes, y un cliente de navegador lee el estado y no un fallo de red opaco.
Un argumento que rompe el esquema de una herramienta se rechaza antes de convertirse en un raspado. El servidor responde con isError: true y el texto MCP error -32602: Input validation error, indicando el campo infractor. Un recuento de children sin los childrenAges correspondientes, o una fecha de salida igual o anterior a la de entrada, se detecta aquí.
Una búsqueda sin disponibilidad devuelve un resultado correcto con un array results vacío, no un error. Un destino y un período sin disponibilidad se devuelven igualmente con requestMetadata.status establecido en ok. Comprueba la longitud del array antes de iterar.
Una URL de propiedad que ya no resuelve devuelve 400 con requestMetadata.status establecido en error.
Los resultados que contienen datos también incluyen un requestMetadata.id que merece la pena citar en el soporte.
Precios, plan gratuito y límites
Cada herramienta de Booking.com cuesta 10 créditos por llamada correcta. El tamaño de la respuesta no cambia el precio. Una página de búsqueda con 25 alojamientos cuesta lo mismo que una con dos.
La prueba gratuita incluye 1.000 créditos durante 30 días sin tarjeta, es decir, 100 llamadas a Booking.com. Después, una cuenta activa sigue recibiendo una recarga de 100 créditos al día siempre que su saldo baje de 100, por lo que un agente de bajo volumen funciona en el plan gratuito indefinidamente.
Los planes de pago empiezan en 49 $ al mes por 200.000 créditos, lo que equivale a 20.000 llamadas. El precio unitario baja con el volumen, desde 2,45 $ por cada 1.000 llamadas en el plan inicial hasta 0,99 $ en Business, 0,83 $ en Growth y 0,75 $ en los planes de alto volumen más grandes.
Tu plan también establece la concurrencia. La prueba gratuita permite 1 solicitud a la vez, Startup 15, Business 30, Growth 50, y los planes de alto volumen van de 200 a 1.500. Gestiona el caso de desbordamiento de forma defensiva en cualquier proceso desatendido.
Una solicitud que devuelve un código distinto de 200 no se factura. Una llamada correcta que no encuentra nada sigue siendo una llamada.
Selección de herramientas
El parámetro de consulta apis determina qué herramientas ve tu agente. Cuantas menos herramientas, menos contexto se gasta en las definiciones de las herramientas y menos probabilidades hay de que el modelo elija la equivocada.
?apis=booking the two tools in this repo
?apis=booking,airbnb add Airbnb stays
?apis=booking,google_travel add Google Hotels and FlightsEl parámetro acepta nombres de proveedor como booking y nombres de API individuales como booking_search. Los nombres mal escritos se ignoran. Si todos los nombres son incorrectos, la solicitud falla con 400, y el cuerpo indica tanto lo que no reconoció como todos los valores válidos. Si omites el parámetro, el mismo endpoint expone las 57 herramientas de HasData.
Comparativa
Los programas propios de Booking.com (la Demand API y la red de socios afiliados) son para socios aprobados que envían reservas y ganan comisiones, no una forma autoservicio de leer el mercado público. Para buscar alojamientos y consultar propiedades concretas, la vía es extraer las páginas públicas, y este servidor lo hace con un esquema estable.
Programas de socios de Booking.com | Este servidor | |
Propósito | Enviar reservas como afiliado aprobado | Leer el mercado público |
Acceso | Aprobación de socio | Una clave y una URL |
Búsqueda en el mercado | Dentro de los términos del socio | Sí, con filtros avanzados |
Configuración | Incorporación para empresas | Ninguna |
Salida | Feeds de socios | JSON estructurado, precio y puntuación preprocesados |
Lo que este servidor no hace. Nada de reservas, pagos, comisiones de socios ni datos de cuenta. Lee lo que un visitante sin sesión puede ver en Booking.com.
Preguntas frecuentes
¿Existe un servidor MCP oficial de Booking.com?
Booking.com no publica ninguno. Este está mantenido por HasData y lee páginas públicas, por eso no necesita ninguna cuenta de Booking.com.
¿Qué es un servidor MCP de Booking.com?
Un servidor que expone los datos de Booking.com como herramientas que un cliente de IA puede llamar. El cliente envía una llamada a herramienta a través del Model Context Protocol, el servidor obtiene los datos y devuelve JSON estructurado, y el modelo trabaja con el resultado. Este expone dos herramientas y se ejecuta de forma remota.
¿Necesito una cuenta de Booking.com o la aprobación de socio?
No. La única credencial es tu clave de HasData. No hay ningún proceso de incorporación de socios, porque las herramientas leen páginas públicas de Booking.com.
¿Por qué la herramienta de alojamientos necesita fechas?
Porque la disponibilidad, las opciones de habitación y el precio dependen de la ventana de estancia. Pasa las mismas checkInDate, checkOutDate y los mismos números de huéspedes que usaste en la búsqueda, y el detalle reflejará esa ventana.
¿Cuál es la diferencia entre la calificación y la puntuación de las reseñas?
rating es la calificación oficial por estrellas del alojamiento. reviews.score es la puntuación de las reseñas de los huéspedes sobre 10. Un hotel de tres estrellas puede tener una puntuación de huéspedes de 9,0, así que consulta la que quieras indicar.
¿Puedo usar esto junto con otras APIs de HasData?
Sí. El parámetro apis acepta una lista, y ?apis=booking,airbnb le da a tu agente Booking.com y Airbnb. Omite el parámetro y lo tendrás todo.
¿Está HasData afiliada a Booking.com?
No. HasData es un servicio independiente y no está afiliado a Booking.com, ni cuenta con su respaldo o patrocinio. Booking.com es una marca comercial de su respectivo propietario.
Cumplimiento y datos personales
HasData solo accede a datos disponibles públicamente. Los términos de una plataforma pueden restringir el acceso automatizado, y tú eres responsable de tu propio cumplimiento. Cuando los datos que recopiles incluyan información personal, asegúrate de tener una base legal para ello en virtud del GDPR, la CCPA o las normas equivalentes de tu jurisdicción.
Enlaces de HasData
Página del producto y constructor de solicitudes | |
Documentación del servidor | |
Las 57 herramientas en un solo servidor | |
Tutoriales para clientes | |
Todo lo demás que extraemos | |
Planes y costes de créditos | |
Claves y uso | |
Lanzador de Node en npm | |
Lanzador de Python en PyPI |
Desarrollo
Este repositorio es configuración y documentación para un servidor remoto. No hay paso de compilación ni nada que contenerizar.
Las pruebas en test/ verifican el contrato de las herramientas, la parte que puede romperse sin un commit aquí. Comprueban que ?apis=booking devuelve exactamente dos herramientas, que cada herramienta sigue declarando sus parámetros obligatorios, que ningún nombre ha cambiado y que la clave en uso es realmente aceptada. Esa última comprobación llama a una herramienta de verdad y cuesta 10 créditos, que es el precio de un canario que puede fallar por el motivo correcto.
# macOS and Linux
HASDATA_API_KEY=your_key_here npm test
# Windows PowerShell
$env:HASDATA_API_KEY="your_key_here"; npm testLa misma suite se ejecuta en CI en cada push y una vez por semana de forma programada, porque la lista de herramientas upstream puede cambiar sin que nadie toque este repositorio. Un fallo significa que la lista de herramientas se ha movido, que la clave ha dejado de funcionar o que el endpoint no era accesible, y el mensaje de aserción indica cuál de ellos.
Contribuciones
Las correcciones de las tablas de herramientas y de las muestras de respuesta son la contribución más útil, porque son las partes que más se desactualizan. Incluye la llamada que hiciste y la respuesta que obtuviste. Las pull requests de forks ejecutan la suite sin clave, y las comprobaciones en vivo se omiten en lugar de ponerse en rojo.
Licencia
MIT. Ver 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.1031 npm64 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.216 npm52 PyPI8MIT