HemmaBo Host Booking Engine

Fetch, verify, and render a live host-domain signed VRP stay offer for exact dates and guest count. Verifies Ed25519 JWS against domain JWKS. Call after hemmabo_search_properties returns a host domain, or after verify_vacation_rental_node confirms a domain from outside search, always before quoting final price or a booking link. Read-only: must not lock a quote, create a booking, collect guest details, or start checkout. Route booking only to the signed direct_booking_url; fall back to hemmabo_booking_negotiate/hemmabo_booking_checkout only when this call returns no signed offer, for a configured non-VRP deployment, after explicit user confirmation. The parameters work as a set: pass the same domain, checkIn, checkOut and guests the guest used at search; checkIn must be strictly before checkOut, and the resulting night count — not the dates themselves — drives the signed price and the host capacity check, so changing either date re-prices the offer. Always pass language as the guest's actual conversation language so the rendered widget matches the guest; it never affects the signed price or availability, only formatting.

Cancel a confirmed booking and process the Stripe refund per host cancellation policy. Use when the guest explicitly requests cancellation — if the guest wants new dates instead of ending the stay, use hemmabo_booking_reschedule instead. Do not use for pending/unpaid bookings — those expire automatically. To preview the applicable policy first, read cancellationPolicy from hemmabo_booking_status. Requires Authorization: Bearer token (MCP_API_KEY or OAuth); rate-limited per token. Destructive and idempotent in effect: a repeat cancel is refused as already cancelled and never triggers a second refund. reservationId is the booking UUID from hemmabo_booking_checkout or hemmabo_booking_create — never a propertyId — and must be paired with the guestToken issued for that same booking. reason is optional free text shown to the host; when omitted the host sees 'Cancelled via MCP'.

Create a fallback non-VRP booking and return a host-configured Stripe checkout URL. Use only after explicit user confirmation when no signed VRP direct_booking_url is available; when get_verified_stay_offer returns one, route the guest there instead. Use hemmabo_booking_create to record a pending booking without collecting payment yet. Behavior: existing bookings are never modified — availability is checked and dates briefly locked first; conflicts fail before anything is created or charged. Success creates exactly one pending booking and one Stripe Checkout Session on the host's connected account, returning paymentUrl, reservationId, and a one-time guestToken (required for status/cancel/reschedule). Only the Stripe webhook confirms the booking; unpaid pending bookings expire automatically. Not idempotent — check hemmabo_booking_status before retrying. Params: pass quoteId only for the exact propertyId/dates/guests locked by hemmabo_booking_negotiate (valid 15 min); omit to price fresh. channel selects which locked total is used; paymentMode changes only the handoff form, never the price. Requires Authorization: Bearer token (MCP_API_KEY or OAuth); rate-limited per token.

Create a pending direct booking without online payment for configured non-VRP fallback deployments. Use only after explicit user confirmation, with a propertyId from search, and only when no signed VRP direct_booking_url is available. For signed VRP offers, route to the signed host-domain URL instead. Requires Authorization: Bearer token (MCP_API_KEY or OAuth); rate-limited per token. Writes exactly one pending booking awaiting the host's decision; availability is checked first — conflicts or a stale calendar fail the call before anything is written. Not idempotent — check hemmabo_booking_status before retrying on timeout. There is no price or quoteId parameter — the node prices the stay itself at creation (gap-night pricing applies automatically). The booking is identified by propertyId + the checkIn/checkOut range + guests; guestName and guestEmail are required for host confirmation, guestPhone is optional. Returns bookingId and a one-time guestToken for later status/cancel/reschedule.

PRICE LOCK, not negotiation: the host's price is fixed — this tool never bargains, discounts, or alters it; it only freezes the current host-source price for 15 minutes so it cannot change during checkout. It refuses to lock dates the property's calendar cannot deliver and returns alternative bookable windows instead. Use it only in the non-VRP fallback checkout flow, when no signed direct_booking_url is available and the user explicitly asks to lock a price. Never use this for search, availability, VRP offers, rendering a stay-offer widget, or verified-offer display — use get_verified_stay_offer instead. Requires Authorization: Bearer token (MCP_API_KEY or OAuth); rate-limited per token. Not idempotent: each call writes a new snapshot; validUntil is fixed at creation and never extended — re-locking returns a new quoteId. The lock freezes both the public and the direct host-source total; hemmabo_booking_checkout's channel picks which one is redeemed. Redeem the quoteId only for the identical propertyId + checkIn/checkOut + guests, and only until validUntil — changing any of them requires a new quote. Night count and guest count together select the locked price tier.

Get a detailed pricing quote for a specific property, dates, and guest count. Use this tool after confirming availability to show the user exact pricing before booking. Do NOT use before checking availability — the quote may be invalid if dates are unavailable. Returns the final host-source total for the booking flow, per-night breakdown, and package pricing context. All prices are integers in the property's local currency (e.g. SEK). The quote is the propertyId priced for the exact checkIn/checkOut range and guests; the night count and party size together select the price tier, so changing any of them re-quotes.

