Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Booking Search hotels in Paris for June 1-5, 2 adults"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Booking.com — search hotels, check availability, manage reservations, and more via AI agents.
By Strider Labs
This MCP (Model Context Protocol) server gives AI agents the ability to interact with Booking.com using browser automation (Playwright). It supports 14 tools covering the full hotel booking workflow.
Related MCP server: Amadeus Hotel API MCP Server
Tool | Description |
| Check login/session status |
| Open a browser window to sign in (non-blocking; returns immediately) |
| Check progress of an in-flight |
| Clear saved session and cookies |
| Search hotels by destination, dates, guests, rooms, and amenities (pets, parking, pool, …) |
| Get property details (amenities, description, policies, structured |
| Check room availability for specific dates |
| Get pricing for a property |
| Filter last search by price, rating, amenities |
| Sort last search by price/rating/distance/reviews |
| Save to wishlist/favorites |
| Get a "continue in your browser" booking link (does not place the booking) |
| List current/upcoming reservations |
| Cancel a booking (requires |
| Get guest reviews for a property |
Node.js 18+
A Booking.com account (for bookings, reservations, and wishlist)
npm install @striderlabs/mcp-bookingOr install Playwright browsers after install:
npx playwright install chromiumAdd to your MCP config (e.g. ~/.claude/mcp_servers.json):
{
"mcpServers": {
"booking": {
"command": "npx",
"args": ["-y", "@striderlabs/mcp-booking"]
}
}
}The server uses cookie-based session persistence. Login is non-blocking (two steps) so it won't hang your MCP client while you wait on an emailed verification code:
Run booking_login. It opens a visible browser window at the Booking.com sign-in page and returns immediately.
Sign in in that window (including any email/SMS code or 2FA/CAPTCHA). A background poller watches for completion.
Run booking_login_status to check progress — it reports in_progress, success, failed, or idle. Poll it until it's no longer in_progress.
On success the session is captured and saved automatically; booking_status will then show you as logged in.
The background poller waits up to ~10 min by default; pass timeoutSeconds to
booking_login to extend it (up to 30 min) if a verification code is slow to
arrive. If the window is closed or the deadline passes before sign-in completes,
the status becomes failed and the window is cleaned up — just call
booking_login again.
Because login drives a real browser window, it requires Google Chrome installed and a desktop display — it cannot run on a headless server.
Session cookies are stored at ~/.strider/booking/cookies.json, scoped to Booking.com domains only (unrelated third-party/tracking cookies are not persisted).
The config directory (0700) and the cookie/session files (0600) are created with owner-only permissions. The files are not encrypted — protect your home directory accordingly.
booking_logout deletes the saved cookies and session.
booking_search(destination="Paris", checkIn="2026-06-01", checkOut="2026-06-05", adults=2, rooms=1)Use flex_window to widen the search around your exact dates, like the Android app "I'm flexible" feature:
# ±2 days flexibility around July 10-13
booking_search(destination="Paris", checkIn="2026-07-10", checkOut="2026-07-13", flex_window=2)
# ±7 days (full week flexibility)
booking_search(destination="Paris", checkIn="2026-07-10", checkOut="2026-07-13", flex_window=7)flex_window values: 0 (exact, default), 1 (±1 day), 2 (±2 days), 3 (±3 days), 7 (±7 days).
The price returned by booking_search is usually the total stay price (not per-night) on multi-night searches:
pricePerNight / totalPrice: same numeric value — the price shown on the Booking.com card
priceIsTotal: true when the card shows total stay price; false only when explicitly labelled "per night"
priceNote: raw text from the card (e.g. "CHF 450 for 3 nights") — use this to verify context
currency: auto-detected from the card (CHF, EUR, USD, etc.)
For multi-night stays, divide totalPrice by number of nights to get the actual nightly rate.
Amenity filters are applied server-side via Booking.com's nflt parameter, so results only contain matching properties.
# Pet-friendly hotels with parking and a pool
booking_search(destination="Rome", checkIn="2026-06-01", checkOut="2026-06-05", amenities=["pets", "parking", "pool"])Supported amenity keys: pets, parking, pool, restaurant, room_service, front_desk_24h, fitness, non_smoking, airport_shuttle, family_rooms, ev_charging, spa, hot_tub, sauna, free_wifi, air_conditioning.
For a single property, booking_get_property returns a structured facilitySummary (e.g. petsAllowed, parking, pool, spa) where true = offered/allowed, false = not allowed, null = not mentioned on the page.
Note: amenity → filter codes are reverse-engineered from Booking.com's UI (undocumented but stable). If a filter behaves unexpectedly, supply an exact chip via
rawNflt(e.g.rawNflt="hotelfacility=4;popular_activities=2").
booking_filter_results(maxPrice=200, minRating=8.0, freeCancellation=true)
booking_sort_results(sortBy="rating")booking_check_availability(propertyUrl="https://www.booking.com/hotel/fr/...", checkIn="2026-06-01", checkOut="2026-06-05")
booking_get_prices(propertyUrl="...", checkIn="2026-06-01", checkOut="2026-06-05")booking_book does not place a booking. Booking.com checkout is a multi-step
wizard (room selection → guest contact details → payment) that can't be reliably
completed via automation, so this returns a bookingUrl to finish in a browser.
# Returns a bookingUrl (property page with dates/occupancy pre-filled,
# opening on the room list with "Reserve" buttons) to complete in a browser.
booking_book(propertyUrl="...", checkIn="2026-06-01", checkOut="2026-06-05", adults=2)
# Optional: also best-effort capture a deeper checkoutUrl with the first
# available room pre-selected (still stops before any guest/payment details).
booking_book(propertyUrl="...", checkIn="2026-06-01", checkOut="2026-06-05", adults=2, advanceToCheckout=true)# List current/upcoming reservations. Each result's reservationId is the trip id
# (or "<tripId>-<n>" for a specific booking within a multi-booking trip).
booking_get_reservations()
# Cancel walks Booking.com's multi-step flow: confirmation page -> "Cancel your
# booking" -> reason survey (Step 1 of 2) -> final confirm (Step 2). The final
# step is irreversible, so it only runs with confirm=true.
booking_cancel_reservation(reservationId="308612662158023") # no-op preview
booking_cancel_reservation(reservationId="308612662158023", confirm=true) # actually cancelsbooking_book never places a booking — it returns a link to complete checkout (contact details + payment) in a browser
booking_cancel_reservation requires confirm=true; without it, it returns a no-op warning and never opens a browser. With it, it drives the multi-step cancel flow (reason survey + final confirm) and the last step is irreversible
npm install
npm run build
npm startMIT — Strider Labs
Get a 'continue in your browser' link to book a room. Booking.com checkout is a multi-step wizard (room selection, guest contact details, then payment) that cannot be reliably completed via automation, so this NEVER places a booking. It returns a bookingUrl (the property page with dates/occupancy pre-filled, opening directly on the room list with Reserve buttons) for the user to finish by hand. Set advanceToCheckout=true to also best-effort capture a deeper checkoutUrl with the first available room pre-selected.
| Name | Required | Description | Default |
|---|---|---|---|
| rooms | No | Number of rooms (default: 1) | |
| adults | No | Number of adults (default: 2) | |
| checkIn | Yes | Check-in date in YYYY-MM-DD format | |
| checkOut | Yes | Check-out date in YYYY-MM-DD format | |
| propertyUrl | Yes | Full property URL or propertyId from search results | |
| advanceToCheckout | No | If true, best-effort: select the first available room and capture a deeper checkoutUrl (still stops before any guest/payment details). If false or omitted, only the property+dates bookingUrl is returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: the multi-step wizard cannot be automated, the tool never places a booking, and the two modes (returning bookingUrl or best-effort checkoutUrl).
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 slightly long but well-structured: first purpose, then limitation, then mode details. Every sentence adds value, though could be trimmed.
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 no annotations and no output schema, the description adequately explains the return value and behavior. It covers the essential aspects for correct usage.
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?
Schema coverage is 100%, but the description adds value by explaining propertyUrl can be a URL or propertyId, and advanceToCheckout behavior is clarified beyond the schema.
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 it gets a 'continue in your browser' link to book a room and explicitly says it NEVER places a booking, distinguishing it from siblings like booking_check_availability or booking_cancel_reservation.
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?
It explains when to use the tool (to obtain a URL for manual booking) and details the advanceToCheckout option. It lacks explicit exclusion of other scenarios but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel an existing reservation. Walks Booking.com's multi-step cancel flow (confirmation page, reason survey, final confirm). IMPORTANT: Set confirm=true only with explicit user confirmation — the final step is irreversible. Without confirm=true it returns a no-op warning and never opens a browser.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | Set to true to actually cancel. If false or omitted, returns a warning instead. NEVER set to true without explicit user confirmation. | |
| reservationId | Yes | The reservationId from booking_get_reservations (the trip id, or '<tripId>-<n>' for a specific booking in a multi-booking trip). A full confirmation/detail URL is also accepted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses irreversible cancellation with confirm=true, the multi-step flow, and that without confirm=true it returns a warning and never opens a browser. No contradictions.
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?
Two sentences with zero waste. The critical purpose is front-loaded, followed by essential usage notes. Every sentence earns its place.
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 no output schema, description adequately covers behavior for both confirm states and the multi-step flow. It does not detail post-cancellation results (e.g., refund), but main requirements are met.
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?
Schema coverage is 100%, baseline 3. Description adds context: explains confirm's irreversible effect and reservationId format (including multi-booking trips and URL acceptance), which adds value beyond schema.
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 cancels an existing reservation, using specific verb 'cancel' and resource 'reservation'. It distinguishes from siblings like booking_book (make reservation) and booking_get_reservations (retrieve reservations).
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 clear guidance: use confirm=true only with explicit user confirmation; without confirm, it's a no-op warning. It explains the multi-step flow, but does not explicitly compare with alternatives like modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check room availability for a specific property and date range. Returns available room types and options.
| Name | Required | Description | Default |
|---|---|---|---|
| rooms | No | Number of rooms (default: 1) | |
| adults | No | Number of adults (default: 2) | |
| checkIn | Yes | Check-in date in YYYY-MM-DD format | |
| checkOut | Yes | Check-out date in YYYY-MM-DD format | |
| propertyUrl | Yes | Full property URL or propertyId from search results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description bears full burden. It states the tool returns available room types and options but does not disclose whether it is read-only, effects on system, authentication needs, or rate limits.
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?
Two concise sentences with no wasted words. Front-loaded with verb and resource, then outcome.
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 moderate complexity (5 params, no output schema, no annotations), the description covers purpose and outcome. Minor omissions: lacks detail on response format or prerequisites like having propertyId from search.
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?
Schema covers 100% of parameters with descriptions. The description reiterates 'specific property and date range' but adds no new meaning beyond the schema, e.g., clarifying propertyUrl can be URL or ID.
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 verb 'check', the resource 'room availability', and the scope 'for a specific property and date range'. It distinguishes from siblings like booking_book (booking) and booking_get_prices (pricing) by focusing on availability.
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 implies usage for checking availability before booking but does not explicitly state when to use it vs alternatives like booking_get_prices or booking_book. No exclusions or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Client-side filter over the most recent booking_search results by price, review score, star rating, free cancellation, breakfast, or a name/location keyword. Returns a filtered subset. To filter by facilities like pets, parking, or pool, use the amenities argument on booking_search instead (filtered server-side).
| Name | Required | Description | Default |
|---|---|---|---|
| stars | No | Filter by star rating (1-5) | |
| keyword | No | Filter by keyword in property name or location | |
| maxPrice | No | Maximum price per night | |
| minPrice | No | Minimum price per night | |
| minRating | No | Minimum review score (0-10) | |
| freeCancellation | No | Only show properties with free cancellation | |
| breakfastIncluded | No | Only show properties with breakfast included |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It clarifies the tool is client-side filtering (operating on in-memory results), which is non-destructive. It does not mention edge cases like empty results, but the behavior is straightforward for a filter.
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?
Two sentences, no wasted words. The first sentence lists all filter options, and the second provides important guidance on alternative tool usage. Information is front-loaded and easy to parse.
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 7 parameters with 100% schema coverage and no output schema, the description is largely complete. It explains the client-side nature and return type ('filtered subset'). It could mention that results are limited to the most recent search, but that is already stated.
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?
Schema coverage is 100%, so baseline 3. The description adds meaning by grouping filter types (price, review score, star rating, etc.) and clarifying the keyword filter applies to name/location. This adds context beyond the schema's brief descriptions.
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 it is a client-side filter over recent booking_search results, listing specific filter criteria (price, review score, star rating, free cancellation, breakfast, keyword). It distinguishes from sibling tools by noting that facility filtering is done server-side via booking_search.
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?
Explicitly states when to use this tool (client-side filtering after search) and when not (for amenities, use booking_search with the amenities argument). Provides a clear alternative, helping the agent decide correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current prices for a property for specific dates. Returns room options with pricing details and the lowest available price.
| Name | Required | Description | Default |
|---|---|---|---|
| rooms | No | Number of rooms (default: 1) | |
| adults | No | Number of adults (default: 2) | |
| checkIn | Yes | Check-in date in YYYY-MM-DD format | |
| checkOut | Yes | Check-out date in YYYY-MM-DD format | |
| propertyUrl | Yes | Full property URL or propertyId from search results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns pricing details and the lowest price, but does not mention idempotency, rate limits, authentication requirements, or any side effects. For a read operation, this is minimally adequate but lacks depth.
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 concise, consisting of two sentences that cover the core functionality. However, it could be structured more effectively (e.g., bullet points or a clear distinction between input and output).
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 absence of an output schema, the description explains return values (room options, pricing details, lowest price). However, it lacks context about how to obtain the required 'propertyUrl', any prerequisites, or potential caveats like price volatility. It is functional but not fully comprehensive.
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?
Schema description coverage is 100%, so baseline score is 3. The description does not add significant extra meaning beyond what the schema already provides for each parameter; it essentially restates the purpose without elaborating on format, constraints, or relationships.
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 action ('Get current prices'), the resource ('a property'), and the constraints ('for specific dates'). It also specifies the return type ('room options with pricing details and lowest available price'). However, it does not explicitly differentiate from sibling tools like 'booking_check_availability', which might serve a similar purpose.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., requiring a propertyUrl from search results) or scenarios where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific property, including amenities, description, photos, raw policies, and a structured facilitySummary (parking, pool, fitness, spa, airConditioning, freeWifi, etc.). Facility fields are true when the amenity is found on the page or null when not mentioned. petsAllowed is the only tri-state field: true (allowed), false (explicitly not allowed), or null (not mentioned); petsPolicy carries the raw pet-policy text when present.
| Name | Required | Description | Default |
|---|---|---|---|
| propertyUrl | Yes | Full URL of the property page, or a propertyId from booking_search results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the behavior of facility fields (true when present, null when not mentioned) and the tri-state nature of petsAllowed (true/false/null). It also mentions raw pet-policy text, adding clarity beyond basic get operation.
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 single, dense paragraph that efficiently conveys all necessary information. It starts with the purpose and then details output fields without waste. Every sentence adds value.
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, the description provides comprehensive details on return values: amenities, description, photos, raw policies, and facilitySummary. It explains field behavior and special cases (petsAllowed). The tool has only one parameter, so completeness is high.
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?
Schema coverage is 100% with one parameter (propertyUrl). The description does not add additional semantic information beyond what the schema provides (URL or ID). Baseline 3 is appropriate.
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 retrieves detailed property information, listing specific features (amenities, description, photos, policies, facilitySummary). It distinguishes from sibling tools like booking_book or booking_search that serve different purposes.
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 does not provide explicit guidance on when to use this tool versus alternatives (e.g., when to use booking_get_prices or booking_get_reviews instead). It is implied that one uses it for property details, but no when-not-to or comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all current and upcoming reservations from your Booking.com account. Requires being logged in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only mentions a login requirement, but does not disclose other behavioral traits such as read-only nature, potential errors, or pagination.
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 single, direct sentence with no extraneous words, achieving high conciseness.
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?
Despite simple tool nature, the description omits details about return format or content of reservations, which is important for an agent to understand the output without an output schema.
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?
Input schema has zero parameters, so description does not need to elaborate. Baseline score of 4 applies as schema coverage is 100%.
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 retrieves all current and upcoming reservations, which distinguishes it from sibling tools like booking_cancel_reservation and booking_book.
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 includes a prerequisite ('Requires being logged in') but does not provide guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get guest reviews for a property, including scores, comments, and reviewer details.
| Name | Required | Description | Default |
|---|---|---|---|
| maxReviews | No | Maximum number of reviews to return (default: 10, max: 50) | |
| propertyUrl | Yes | Full property URL or propertyId from search results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It fails to disclose any behavioral traits such as rate limits, authentication needs, or side effects. For a read operation, this is a notable gap.
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 single, well-formed sentence with no extraneous information. It is appropriately front-loaded and efficient.
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 mentions included return fields (scores, comments, reviewer details) but lacks details on pagination, response format, or limit behavior. Given no output schema, more context would be helpful.
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?
Schema description coverage is 100%, so the input schema already documents both parameters. The description adds no extra meaning for parameters, but does indicate the return content (scores, comments, details). Baseline 3 is appropriate.
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 retrieves guest reviews and lists included data: scores, comments, and reviewer details. It is specific and distinguishable from siblings like booking_get_property or booking_search.
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 does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. However, the context of sibling tools makes the use case obvious (reviews vs. other operations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an interactive Booking.com login. Opens a VISIBLE browser window at the sign-in page and returns IMMEDIATELY (non-blocking) — sign-in runs in the background, so this won't hang the client while the user waits on an emailed/SMS code, 2FA or CAPTCHA. The user completes sign-in in that window, then you call booking_login_status to confirm the session was captured. Requires Google Chrome and a desktop display (cannot run on a headless server).
| Name | Required | Description | Default |
|---|---|---|---|
| timeoutSeconds | No | How long the background poller waits for sign-in to complete before giving up and closing the window, in seconds (default: 600 = 10 min, max: 1800 = 30 min). Increase if email/SMS verification codes are slow. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: visible browser, non-blocking return, background sign-in, user interaction, and post-call requirement. It also notes environment prerequisites. Could mention failure handling, but overall well-covered.
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?
Three sentences efficiently cover purpose, behavior, and post-conditions without waste. Information is front-loaded, and every sentence adds distinct value.
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's interactive nature and single parameter, the description covers core behavior, environment requirements, and subsequent step. Slightly lacking in failure modes, but adequate for the complexity.
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 single parameter 'timeoutSeconds' is fully described with default (600), range (max 1800), and use case guidance (increase for slow SMS codes). Schema coverage is 100%, and the description adds meaningful context beyond the schema.
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 uses specific verbs ('start', 'opens', 'returns') and clearly states the tool initiates an interactive Booking.com login. It distinguishes itself from sibling tools, notably mentioning 'booking_login_status' as the follow-up 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 explains when to use the tool (to start login), that it runs non-blocking, and directs the agent to call booking_login_status after user completes sign-in. It also specifies requirements (Chrome, desktop display) and timeout tuning. No explicit 'when not to use' guidance, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the progress of an interactive login started with booking_login. Returns status 'in_progress' (window still open, awaiting sign-in), 'success' (session captured and saved — other booking_* tools will reuse it), 'failed' (window closed or timed out before completing), or 'idle' (no login started). Poll this after calling booking_login until the status is no longer 'in_progress'.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it returns status strings, what each means, and the polling pattern. No side effects are implied, and it accurately reflects a read-only check.
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?
Two sentences, no wasted words, front-loaded with purpose, and efficiently conveys all necessary information.
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 no output schema and no parameters, the description fully covers the status values and usage pattern, leaving no gaps.
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?
No parameters exist, so the description adds meaning by explaining the return values and usage, exceeding the empty schema.
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 it checks the progress of an interactive login started with booking_login. It enumerates all possible statuses, distinguishing this tool from siblings like booking_login and booking_logout.
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?
Explicitly instructs to poll after calling booking_login until status is no longer 'in_progress', providing clear when-to-use guidance. The sibling context further reinforces its specific role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear saved Booking.com session and cookies. Use this to log out or reset authentication state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the behavioral trait of clearing session and cookies, which is a destructive action on authentication state. It does not detail reversibility or side effects on other states, but the core behavior is effectively communicated.
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 consists of two concise sentences with no extraneous information. The first sentence states the action, and the second specifies when to use it, making it efficient and well-structured.
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's simplicity (no parameters, no output schema), the description fully covers purpose and usage. It is complete for an agent to understand the tool's function and when to invoke it.
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 tool has zero parameters, so the description does not need to provide parameter info. The baseline score of 4 is appropriate as per guidelines for tools with no parameters.
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 clears Booking.com session and cookies, explicitly naming the resource (session/cookies) and action (clear). It distinguishes from siblings like booking_login and booking_login_status, which handle authentication establishment and status inquiry.
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 clear context: 'Use this to log out or reset authentication state.' It specifies when to use the tool but does not explicitly state when not to use it or mention alternatives. However, the sibling tools context makes the use case unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a property to your Booking.com wishlist/favorites. Requires being logged in.
| Name | Required | Description | Default |
|---|---|---|---|
| propertyUrl | Yes | Full property URL or propertyId from search results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only mentions the login requirement but does not disclose other behaviors (e.g., idempotency, what happens if already saved, side effects, or response format).
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 single sentence with no extraneous words. It is front-loaded and efficiently conveys the core purpose and a key prerequisite.
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's simplicity (1 parameter, no output schema), the description is minimally adequate. It states purpose and a condition but lacks details on return values or verification of success. Could be improved by noting what the tool returns or confirms.
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?
Schema coverage is 100% and the schema already describes the parameter ('Full property URL or propertyId from search results'). The description does not add additional meaning beyond what the schema provides, so baseline score applies.
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 action ('Save') and the target resource ('property to your Booking.com wishlist/favorites'). This distinguishes it from siblings like 'booking_book' (books) and 'booking_get_property' (retrieves info).
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?
Specifies a necessary condition ('Requires being logged in'), which aids in tool selection. However, it lacks explicit guidance on when not to use this tool or alternatives like 'booking_book' or 'booking_get_property'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for hotels and properties on Booking.com. Returns property names, ratings, prices, and availability indicators. Optionally filter server-side by amenities/facilities (e.g. pets, parking, pool) so only matching properties are returned.\n\nPRICE FIELDS: pricePerNight and totalPrice both carry the same numeric value extracted from the card. On multi-night searches this is typically the TOTAL stay price (not per-night). Check priceIsTotal (true = total, false = explicitly per-night) and priceNote (raw card text) for context. currency is auto-detected from the card text when visible (e.g. 'CHF', 'EUR', 'USD'). For accurate per-night pricing on multi-night stays, divide totalPrice by number of nights.
| Name | Required | Description | Default |
|---|---|---|---|
| rooms | No | Number of rooms (default: 1) | |
| adults | No | Number of adults (default: 2) | |
| checkIn | Yes | Check-in date in YYYY-MM-DD format | |
| rawNflt | No | Advanced/escape hatch: raw Booking.com `nflt` filter chips, ';'-delimited (e.g. 'hotelfacility=4;popular_activities=2'). Merged with `amenities`. Use when an amenity code needs correcting or for filters not in the amenities list. | |
| checkOut | Yes | Check-out date in YYYY-MM-DD format | |
| children | No | Number of children (default: 0) | |
| amenities | No | Filter results server-side to properties offering ALL of these amenities/facilities. Supported: pets, parking, pool, restaurant, room_service, front_desk_24h, fitness, non_smoking, airport_shuttle, family_rooms, ev_charging, spa, hot_tub, sauna, free_wifi, air_conditioning. Example: ["pets", "parking", "pool"] for pet-friendly hotels with parking and a pool. | |
| maxResults | No | Maximum results to return (default: 10, max: 50) | |
| destination | Yes | Destination to search (e.g. 'Paris', 'New York', 'Rome, Italy') | |
| flex_window | No | Date flexibility window (days). 0 = exact dates only (default). Positive values search with flexible dates around the given checkIn/checkOut: 1=±1 day, 2=±2 days, 3=±3 days, 7=±7 days. When >0, Booking.com returns properties available across the date window, which can reveal cheaper options just outside your exact dates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries full burden. It explains price fields ambiguity (pricePerNight vs totalPrice), priceIsTotal flag, currency detection, and server-side filtering. However, it misses details on pagination, error handling, and rate limits.
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 primary purpose and well-structured with a dedicated 'PRICE FIELDS' section. While somewhat lengthy, each sentence contributes meaning, making it efficient.
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 10 parameters and no output schema, the description covers search, filtering, flexibility, and price nuances. However, it lacks details about pagination, default sorting, or whether only available properties are returned, leaving some gaps.
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?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining price field relationships, flex_window behavior, and rawNflt usage, which go beyond the schema descriptions.
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's purpose: 'Search for hotels and properties on Booking.com' and lists what it returns. It distinguishes from siblings by focusing on the initial search with filtering, but does not explicitly compare to related tools like booking_check_availability or booking_get_prices.
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 does not provide guidance on when to use this tool versus alternatives like booking_check_availability or booking_filter_results. It implies usage for general search but lacks explicit when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sort the most recent booking_search results. Options: price_asc, price_desc, rating, distance, reviews.
| Name | Required | Description | Default |
|---|---|---|---|
| sortBy | Yes | Sort criteria: price_asc (cheapest first), price_desc (most expensive first), rating (highest rated), distance (closest to center), reviews (most reviewed) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states sorting action and options, but omits whether results are returned or modified, side effects, or any permissions needed. This is insufficient for full transparency.
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 single sentence plus a list of options, front-loaded with the core action. Every word is necessary; no filler or repetition. Ideal conciseness for the task.
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?
For a simple sort tool with one parameter and no output schema, the description adequately covers purpose and options. It could mention return value or state change, but given low complexity, it is mostly complete.
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?
Schema coverage is 100% with detailed enum descriptions, so baseline is 3. The tool description merely lists the options without adding extra meaning beyond the schema. No additional semantic value is provided.
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's action (sort) and resource (most recent booking_search results), which distinguishes it from sibling tools like booking_filter_results that filter but do not sort. The specific verb 'sort' and resource identification leave no ambiguity.
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 implies usage after booking_search, but provides no explicit guidance on prerequisites, when not to use, or alternatives. For example, it doesn't clarify that it only works on the last search or that it does not filter. Thus, guidance is adequate but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Booking.com login status and session info. Use this to verify authentication before performing other actions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The verb 'Check' implies a read-only operation, but the description does not explicitly state it has no side effects or what 'session info' entails. More detail would help, especially without annotations.
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?
Two sentences, zero waste. The first sentence states the action, the second gives usage guidance. Efficiently 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?
For a simple status check with no parameters and no output schema, the description is adequate. However, it could elaborate on what 'session info' includes or the expected response format to be fully complete.
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?
There are no parameters, and the schema coverage is 100%. The description adds no parameter info (unnecessary), but explains the tool's purpose, which is sufficient for a parameterless tool.
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 checks login status and session info. However, the sibling list includes 'booking_login_status', which likely has an overlapping purpose, and the description does not clarify the distinction.
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 advises using this tool to verify authentication before other actions, which is helpful. But it does not mention when not to use it (e.g., if already known) or provide alternatives like 'booking_login_status'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.1booking_bookbooking_cancel_reservationbooking_check_availabilitybooking_filter_resultsbooking_get_pricesbooking_get_propertybooking_get_reservationsbooking_get_reviewsbooking_loginbooking_login_statusbooking_logoutbooking_save_propertybooking_searchbooking_sort_resultsbooking_statusEvery tool has a clearly distinct purpose: search, filter, sort, check availability, get prices, get property details, book (with caveat), cancel, get reservations, save property, login/logout/status. No two tools overlap in functionality; each targets a specific action or resource.
Tools consistently use the 'booking_' prefix followed by a verb_noun pattern (e.g., booking_cancel_reservation, booking_get_prices). Minor inconsistency: 'booking_status' uses a noun alone (no verb), which deviates from the predominant verb-first pattern.
With 15 tools covering search, filtering, pricing, property details, reservations, authentication, and wishlist management, the count is well-scoped for a booking service. Each tool has a clear role, neither too few nor too many for the domain.
The tool set covers most of the booking lifecycle but has a notable gap: 'booking_book' explicitly does not complete a booking (only provides a link for manual finishing). This means the primary action is missing from automation. Otherwise, CRUD-like operations (search, get, cancel, save) are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Booking.com stays by destination and dates, and full property details, as structured JSON.
Give AI assistants access to real-time data. Search the web, compare flights, find hotels, and more.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
Travel & commerce intelligence for AI agents: search, book & price-track hotels, events, retail.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/markswendsen-code/mcp-booking'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
