Skip to main content
Glama

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

Glama score tool contract MCP Tools npm PyPI License

Contenido

Related MCP server: Hotels MCP Server

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

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

Transporte

HTTP, streamable

Cabecera de autenticación

x-api-key: HASDATA_API_KEY

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

keyword

string

Destino, como Paris o el nombre de una propiedad concreta

checkInDate / checkOutDate

string

YYYY-MM-DD, fecha de entrada futura y anterior a la fecha de salida

rooms / adults / children

number

Composición de los huéspedes. Pasa children: 0 cuando no haya ninguno

childrenAges

string

Edades separadas por comas, obligatorio cuando children > 0

sort

string

priceLowestFirst, ratingHighToLow, bestReviewedAndLowestPrice, distanceFromDowntown y más

propertyType__ / rating__ / reviewScore__

array

Tipo de propiedad, categoría por estrellas y tramos de puntuación de los huéspedes

facilities__ / roomFacilities__ / reservationPolicy__

array

Filtros de instalaciones, de habitación y de cancelación

price_min_ / price_max_

number

Banda de precio total de la estancia

page

number

Unos 25 resultados por página, 2 para la siguiente 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 price se escribe dicsount (dicsountRaw y dicsountParsed), que refleja la clave del origen. Lee esa grafía, no discount. Ten en cuenta también que rating es la categoría oficial por estrellas, mientras que reviews.score es 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

url

string

La URL de una propiedad de Booking.com, el campo url de un resultado de búsqueda

checkInDate / checkOutDate

string

YYYY-MM-DD, el período para el que se calcula el precio y se consulta la disponibilidad

rooms / adults / children

number

Composición de los huéspedes, con el mismo significado que en la herramienta de búsqueda

childrenAges

string

Edades separadas por comas, obligatorio cuando children > 0

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 Flights

El 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

Booking.com Scraper API

Documentación del servidor

Documentación del servidor MCP

Las 57 herramientas en un solo servidor

HasData/hasdata-mcp

Tutoriales para clientes

Clientes e integraciones MCP

Todo lo demás que extraemos

Booking.com Scraper API y 54 más

Planes y costes de créditos

Planes y costes de créditos

Claves y uso

Panel de HasData

Lanzador de Node en npm

@hasdata/booking-mcp

Lanzador de Python en PyPI

hasdata-booking-mcp

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 test

La 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 tools
hasdata_booking_place_getBookingPlaceDetailsbooking_place: GET /AInspect

Get Booking Hotel Details

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

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesFull Booking.com URL of the property page. Only `booking.com` and `www.booking.com` hosts are accepted.
roomsYesNumber of rooms to book.
adultsYesNumber of adult guests across all rooms.
childrenYesNumber of child guests across all rooms (0–10). Pass `0` if there are no children.
currencyNoCurrency 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`.
languageNoLanguage of the Booking.com interface and localized fields in the response.
checkInDateYesCheck-in date in `YYYY-MM-DD` format. Must be in the future and earlier than `checkOutDate`.
checkOutDateYesCheck-out date in `YYYY-MM-DD` format. Must be later than `checkInDate`.
childrenAgesNoComma-separated list of child ages, one entry per child (each `0`–`17`). Required when `children > 0` and the number of ages must equal `children`. Example: `1,3,7`

TDQS

A4.1/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoPage number of the search results. Booking.com returns 25 results per page; pass `2` for results 26–50, `3` for 51–75, etc.
sortNoSort order applied by Booking.com to the results page.
roomsYesNumber of rooms to book.
adultsYesNumber of adult guests across all rooms.
keywordYesFree-text destination query. Usually a city, region or neighborhood (e.g. `Paris`, `Manhattan, New York`); a specific property name is also accepted.
meals__NoFilter by available meal plans. Multiple values are combined with OR.
bedroomsNoMinimum number of bedrooms in the property.
childrenYesNumber of child guests across all rooms (0–10). Pass `0` if there are no children.
currencyNoCurrency 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`.
languageNoLanguage of the Booking.com interface and localized fields in the response.
rating__NoFilter by official star rating. Multiple values are combined with OR.
bathroomsNoMinimum number of bathrooms in the property.
price_max_NoMaximum 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_NoMinimum total price for the stay, in the requested `currency`. Must be `>= 10`. Required if `price[max]` is omitted.
checkInDateYesCheck-in date in `YYYY-MM-DD` format. Must be in the future and earlier than `checkOutDate`.
checkOutDateYesCheck-out date in `YYYY-MM-DD` format. Must be later than `checkInDate`.
childrenAgesNoComma-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__NoFilter by property-level facilities. Multiple values are combined with OR.
reviewScore__NoFilter by minimum guest review score bucket. Multiple values are combined with OR.
travelGroup__NoFilter by travel-group oriented stay options. Multiple values are combined with OR.
propertyType__NoFilter by property type. Multiple values are combined with OR.
bedPreference__NoFilter by bed configuration. Multiple values are combined with OR.
onlinePayment__NoFilter by online payment options.
roomFacilities__NoFilter by in-room facilities. Multiple values are combined with OR.
reservationPolicy__NoFilter by reservation flexibility. Multiple values are combined with OR.
roomAccessibility__NoFilter by in-room accessibility features. Multiple values are combined with OR.
distanceFromCenter__NoFilter by distance from the destination center. Multiple values are combined with OR.
propertyAccessibility__NoFilter by property-level accessibility features. Multiple values are combined with OR.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden, 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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

  1. 2 tool updatesv1.0.0
    • First observedhasdata_booking_place_getBookingPlaceDetails
    • First observedhasdata_booking_search_getBookingSearchResults

TDQS

A4.3/5.0
Disambiguation5/5

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

Naming Consistency5/5

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

Tool Count3/5

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

Completeness5/5

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

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to search and book hotels globally with real-time pricing and inventory from over 2 million properties.
    81
    MIT
  • F
    license
    Not graded
    quality
    C
    maintenance
    Provides 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

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