Reschedule a confirmed or pending booking to new dates with automatic repricing and Stripe charge/refund. Use when the guest wants to change dates on an existing booking — if the guest wants to end the stay entirely rather than move it, use hemmabo_booking_cancel instead. Do not use if cancelled or if a protocol compatibility client reports completed — check hemmabo_booking_status first. Requires Authorization: Bearer token (MCP_API_KEY or OAuth). Destructive write: the original dates are released back to the host calendar and the original price no longer applies — the booking keeps the same reservationId (updated in place, never recreated), and the price difference is charged or refunded via Stripe. Rate-limited per token. Identify the existing booking by reservationId, then give the new stay as newCheckIn/newCheckOut (newCheckIn strictly before newCheckOut); the new night count re-prices the stay exactly like a fresh quote.

Retrieve current status and full details of an existing booking by reservationId. Use to confirm checkout/create succeeded or before cancel/reschedule. Do NOT use for property discovery, availability, or pricing — use hemmabo_search_properties, hemmabo_search_availability, or hemmabo_booking_quote for those. Requires Authorization: Bearer token (MCP_API_KEY or OAuth); rate-limited per token. Read-only against the database — never writes, so it is safe to poll after a checkout timeout — but returns guest PII (name, email). reservationId is the booking UUID returned by hemmabo_booking_checkout or hemmabo_booking_create — never a propertyId — and guestToken is the secret issued with that same booking: a mismatched pair reveals nothing, not even that the booking exists. Without a reservationId there is no booking to look up yet.

Return a safe HemmaBo onboarding handoff URL for a vacation-rental host who wants their own booking website or booking engine. Not for guests — guests should use hemmabo_search_properties instead. Use after explaining the fit or when the host asks to start; if the host is still evaluating whether HemmaBo fits, run hemmabo_host_readiness_check first — it already returns the same prefilled URL in its next_step. This tool is read-only and does not create a HemmaBo account, buy a domain, configure Stripe, write to Supabase, or provision a booking site. It returns the URL, what the host gets, and what the host should prepare. All parameters are optional prefill: they never change where the host lands — the URL always opens the same onboarding page with the passed details filled in; blank values are simply left out, and nothing is stored server-side.

Read-only fit check for a vacation-rental host evaluating HemmaBo for their own booking website or booking engine. Use when the user is a host or property owner, not a guest booking a stay; guests should use hemmabo_search_properties instead. Returns a fit verdict, what the host gets, the setup inputs to prepare, and a safe onboarding next step. Does not create an account, buy a domain, configure Stripe, store host data, or provision a website. When the host is ready to start, follow up with hemmabo_host_onboarding_link. Only five inputs sharpen the fit verdict: a domain (hasOwnDomain or domain), currentChannels, one location signal (city/region/country), and the wants* booleans, which count unless explicitly false — omitting them never lowers the verdict; propertyName and preferredLanguage only prefill the onboarding URL, and with no inputs the summary is generic.

Check whether a specific property is available for the requested dates. Use this tool after the user has selected a property from hemmabo_search_properties and wants to confirm availability before getting a quote. Do NOT use for general browsing — use hemmabo_search_properties instead. Read-only, open to anonymous callers (no Bearer token), and rate-limited: checking availability never places a hold or reserves dates. Returns available=true/false with conflict details and, when unavailable, the host node's own next available window (alternativeDates, at most one entry — the same window the node's /api/availability reports, never a platform-invented date); a stale inbound calendar sync blocks an available answer (fails closed with calendar_freshness) instead of guessing. Omit guests to check dates only; pass it to price the alternative windows and to gate capacity — counts above the property's maximum return available=false (guests_exceed_max) with no alternatives. Stays shorter than the host's effective minimum nights return available=false with reasonCode min_nights_violation — extend the stay rather than shifting dates. The verdict always matches the host node's own availability API.

Search available vacation rental properties by location and travel dates. Use when the user wants to find or browse places to stay. Discovery only — call get_verified_stay_offer with the host domain and same dates before the final answer so the client can render the verified stay offer widget; never quote a final price or booking link from search alone. Do NOT use when the user already has a propertyId or host domain. Returns propertyId, host domain, live availability, host-source pricing, and capacity. Parameters combine as one filter with guests and the checkIn/checkOut range (checkIn strictly before checkOut): region matches broadly against region, city, and country names, while country matches the country field alone — omit both and the search spans every published property. Capacity misses are excluded; date-unavailable matches return separately in unavailableMatches with up to three alternative windows.

Verify that a vacation-rental host domain is a valid Vacation Rental Protocol (VRP) node before trusting it. Reads the domain's .well-known/vacation-rental.json and JWKS. Read-only trust check: no availability, pricing, booking, or payment — do NOT use it to answer those questions. Use when a host domain arrives from outside search (user-typed or third-party); domains returned by hemmabo_search_properties can go straight to get_verified_stay_offer. On success, call get_verified_stay_offer with the same domain and stay dates. The single input is the host domain as a bare hostname (no scheme or path); public domains only — IPs, ports, and local/private hostnames are refused. Pass the node's canonical domain exactly — www and apex are distinct identities, and verification fails when the domain's declared canonical_domain differs from the one you passed. Verification reads that domain's own .well-known and JWKS, so the result is only as trustworthy as the exact domain you pass.