Bluerails Hotels
Server Details
Live hotel search and booking for AI agents in DACH, the UK and 10 US cities.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- –
TDQS
Scored across 2 tools
The two tools occupy entirely separate phases of the workflow: `list_hotels` searches and prices properties, `hotel_reserve` books a specific `offerId` returned by the search. Cross-references in both descriptions reinforce the boundary, so an agent cannot plausibly pick the wrong one.
Both names are snake_case and readable, but they follow different orderings: `list_hotels` is verb_noun while `hotel_reserve` is noun_verb. With only two tools the deviation is minor, though `reserve_hotel` would have made the set fully predictable.
Search-plus-book is the essential pair, but a hotel booking server with only two tools feels thin — there is no lookup, cancel, or modify operation an agent could reach for after a booking. The count is defensible for a minimal surface but borderline for the stated domain.
Discovery and reservation are covered end-to-end, including pricing, budget filtering, and the payment-link vs confirmation fork. However, the lifecycle has dead ends: no tool to retrieve a reservation by confirmation number, cancel it, or modify dates, so a guest who books cannot be helped further.
Available Tools
2 toolshotel_reserveADestructiveInspect
Book a hotel room. Works for ANY offer list_hotels gave you an offerId for — there is no separate check to make first, so pass the offer the guest chose. Pass that offer’s offerId exactly as you were given it — it names the hotel, room, rate, stay and price, which is why none of those are separate arguments. It expires after 30 minutes; if it has expired or the hotel has raised the price since, nothing is booked — get a fresh one by calling list_hotels with that same offerId, which re-prices just that room rather than showing the guest the whole property again. TWO OUTCOMES, and the reply tells you which. confirmationNumber means the room is booked: give the guest the number and tell them they pay the hotel at the desk — nothing has been charged. paymentUrl means the room is NOT held yet: give the guest that link to pay, their card is HELD rather than charged, and the booking is placed once they have paid. Set acceptedTerms only after the guest has agreed to book this rate. Show them that rate’s cancellation terms where list_hotels gave any; where its cancelTerms was null we hold none, so say so and that the hotel’s own terms apply, then set it once they agree on that basis — a blank is NOT a reason to refuse the booking. Ask the guest for their own phone number and billing address — the hotel puts them on the reservation and uses them to reach the guest. Never invent them. If a call comes back ambiguous, do NOT call again — a reservation may already exist.
| Name | Required | Description | Default |
|---|---|---|---|
| offerId | Yes | The `offerId` of the exact room and rate the guest chose, copied from `list_hotels` unchanged. It names the hotel, the room, the rate, the stay, the party and the price the guest was shown, so none of those are passed separately. It is valid for 30 minutes — if the guest takes longer to decide, call `list_hotels` with this same `offerId` to get a fresh one: it re-prices that one room and nothing else, so the guest is not shown the whole property a second time. Never edit it or build one yourself. | |
| guestCity | Yes | ||
| guestEmail | Yes | The hotel sends its confirmation here. It is the guest's own address, never yours. An example or placeholder address such as name@example.com is refused and nothing is reserved: ask the guest for the address they actually use. | |
| guestPhone | Yes | The guest's phone number, in any format the guest gives it. | |
| guestPostal | Yes | Postal code. | |
| guestStreet | Yes | Street and house number. | |
| guestCountry | Yes | Two-letter country code, e.g. DE, AT, CH. The country the guest lives in, not the one they are travelling to. | |
| acceptedTerms | Yes | TRUE only when the guest has agreed to book this rate. Where `list_hotels` gave that rate cancellation terms, show them first and get the agreement to those. Where its `cancelTerms` was null WE HOLD NONE — tell the guest plainly that we do not have this rate’s cancellation terms and that the hotel’s own terms apply and reach them with the hotel’s confirmation, then set this once they have said to go ahead knowing that. Never assume it on their behalf, and never treat a blank as a reason not to book. | |
| guestLastName | Yes | ||
| guestStreetNo | No | House number, when the guest gives it separately from the street. | |
| guestGivenName | Yes | ||
| guestSalutation | No | How the guest is addressed, in their own words. Only pass what the guest told you; never guess from a name. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present ONLY when nothing was booked. It carries the reason in words a guest can hear and, on a refusal you can recover from, the call to make next. Give the guest the reason; act on the rest yourself. |
| hotel | No | The property that took the booking. |
| reason | No | Machine-readable cause of a refusal: terms-not-accepted, guest-email-placeholder, offer-malformed, offer-bad-signature, offer-expired, offer-not-enabled, offer-not-bookable, listing-not-found, not-configured, not-recorded, room-not-offered, rate-not-offered, availability-unreadable, price-unreadable, price-moved-up, guest-details-incomplete, no-booking-identity, dry-run, ambiguous, not-confirmed, unexpected-error. |
| checkIn | No | |
| payment | No | What the guest owes and to whom. Nothing is ever charged here. |
| checkOut | No | |
| paymentUrl | No | OUR payment page, and the room is NOT reserved until the guest has paid. Their card is HELD, not charged. Present only when nothing was booked yet and payment is what gets it booked. |
| tellTheGuest | No | Wording meant for the guest rather than for you. On an ambiguous outcome it says NOT to book again — pass that on rather than retrying. |
| bookingReference | No | OUR reference for this booking — the number the guest quotes to US. Different from `confirmationNumber`, which is the hotel’s and is what they quote at the property. Absent only when the booking could not be recorded. |
| confirmationNumber | No | Present ONLY when a room was actually booked. The hotel’s own reference — give it to the guest and tell them to keep it. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Well beyond the annotations (readOnly=false, destructive=true, openWorld=true), it discloses the 30-minute offer expiry, that an expired or re-priced offer means nothing is booked, the two mutually exclusive success shapes (`confirmationNumber` vs `paymentUrl`), that payment is held at the desk or via link rather than charged now, and the ambiguity/idempotency hazard. These are exactly the side-effect details a mutation tool needs.
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?
Front-loaded with purpose and the offerId handoff, then the two outcomes, then the terms/guest-details rules. It is long and repeats some offerId expiry and acceptedTerms guidance already present in the schema property descriptions, but no sentence is filler and the ordering follows the call flow.
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 12-parameter, 10-required booking mutation with an output schema, the description covers everything an agent needs to execute and narrate correctly: offer lifecycle, outcome interpretation, payment timing, consent gating, and the double-booking guard. Return values need little explanation since an output schema exists, yet the two response shapes are still made actionable.
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 75%, and the description supplies the business meaning the schema can't: why hotel/room/rate/stay/price are absent (all encoded in `offerId`), why a stripped offerId must never be edited or rebuilt, and how `acceptedTerms` must be set relative to the rate's `cancelTerms`, including the explicit rule that a null `cancelTerms` is not a reason to refuse. It also states guestPhone and billing fields must come from the guest and never be invented.
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?
Opens with a specific verb+resource ("Book a hotel room") and immediately scopes it to offers produced by the sibling `list_hotels`, so the agent can tell the two apart without opening either schema. It also names the exact identifier (offerId) that ties this tool to the sibling's output.
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 there is no separate check to make first, tells the agent to pass the chosen offer's `offerId` unchanged, and routes back to `list_hotels` with that same `offerId` when the offer expired rather than re-listing the property. It also gives an explicit when-NOT-to-call rule: on an ambiguous response, do not call again because a reservation may already exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_hotelsAInspect
Search hotel properties in Germany, Austria, Switzerland, the United Kingdom and the United States, and price them for a stay in the same call.
ASK BEFORE YOU SEARCH. Four things are required and this tool answers nothing without them: checkIn, checkOut, adults and maxPricePerNight. "Hotels in Berlin for a couple" is not yet a search — it names a place and a party and nothing else, so ask which nights they want, who is coming — adults AND any children, by age — and roughly what they want to spend, in ONE message, and search once they answer. Never fill these in for them: dates you chose are not their dates, and a budget read off "cheap" or off a star rating hides the very hotels they could have afforded. A call missing any of them comes back with no rows and a hint naming what is still to be asked.
PLACES. Pass city with any place name we cover to get properties around it, nearest first, each with distanceKm — despite the name it takes a place of any size, so a village, a resort or a borough ("Silvaplana", "Wals", "Zell am See", "Brooklyn") works as well as a city. radius is a value with its unit — {"value": 10, "unit": "mi"} — so you never have to convert; it defaults to 20 km and may not exceed 100 km. Prefer city over query for place-based searches: it understands about 151,800 places and returns neighbouring towns, whereas query only matches words in a name or description. An unresolvable place name returns placeNotRecognised — that means the NAME was not understood, not that the place has no hotels. When a radius returns nothing you get nearestBeyondRadiusKm so you can widen deliberately rather than guess.
SOMEWHERE SMALLER THAN A TOWN — A STREET, A LANDMARK, A STATION, A DISTRICT — GOES IN coordinates, NOT city. Sent as a city, such a name is either refused or resolved to a different place of the same name, which comes back as a confident answer about somewhere else. Estimate the point yourself, pair it with a small radius, and tell the guest you estimated it.
A STAY. checkIn, checkOut and adults are required, and when you ask how many adults, ASK WHETHER ANY CHILDREN ARE COMING TOO and send their ages in childrenAges — ages, not a count. A child left out is priced as though they are not coming, so the guest can book a room that will not sleep them. The moment the guest mentions a child, put it in childrenAges even if you do not yet know the age — send null for that entry: THE SEARCH IS THEN REFUSED until you replace it with the real age, which is what stops a family being quoted as a couple. With those, the answer comes back in TWO groups. priced holds the hotels we read real rates for: every room and rate plan with its own price for the WHOLE stay, in the currency you sent, its cancelTerms where we hold any and null where we do not, its photos where we have them, a bookingUrl carrying the guest's dates WHERE THIS ENDPOINT PUBLISHES ONE — read that field's own description rather than assuming it is there, because an endpoint that can book the room for you publishes no link for it — and stayTotal / pricePerNight for the cheapest offer. EVERY PRICE IS IN THE currency YOU SENT. They come back in a deliberate order that is NOT nearest first and NOT cheapest first — show them in the order you are given. Show all the rooms you are handed, not just the cheapest. unpriced holds everything else: hotels that do not publish rates anywhere we can read, that did not answer us, or that were past the read ceiling. Those are the same thing to you — NONE of them carries a booking link of any kind. What a row carries instead is websiteUrl, the property's own site, or an EMPTY websiteUrl when we hold no site either and there is nothing to open at all. WHEN YOU RECOMMEND A HOTEL, RECOMMEND A PRICED ONE. We hold no rate for anything in unpriced, so you cannot say what it costs and it may be well over what the guest wants to spend; naming one as your suggestion answers their budget with a number nobody has. Bring one up only as "I could not get a rate for X, here is their website". Offer that site as the property's website and NEVER as a way to book or check rates, since we do not know it sells rooms online — and where it is empty, say we have nowhere to send them rather than going looking for a page of your own.
AN EMPTY priced IS NOT "SOLD OUT", AND CHECK aboveBudget BEFORE CALLING IT UNREADABLE. With a maxPricePerNight, an empty priced means every hotel we priced costs more than that, and those hotels are in aboveBudget with real prices — quote them. Only when aboveBudget is empty too does an empty priced mean no rates could be read, and even then we get the same empty answer for a connection that failed, a party the property will not sell to, and a genuinely full hotel, and it never says which — so report the price as unknown and hand over the links, NEVER that a property is full. No ROW in this response can tell you a hotel has no space. One thing can: the hint, which says how many properties were left out because they told us outright that they are full — that is why they are in no group at all, and it is the only "full" this tool ever reports. It is never about a hotel you can see.
A BUDGET IS A FILTER, NOT A LABEL — AND IT IS THE GUEST'S NUMBER, NEVER YOURS. maxPricePerNight is required, so ask them for a figure before searching rather than sending one of your own. Words like "budget", "cheap" or "affordable" are not amounts: read as one they filter out the very hotels the guest wanted, and the answer then tells them their limit was missed when they set no limit. A guest who says they have no limit still has a most-they-would-pay — ask for that and send it. maxPricePerNight decides what you are handed, at both levels. priced holds ONLY the hotels at or under it, each carrying ONLY its rooms at or under it — so every price you read out is one the guest already agreed to, and priced may be shorter than the limit you asked for. Dearer hotels are NOT in priced, NOT in unpriced, and not returned at all while any hotel fits: do not tell the guest this is every hotel in the area, and read the hint, which says how many were left out. Only when NOT ONE hotel fits do they come back, in aboveBudget — then say what the nearest options actually cost, never "nothing is available". A room in priced keeps ALL of its rate plans, including one dearer than the budget, so a breakfast or flexible rate is still there to offer as an upgrade. The comparison is pricePerNight, the stay total divided by nights — a stay AVERAGE, not a rate charged on every night, so say it that way.
HOW MUCH ONE SEARCH RETURNS. limit is the ceiling across BOTH groups, priced first — an answer can be shorter when properties were dropped as full, defaulting to 10 and capped at 20. unpriced carries AT MOST 5 however large a limit you ask for, so raising limit buys you more PRICED hotels and never a longer list of names we hold no price for. THERE IS NO PAGING: one search returns one set of rows and there is no second page to ask for, so to reach anything past 20 properties, narrow the search — a nearer city, a smaller radius, a query, country or starRating. Calling again with the same filters returns the same rows. No count of the whole match comes back either, so do not tell the guest how many properties exist in a place — say what you can show them.
Also supports country (de, at, ch, us, gb), starRating (1-star, 2-star, 3-star, 4-star, 5-star) and style (boutique), which are independent of one another. Some place names exist in more than one of those countries, and city alone resolves them to THE MOST POPULOUS of them — "Cambridge" is England, not Massachusetts; "Bellevue" and "Salem" stay European. It is a proxy for the place a guest means, and it is sometimes wrong: "Kendal" resolves to the Kendall in Miami, not the Cumbrian town. Pass country alongside whenever you know which you mean, and ALWAYS when the guest named the country — it overrides the contest outright. Returns public fields only.
BOOKING A ROOM FROM THIS ANSWER. Every priced room carries an offerId and NO booking link, because we can book it for the guest ourselves — call hotel_reserve with the offerId rather than sending them to a website. It needs the guest's full name, email, phone and address, so ask for those once they have chosen a room. It answers one of two ways: a confirmationNumber means the room is booked and the guest pays the hotel at the desk, and a paymentUrl means the room is not held yet and that link is where the guest pays to get it booked. Where a room's cancelTerms is null we hold no cancellation terms for it: say so plainly, say the hotel's own terms apply and come with its confirmation, and book once the guest agrees on that basis — a blank is not a refusal.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Place to search around — any place name we cover, not just a city: a town, a village or a resort works, e.g. "Salzburg", "Munich", "Silvaplana", "Wals". Pass the place name ALONE, not a phrase: "Salzburg", never "10 miles from Salzburg" — say the distance in `radius` instead. Accents are folded away before lookup, so "München" is looked up as "munchen" and can collide with a smaller place of that same folded name — where a city has a common English name, prefer it: "Munich", not "München". Anything smaller than a town — a street, a landmark, a station, a district — belongs in `coordinates`, not here. Returns properties nearest first. | |
| limit | No | How many results to return. Defaults to 10, and may not exceed 20; a larger value is rejected, never quietly reduced. | |
| query | No | Free-text match over a property’s NAME, short description and tags. It is NOT a natural-language request: EVERY word you pass must appear on the same property, so each extra word narrows the result and a whole sentence almost always matches nothing. Pass "spa munich", never "find me a nice spa hotel in Munich". Words match close to as written — the index is stemmed for English, so a German compound or inflection needs the form that actually appears on the listing. A place belongs in `city`, dates in `checkIn`/`checkOut`, a budget in `maxPricePerNight`; none of those are searched here, and a date or a price in `query` only empties the result. When a search that set `query` comes back empty, the reply carries a `hint` saying whether the text or the other filters emptied it. | |
| style | No | Filter by how the property presents itself: boutique. Independent of starRating — combine them to ask for both. | |
| adults | No | Adults in the party. REQUIRED — ask how many people are travelling. Properties price by party size, so a number you assumed prices a stay nobody asked for. "A couple" is two; anything vaguer is a question. | |
| radius | No | How far around `city` — or around `coordinates`, when you sent a point — to search, as a value and its unit: {"value": 10, "unit": "mi"}. Defaults to 20 km. May not exceed 100 km once converted; larger values are rejected, never quietly reduced. | |
| checkIn | No | Arrival date, YYYY-MM-DD. REQUIRED — ask the guest for their dates before you search. Without them nothing can be priced and the answer would be a list of property names with no rooms, no prices and no results card. NEVER choose dates yourself, and do not read them out of a vague phrase: "next month" is not a date, it is a question to ask. | |
| country | No | Filter by country: de=Germany, at=Austria, ch=Switzerland, us=United States, gb=United Kingdom | |
| offerId | No | An `offerId` from an earlier answer, to get a fresh price for THAT room rather than searching again. Pass it when the guest has already chosen and you need a current handle — after `hotel_reserve` said the offer expired, or before asking them to confirm. The answer comes back as that one property carrying that one room with its rate plans, each with a new `offerId`, so you never have to work out which of several rooms was theirs. An offer older than 30 minutes still works here — this call is what refreshes it. EVERY OTHER SEARCH FIELD IS IGNORED when you pass this: `city`, `coordinates`, `radius`, `query`, `country`, `starRating`, `style`, `limit` and `maxPricePerNight` describe a search, and this is not one. `language` still applies. The stay comes from the handle, so leave the dates out to re-price the same nights; pass `checkIn`, `checkOut` and `adults` together to ask for the same room on different nights. THIS IS THE ONE CALL THAT NEEDS NO DATES AND NO BUDGET: a plain search is refused without them, but a handle already carries the stay it was quoted for, and a budget here could filter out the very room the guest chose. | |
| checkOut | No | Departure date, YYYY-MM-DD. REQUIRED, on the same terms as `checkIn` — ask the guest, never choose. | |
| currency | No | THE CURRENCY OF `maxPricePerNight`, AND THE ONE THE ANSWER IS QUOTED BACK IN. ISO 4217 — `EUR`, `CHF`, `GBP`. REQUIRED on every search: send `EUR` when the guest gave you a euro figure, which is most of the time. USE THE ONE THEY ALREADY NAMED and do not re-ask — "200 euros" is `EUR`, "CHF 165" is `CHF`. Ask them only when they gave a bare number and you genuinely cannot tell which currency they meant; guessing it is the thing this field exists to stop. IT ALSO CHOOSES THE CURRENCY THE ANSWER COMES BACK IN: every `price`, `stayTotal` and `pricePerNight` is in what you send here. It exists because a budget with no currency was read as euro, so a guest who said "CHF 165" was filtered at €165 and the hotels they could actually afford were not marked dear, they were absent. PASS THE GUEST’S OWN NUMBER and name its currency here; never convert it yourself. Quote them their own figure back; the prices you are handed are already in it. A currency we cannot get a rate for is REFUSED rather than assumed to be euro. | |
| language | No | The language to render the results card in — pass the language the guest is WRITING in, unless they have asked for another. A bare language code or a full BCP 47 tag both work ("de", "de-AT", "en-GB"); only the language part is read, so a region suffix is harmless and case does not matter. German and English are rendered; any other value falls back to English rather than failing the search. Omit it and the card follows the guest’s own app language, then English. It changes ONLY the labels WE write on the card — never a room name or a rate plan, which stay in the property’s own words. A cancellation term carries the property’s own figures, but the sentence around them is written in English whatever language the card is in. | |
| amenities | No | Facilities and house rules the property must ALL have — a hotel missing one is excluded, so every extra value narrows the result. Prefer this to naming an amenity in `query`: these are exact, while `query` matches only the words we happen to store. Naming one in `query` in either language ("swimming pool", "Schwimmbad") also works and resolves to these same values. | |
| starRating | No | Filter by star rating: 1-star, 2-star, 3-star, 4-star, 5-star. A property can hold stars AND be a boutique hotel; ask for the two separately. | |
| coordinates | No | A point to search around, for anywhere smaller than a town: a street, a landmark, a station, a junction, a named district. ESTIMATE IT YOURSELF for the place the guest named — `city` takes town names only, and a smaller name sent there is either refused or resolved to a different place of the same name, which comes back as a confident answer about somewhere else. Same shape as the `coordinates` on a hotel in the answer, so you can search around one you were just given. TAKES PRECEDENCE over `city` when both are sent: the point decides what is searched and which row leads, and `city` only names the place in the answer. Use `radius` to say how far around the point to look, and keep it small for a street or a venue. Tell the guest you estimated the point, so they can correct you. | |
| childrenAges | No | ONE ENTRY PER CHILD — their age, or `null` when you do not know it yet. Not a count: properties price a child by its age, and none may be invented. ASK WHETHER ANYONE UNDER 18 IS TRAVELLING, in the same message as `adults`. The moment the guest mentions a child, put it here: send `[null]` if you have not asked the age yet and the search is REFUSED until you replace it with the real age, which is what stops a family being quoted as a couple. A child you leave out altogether is priced as though they are not coming — the quote is for the adults alone, and the room the guest books may not sleep them, which they find out at the desk. Leave the field out when there are no children — an EMPTY ARRAY says the same thing and is read as none. An age of 0 is a real age — an infant is a child, not nobody. | |
| maxPricePerNight | No | Budget per night, in the `currency` you send alongside it — BOTH ARE REQUIRED. TAKEN FROM A FIGURE THE GUEST GAVE YOU AND NOWHERE ELSE. Ask them roughly what they want to spend a night before you search: "a budget hotel", "somewhere cheap", "nothing too pricey" and a star rating are not amounts, and a figure you inferred hides every hotel they could have afforded behind a limit they never set. If they say they have no limit, ask for the most they would still pay and send that. PASS THE NUMBER THEY SAID AND NAME ITS CURRENCY — do not convert it yourself, and do not pass a euro figure you worked out from one they gave in francs or pounds. It FILTERS rather than labels. `priced` comes back holding ONLY the hotels at or under it, each carrying ONLY its rooms at or under it — so it can be shorter than `limit`, and it is not every hotel in the area. A kept room keeps all of its rate plans, including one dearer than the budget, so a breakfast rate is still there to offer. Dearer HOTELS are returned only when not one fits, in `aboveBudget`. Read the `hint`, which says how many were left out. Compares the stay average, not a nightly rate. |
Output Schema
| Name | Required | Description |
|---|---|---|
| hint | No | One or more sentences about THIS answer that the rows cannot tell you: why a search came back empty, what a budget left out, how many properties were dropped because they told us they are full, and — when the call was refused for missing dates, party size or budget — exactly what to ask the guest before searching again. Read the whole string; several of these can arrive together. Where it describes hotels it describes the ones this call priced, never the whole area. |
| stay | No | The stay this answer priced, echoed back. Present only on a dated call — a view needs it to label the result and to turn a stay total into a per-night figure. |
| error | No | |
| place | No | The `city` that was resolved, echoed back. |
| priced | No | Only on a dated call. AT MOST your `limit` of them — 10 by default and never more than 20 — hotels we could get a real price for. Deliberately ordered — SHOW THEM IN THE ORDER YOU ARE GIVEN, and lead with the top row. The order is neither distance nor price, so do not call any row the nearest or the cheapest. Under a `maxPricePerNight` this holds ONLY the hotels at or under it, so it can be shorter than `limit` and an empty one does NOT mean the rates were unreadable — check `aboveBudget` before saying anything about price. A hotel here is NOT in `unpriced`; one that did not answer us is NOT here, it stays in `unpriced`, where it carries the property's own website and no booking link. |
| currency | No | The ISO code every price in this answer is in. |
| language | No | The `language` that was asked for, echoed back verbatim. Absent when the caller passed none, which is how the card knows to follow the guest’s own app language instead. |
| unpriced | Yes | Matching properties we have NO price for. SHOW THEM IN THE ORDER YOU ARE GIVEN, and do not call any row the nearest. On a dated call that means: the property does not publish rates anywhere we can read, or it does and did not answer, or it was past the read ceiling — all the same to you. There is NO booking link on a row here. What a row carries instead is `websiteUrl`, the property’s own site, and the guest checks there: offer it as their website and never as a way to book or check rates, since we do not know it sells rooms online. An EMPTY `websiteUrl` means we hold no site either, so that row has nothing to open — say so plainly, do not invent a link, and do not go looking for one. None of that means full: a property here may well have rooms. A property that TOLD US it is full for this stay is the one thing not here — it is dropped from the whole answer rather than given a link that opens on nothing, and `hint` says how many were dropped. On a dateless call it is simply every match, because nothing was priced. NEVER RECOMMEND ONE: we hold no rate for these, so a hotel here may cost anything, including more than the guest’s budget — recommend from `priced`, and bring one of these up only as "I could not get a rate for X, here is their website". AT MOST 5 of them come back however large a `limit` you ask for, for the same reason — a property with no price is something to mention, not an option to offer — so a short list here does NOT mean the area is small, and every property we could price is still returned. AN ANSWER CARRYING ENOUGH REAL PRICES RETURNS NONE OF THEM AT ALL, so an empty list here is NOT a statement about the area and NOT a claim that every property in it was priced — it means this answer did not need them. Read it as nothing, never as a finding, and never tell the guest a search came back short because of it. No count of the whole match is returned. |
| aboveBudget | No | Hotels we read real prices for that are OVER your `maxPricePerNight`, in the same shape as `priced`. Returned only when NOT ONE hotel fits the budget — when any does, dearer ones are left out entirely. So this is never a second page of results to offer alongside `priced`: it is the answer to "then what does the nearest thing cost", and the honest sentence is "none of the ones I could price are under X, the cheapest is Y". Ordered like `priced`, so read the prices rather than taking the first row as the cheapest. Each carries all of its rooms, since here the prices are the point. |
| maxRadiusKm | No | |
| radiusUsedKm | No | The radius actually searched, in km, after converting the caller’s unit. |
| maxPricePerNight | No | The budget `aboveBudget` was measured against — the GUEST’S OWN figure, in the `currency` you sent, like every price beside it. Echoed back so the results card can name it. Present only alongside `aboveBudget`. Say the figure when you quote those prices — if the guest never gave you one, that is your own number in front of them. |
| requestedRadiusKm | No | |
| placeNotRecognised | No | The place name could not be resolved. NOT a statement that the place has no hotels. |
| nearestSearchedToKm | No | How far the nearestBeyondRadiusKm search itself looked before giving up. |
| nearestBeyondRadiusKm | No | Only when the search found nothing: how far the nearest property lies outside the radius. It is measured with your `query` still applied, so when you set one a null here does NOT mean the area is empty — read the `hint` before saying anything about the place. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes far beyond the annotations: no paging, limit ceiling of 20 across both groups, unpriced capped at 5, empty priced not meaning sold out, aboveBudget semantics, hint being the only 'full' signal, 30-minute offer refresh window, and refusal on an unratable currency. These are failure-mode and result-shape disclosures an agent could not infer from readOnlyHint/openWorldHint alone.
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?
Section headers (ASK BEFORE YOU SEARCH, PLACES, A STAY, BOOKING A ROOM) front-load the critical rules well, but the prose is very long for a tool description and repeats the same injunctions about never guessing dates, budgets and children's ages in the body text, in the lead, and again in the schema descriptions.
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 17-parameter open-world search with nested objects and two output groups, the description covers the missing pieces an agent needs: what rows mean in each group, what an empty result implies, and how to hand off to hotel_reserve. Output schema exists, so return fields are appropriately referenced rather than re-explained.
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 the baseline is 3; the description still adds interpretation the schema does not, notably that maxPricePerNight filters at both hotel and room level, that comparison uses the stay average pricePerNight rather than a nightly charge, and that passing offerId ignores every other search field. Some of this duplicates the schema text closely.
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?
Opens with a specific verb+resource+scope: search hotel properties in five named countries and price them for a stay in the same call. It is clearly distinguished from the only sibling, hotel_reserve, which the description says is the booking step called with an offerId.
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?
States explicit preconditions (checkIn, checkOut, adults, maxPricePerNight) and an explicit ask-first protocol, then routes among alternatives: city vs coordinates vs query, country to disambiguate place names, offerId refresh instead of a new search. Exclusions are spelled out (query is not natural language, street names must not go in city).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- First observed
hotel_reserve - First observed
list_hotels
Related MCP Connectors
AI hotel search and booking: millions of properties, 85,000+ cities, live rates.
Travel & commerce intelligence for AI agents: search, book & price-track hotels, events, retail.
Book hotels direct through your AI, for a 5% fee. Demo: sample hotels, no real bookings yet.
Search, quote and book hotels and resorts from any AI agent. Checkout on tellandgo.com. No API key.
Related MCP Servers
AlicenseNot gradedqualityDmaintenanceEnables AI agents to search and book hotels globally with real-time pricing and inventory from over 2 million properties.46MIT
RollingGo Hotel MCPofficial
AlicenseNot gradedqualityBmaintenanceEnables AI agents to search, compare, and book hotels worldwide through natural language, with real-time pricing and availability, plus price monitoring and order management.55MIT- FlicenseAqualityCmaintenanceHotel booking MCP server — the first transaction-complete hotel booking integration for AI agents. Search 300K+ properties in 140+ countries, get live rates and room details, and generate secure checkout URLs. No payment in the AI conversation — guests complete booking at a hosted checkout page and receive a real hotel confirmation number. Set your own booking fee via Stripe Connect.86 npm3-
- FlicenseNot gradedqualityBmaintenanceEnables AI assistants to search live hotel availability and rates, compare preferred-partner perks with public rates, create a secure one-time payment page, and manage hotel bookings through a licensed travel agency.2-
Glama MCP Gateway
Add one secure layer between your agents and this server.