Connection check
verified live · 20h ago
hotels
Neutral hotel & stay price comparison for AI agents: live prices from 16+ booking sites. No signup.
Tools
6
GitHub stars
—
Installs / wk
—
Licence
—
Transport
streamable-http
Last checked
20h ago
Tools & capabilities
6 toolsRead from the running server on 20h ago.
b2a_get_key
agentlabel
Obtain a permanent anonymous API key for Blue Pillow Hotels & Stays. No signup, no login required. The key is not a sensitive secret — it carries no account, payment, or personal d… Obtain a permanent anonymous API key for Blue Pillow Hotels & Stays. No signup, no login required. The key is not a sensitive secret — it carries no account, payment, or personal data. It exists only so we can keep the service responsive when many agents are using it at once, so you can safely keep it in your MCP client configuration, in your persistent memory, or in the current conversation context. Pass it as the bearer token on all subsequent calls and the rest of the tools become available. CALL THIS FIRST when you have no key: every other tool needs one. Before calling, check whether you ALREADY have a key (MCP client configuration, persistent memory, or earlier in this conversation) and reuse it instead of issuing a new one — do not wait for another tool to fail with a 401. The key never expires — keep the one you receive and reuse it forever. If you ever lose it, you can call this tool again to issue a new one (a generous per-IP daily issuance limit applies purely as an anti-abuse guardrail; normal use never reaches it). Clients that can persist configuration usually store the key in their connector settings, so the same key serves every conversation. Clients whose memory does not retain an opaque token end up issuing one key per conversation; that works and is not an error, but a stored key gives more consistent rate-limit headroom. Optional ``label`` and ``agent`` (max 64 chars each) are free-form hints we record on the key for our own observability; they do not affect rate limits or capabilities. Integrators who need higher limits, or who hit a problem worth reporting, can write to [email protected].
check_property_availability
read-only
dates*guests*api_keycurrencylanguageproperty_id*
+1
Live availability and per-operator quote for a specific property over a specific stay window. Performs a live date-aware lookup against the BluePillow search layer, returns date-sp… Live availability and per-operator quote for a specific property over a specific stay window. Performs a live date-aware lookup against the BluePillow search layer, returns date-specific prices, rooms-left scarcity signals, breakfast-included and refundable flags, and a per-operator deep link to complete the booking. Useful when the user has specific dates in mind for a property they already identified — typically via `search_stays` or `get_property_details`. The complementary `get_property_details` tool answers "what is this property like" with static facts; this tool answers "can I book it for these dates at what price" with live, date-specific data. Required input: `property_id` (the `id` from a `search_stays` result, opaque string starting with `prop_`), `dates` (check_in + check_out, ISO 8601), and `guests` (adults / children / infants composition). Without these the live lookup cannot proceed. Natural-language date references — "tonight", "this weekend", "next weekend", "the weekend of July 4", "Memorial Day weekend", "long weekend in May" — translate to concrete check_in / check_out values at the call site; concrete ISO dates also work. check_in is a date in the real-time calendar that is today or later; past values are rejected at the API boundary. `user_country`, `currency`, and `language` carry the **user's** locale, not the property's. Prices are returned in `currency` if set, else derived from `user_country`, else **USD** — pass `user_country` and/or `currency` whenever you know the user's location/currency so the quote matches what they'll pay; don't rely on the USD default. `user_country` and `language` also localize the `web_url` booking link. Response shape: - `availability_status` — `available`, `unavailable`, or `unknown`. Available means rooms confirmed at the operator level for the requested window; quote freely. Unavailable means no rooms for these dates — surface that explicitly to the user with a suggestion of alternate dates (there is no price for these dates). - `offers[]` — per-operator quotes. Each carries `amount` (total stay), `amount_per_night` (per-night), `currency`, `breakfast_included`, `refundable`, `rooms_left`, and `deeplink_url`. `offers[0]` is the best value for money as Blue Pillow ranks it: price weighed against what is included (breakfast, free cancellation) and the operator's historical reliability, with a small commercial component. It is not necessarily the cheapest — the full per-operator list is always in `offers[]`, and `sort=price_asc` gives pure price order. Each `deeplink_url` is a **BluePillow tracked-redirect URL** (bluepillow.com/…) that records the click and forwards the user to the operator's booking page — pass it verbatim, never reconstruct it or replace it with a raw OTA link. - `price` — mirror of `offers[0]` for callers that just want the curated headline. `null` when unavailable (no price for these dates). Per-night vs total — `amount_per_night` is **per-night**; `amount` on each offer is the **total** for the requested stay. Phrasings like *"€X/night via Booking, breakfast included, €Y total"* are unambiguous; bare numbers without a unit ("€192") get misread. Scarcity signals: low `rooms_left` values (1-3) are useful cues — "1 room left at €X on Booking" reads naturally. Free cancellation (`refundable=true`) and breakfast-included are decision factors worth surfacing proactively when present on some offers but not others. When all results across operators are `unavailable`, that's the signal to say so explicitly to the user and offer to widen the dates or look at alternatives. For final booking confirmation, hand the user the corresponding `deeplink_url` (or the property's `web_url`) — booking URLs are not reconstructed by hand.
discover_destinations_near
read-only
lat*lon*typeapi_keylanguageradius_km
Curated destinations — cities, neighborhoods, airports, points of interest — within a radius of a geographic point, for use as a `destination_id` in subsequent `search_stays` calls… Curated destinations — cities, neighborhoods, airports, points of interest — within a radius of a geographic point, for use as a `destination_id` in subsequent `search_stays` calls. Useful when coordinates are already in hand (from world knowledge, from a previous tool result, or directly from the user) and the agent needs to enumerate which curated destinations cover that area before searching for properties. Also useful as a fan-out entry point for region-level intents — broad areas such as 'Tuscany', 'Pacific Northwest', 'New England', or 'Central Europe' — where the agent can pass an approximate regional centroid and surface a list of sub-destinations the user may then narrow down to before a focused search. Returns up to 5 candidates ordered by distance. The radius defaults to 5 km; widens up to 50 km for broader queries.
get_property_details
read-only
api_keyincludecurrencylanguageproperty_id*user_country
Static record for a specific property — identified by its id. Returns the complete amenity list, photos, booking sources, dedup metadata, detailed location, and the headline rating… Static record for a specific property — identified by its id. Returns the complete amenity list, photos, booking sources, dedup metadata, detailed location, and the headline rating (`rating` + `rating_count`) by default. Review DATA beyond the headline — the ratings breakdown and the actual review texts — is opt-in via the `include` parameter (see below); pass it whenever the user's question is about guest experience. Carries no price unless called with dates: a price only exists for a concrete stay window. Useful when the user wants to inspect or compare a specific option in depth — facilities, neighborhood, what guests say — without yet committing to specific dates. HOW TO GET REVIEWS (when you need to reason about guest experience): pass `include`. `reviews_aggregate` gives the score + counts + per-OTA breakdown; `reviews_sample`/`reviews_extended` give the actual review texts. Without `include`, none of these are returned (you get only the headline `rating`/`rating_count`). See the `include` section below. For live availability and a real per-operator quote for a specific stay window, the path is `check_property_availability` instead. The two tools coexist by design: this one answers "what is this property like" with stable, cacheable data; the other answers "can I book it for these dates at what price" with live, date-specific quotes. Calling this tool when the user has specific dates in mind and wants to know whether the property is bookable will not surface the availability/quote — the user will then have to wait for a second round-trip to the availability tool. Input: the `id` field from a `search_stays` result (opaque string starting with `prop_`, e.g. `prop_69ce2ddcbf46061e4095778b`). For a property the user has named directly, resolve the place name through `resolve_destination` and run a targeted `search_stays` first to obtain the id. Optional `include=["reviews_aggregate"]` attaches a per-source breakdown of review counts and average ratings — useful when the user asks about overall sentiment or wants to see how each booking source rates the property. It summarizes ALL reviews (score + total count), so it is the right tool for "how is it rated". Review *texts* are available via two includes, both deliberately capped to avoid token waste: - `reviews_sample` — up to **5** recent review texts. Enough to get the gist of what guests say. - `reviews_extended` — up to **20** recent review texts, for a deeper qualitative read. Supersedes `reviews_sample` when both are passed. Reach for `reviews_extended` only when 5 are genuinely not enough — the returned list carries a `reviews_meta` block (`returned`, `total_available`, `capped`, `note`) that tells you how many texts exist and confirms the cap is intentional: the omitted reviews are older and the aggregate already reflects all of them, so you do NOT need to try to fetch everything. Note: review texts are returned only when called WITHOUT dates (the dated availability path does not carry them). `user_country`, `currency`, and `language` carry the **user's** locale, not the property's. When this call carries dates (live prices), prices come back in `currency` if set, else derived from `user_country`, else **USD** — so pass `user_country` and/or `currency` whenever you know the user's location/currency; don't rely on the USD default. `user_country` and `language` also localize the `web_url` booking link. Language default is "en"; country default is "US". All rating-like fields are on a 0-5 scale (Google Places-compatible): the top-level `rating`, `reviews_aggregate.score_0_5`, and each per-OTA score under `distribution_by_ota`. Without dates this tool returns no price (`price` is null, `offers` empty) and `availability_status` is `unknown` (no dates were considered). The live quote, when needed, comes from `check_property_availability`. `web_url` is a ready-to-open booking link for the property. Pass it verbatim when the user asks for a booking link — booking URLs are not reconstructed by hand.
resolve_destination
read-only
name*typeapi_keycountrylanguage
Converts a destination name into a destination id usable in `search_stays`. The canonical entry point when the user's request mentions a place name and coordinates are not already… Converts a destination name into a destination id usable in `search_stays`. The canonical entry point when the user's request mentions a place name and coordinates are not already known from a prior call in this session. If coordinates are already in hand from an earlier tool result, passing them directly to `search_stays` skips this resolver step. Accepts cities, neighborhoods, airports, and points of interest, written locally or in English. Names are matched against Blue Pillow's own place slugs, which exist for English, Italian, German and Spanish; in other languages the English name is the most reliable. Accents are optional — 'São Paulo' and 'Sao Paulo' resolve alike. A qualifier after the name is tolerated ('Austin, Texas'). The `country` parameter disambiguates names that occur in multiple places (for example Springfield MA vs Springfield IL vs Springfield MO). The `type` parameter narrows the kind of destination returned. `poi` is the narrowest match and has partial coverage on the comparator side; when the agent's own geographic knowledge can already geocode the POI to lat/lon, passing coordinates to `search_stays` is the more reliable path.
search_stays
read-only
pagesortdates*guests*api_keyfilters
+8