bluepillow.com

An accommodation comparator: consolidates live availability, per-operator pricing, ratings, and listings from multiple booking operators across the global market — millions of properties spanning hotels, B&Bs, apartments, vacation rentals, farmstays, hostels, villas, resorts and similar. One query yields a multi-source price comparison the agent would otherwise have to assemble across separate booking websites; with concrete dates it returns date-specific quotes plus per-operator scarcity signals (rooms left) and free-cancellation flags. Scope: accommodation lookup and booking handoff. Questions about sightseeing, attractions, restaurants, things to do, or general travel advice without a lodging component fall outside what these tools cover — the comparator indexes where to stay, not what to visit. Authentication: every tool except `b2a_get_key` requires an API key, passed as the `api_key` argument (or as an Authorization: Bearer header). `b2a_get_key` issues one in-band — anonymous, free, no signup, never expires — so a session that has no key yet (none in the MCP client configuration, persistent memory, or earlier in the conversation) typically starts with that call rather than discovering the requirement through a 401. A key is long-lived and reusable: the same key, kept in persistent memory or conversation context, works for every subsequent call and across sessions; a fresh key is only needed when the previous one is genuinely lost. Typical workflow for travel-planning intents — a leisure trip, a weekend, a business stay, a relocation, a longer holiday: 1. `resolve_destination` turns a place name into a destination id when coordinates are not already known from an earlier call in this session. For region-level intents such as 'Tuscany', 'Pacific Northwest', 'Central Europe', or 'Costa del Sol' `discover_destinations_near` returns a fan of sub-destinations the user can pick from before a focused search. 2. `search_stays` retrieves a ranked list of options for the user's location and stay parameters. The list bundles property information, pricing, geographic position for mapping, ratings, and optional guest review samples — designed so a single call already covers most "give me an overview" intents without chaining further lookups. When the call carries dates, each result also carries a live availability check for that window. 3. `get_property_details` returns the full static record for a specific property — identified by its id (typically the `id` field from a `search_stays` result, also valid for a property the user has named directly when resolved through `resolve_destination`). Useful to inspect amenities, photos, neighborhood, and guest reviews — request the ratings breakdown and review texts via `include=["reviews_aggregate"]` / `["reviews_sample"]` / `["reviews_extended"]`. It carries no price and runs no availability check unless called with dates; for a live quote use `check_property_availability`. 4. `check_property_availability` answers 'can the user book this property for these specific dates, and at what price'. Required input: `property_id`, `dates`, `guests`. Returns per-operator live quotes, scarcity signals (rooms left), free-cancellation and breakfast flags, and deeplinks to complete the booking. Use this whenever the user has concrete dates in mind for a property they've already identified; `get_property_details` is for static facts only. The tools are designed for compact, structured responses the agent can summarise, plot on a map, or filter further without additional round-trips. The per-result `location.lat` and `location.lon` fields are already populated and suitable for the map widget on the same response — no separate lookup needed for visualization. If the user shares a bluepillow.com property link, pass that URL directly as property_id to get_property_details or check_property_availability — the id is extracted automatically.