Skip to main content
Glama

Check the hotel's own price against Booking.com

check_direct_price
Read-only

Checks whether a hotel is cheaper on its own website than on Booking.com, for one stay. Give the hotel, the dates, the guests and, when you have it, the total Booking.com shows for the whole stay with its meal plan and cancellation terms. BookHotels.direct reads the hotel's own booking site live, applying the public promo codes and free-club prices it knows for that hotel, or uses a traveller's read of the same stay from the last 24 hours, and compares like for like: same hotel, dates and guests, with every difference in room, meal plan or cancellation stated. The answer is honest either way: when Booking.com is cheaper, it says so. When the hotel's site cannot be read automatically, the answer gives the link to the hotel's own site for these dates and asks you to report the prices shown there with report_hotel_price. Without a Booking.com total, the answer gives the hotel's own price and, when the evidence allows, an estimated saving, always labelled as an estimate with its basis. Only Booking.com prices can be compared. One room per check.

Input Schema

NameRequiredDescriptionDefault
cityNoThe town or city the hotel is in, e.g. "Sitges". Helps find hotels we have not checked before.
hotelYesThe hotel's name as the traveller sees it, e.g. "Hotel Calipolis".
adultsNoNumber of adults (default 2).
checkinYesCheck-in date, YYYY-MM-DD.
checkoutYesCheck-out date, YYYY-MM-DD.
languageNoLanguage of the check page for the traveller (default en).
booking_urlNoOptional: the Booking.com address of the hotel's page (https://www.booking.com/hotel/…). Only the address is read, to recognise the hotel and the dates; the page is never opened.
booking_roomNoThe room name of the Booking.com offer, when shown.
booking_totalNoThe total Booking.com shows for the whole stay, in euros, when known. Without it you get the hotel's own price and, when the evidence allows, an estimated saving.
children_agesNoEach child's age on the day of check-out, one number per child. Leave out when no children travel. Hotels price children by age, so ages are needed for families.
booking_meal_planNoThe meal plan of the Booking.com offer, when Booking.com shows it.
booking_taxes_extraNoTaxes Booking.com lists on top of its total, in euros (e.g. a city tax), when shown.
booking_cancellationNoThe cancellation terms of the Booking.com offer, when Booking.com shows them: free cancellation, non-refundable, or partly refundable.
booking_taxes_includedNotrue when Booking.com says its total includes taxes and charges; false when it lists taxes on top.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond readOnlyHint/openWorldHint/openWorld it discloses how the answer is produced: a live read of the hotel's own booking site, promo-code and free-club pricing, or a traveller's read from the last 24 hours, and comparison 'like for like' with every room/meal/cancellation difference stated. It also flags the non-deterministic character implied by idempotentHint=false and is honest about failure modes and estimate labelling.

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?

Purpose and inputs come first, then behaviour, then the fallback path — a good front-loaded order with no filler sentences. It is dense but the booking_total behaviour is stated twice (prose and schema), costing a little tightness.

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?

For a 14-parameter, no-output-schema tool this covers what an agent needs: required inputs, which optionals improve fidelity, what the answer contains (comparison verdict, link fallback, labelled estimate with basis), and the comparison's limits. Nothing material for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds conditional priority ('when you have it', the meal plan and cancellation terms) and explains the consequence of omitting booking_total. It does not walk through the taxes or children_ages semantics, which remain schema-only.

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?

States a precise verb and comparison ('Checks whether a hotel is cheaper on its own website than on Booking.com, for one stay'), naming both data sources and the unit of work. An agent knows exactly what question this tool answers, and the sibling names (report_booking, report_hotel_price) are routed away from it explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives positive conditions (supply hotel, dates, guests and, 'when you have it', the Booking.com total), branches (without a total you get the hotel's own price plus a labelled estimate), a fallback path ('asks you to report the prices shown there with report_hotel_price'), and hard exclusions ('Only Booking.com prices can be compared. One room per check.').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources