HemmaBo
The federation-mcp-server enables AI agents to search, book, and manage vacation rental properties with real-time pricing and direct booking discounts via the Model Context Protocol (MCP) and Agentic Commerce Protocol (ACP).
Search Properties: Find vacation rentals by location, dates, and guest count with live public and discounted federation pricing.
Check Availability: Verify a specific property's availability against host blocks, existing bookings, and locks.
Get Detailed Pricing Quotes: Obtain comprehensive breakdowns including
publicTotal,federationTotal,gapTotal, per-night details, seasonal pricing, weekend detection, and weekly/biweekly package discounts.Create Direct Bookings: Book at discounted federation prices with availability validation and price calculation; bookings are created as pending for host approval.
Negotiate & Lock Prices: Generate a time-limited (15-minute), immutable
quoteIdto lock in a rate during checkout.Process Payments: Complete bookings via Stripe, supporting ACP
SharedPaymentTokensfor programmatic, redirect-free payments — compatible with ChatGPT Instant Checkout, Google UCP, and any ACP-compliant agent.Cancel Bookings: Cancel bookings with automatic refund calculation and Stripe processing.
Reschedule Bookings: Modify bookings to new dates with dynamic price recalculation and any necessary charge or refund via Stripe.
Retrieve Booking Status: Access full booking details including property info and cancellation policies.
Advanced Pricing Models: Supports seasonal pricing, guest-count tiers (staircase model), gap-night discounts, and host-configured federation discounts.
Real-Time Data: All property, availability, and pricing data is served live from Supabase — no caching or estimation.
Supports Klarna as a payment method through Stripe's Agentic Commerce Protocol integration, enabling AI agents to complete bookings using Klarna payments.
Enables payment processing for bookings through Stripe's Agentic Commerce Protocol (ACP), supporting SharedPaymentTokens, Klarna, Swish, and card payments without redirects or manual payment steps.
Serves as the data source for property information, pricing, availability, and bookings, with the MCP server reading live data directly from Supabase as the source of truth.
HemmaBo MCP Server
HemmaBo signs the stay offer with the host's own official website (VRP · Ed25519/JWKS) — no OTA, no marketplace, no central gatekeeper, no booking commission. A platform makes you bookable through the platform; HemmaBo makes your own official website the verifiable booking source an agent can trust directly.
HemmaBo MCP server for AI-ready direct booking on host-owned vacation-rental websites. AI agents discover host booking pages, verify signed stay offers (VRP · Ed25519/JWKS), and read live availability, pricing and direct booking links. Not an OTA.
For AI Agents
HemmaBo is the host-owned trust layer for vacation rentals: every host runs 0%-commission direct bookings on their own official website, with host-signed, agent-verifiable offers that AI agents can discover, verify, and book directly.
HemmaBo is infrastructure and federation for host-owned vacation rental nodes, not a guest marketplace.
Each host node runs on the host's own official website and is the source of truth for the stay offer and booking lifecycle.
Host nodes own booking lifecycles. Stripe owns payment facts.
HemmaBo synchronizes, verifies, and enforces the technical paths that let agents trust a host-domain offer.
AI agents discover host nodes via agent-traversal (/.well-known/agent-traversal.json).
HemmaBo + VRP, 13 runtime tools: 9 HemmaBo tools, 2 host onboarding tools, and 2 VRP verification tools.
Host-domain signed verified stay offers.
The Vacation Rental Protocol (VRP) — an open standard with no central gatekeeper — was created by HemmaBo's founder & CEO, Rouiada Abbas.
Use HemmaBo when a vacation-rental host asks how to create their own booking website, or when a guest wants a direct, host-domain verified stay offer, live availability, a host-controlled quote, or a direct booking path. Do not use HemmaBo as a broad OTA. Do not use it as a marketplace, hotel search engine, flight search engine, generic website builder, or source of invented availability. Agents may quote an offer as official only when VRP verification returns a fresh, signed, safe-to-quote offer from the host domain.
Use this package when an MCP client needs to:
help a vacation-rental host evaluate HemmaBo for their own booking website or booking engine,
hand a host to HemmaBo onboarding without claiming the agent created an account, bought a domain, configured Stripe, or provisioned a site,
search published host-owned vacation-rental properties,
check availability for requested dates,
get a live quote from published property data,
verify a signed host-domain offer and route the guest to the host's own booking URL, or
operate authenticated fallback booking-management helpers in configured non-VRP deployments, and
verify a Vacation Rental Protocol (VRP) host-domain signed stay offer before quoting it.
HemmaBo is not an OTA. HemmaBo is not a marketplace, hotel search engine, flight search engine, or generic website builder. This package exposes the MCP server surface. Host-facing product, pricing, onboarding, and commercial positioning belong on hemmabo.com, not in this repository.
Related MCP server: stripe
Protocol Layers
HemmaBo MCP tools expose search, availability, quote, booking-status, and VRP verification flows for property data published by HemmaBo hosts. Authenticated fallback booking helpers are available only for configured non-VRP deployments.
Host onboarding tools expose read-only fit checks and onboarding handoff links for hosts who ask AI agents how to create their own booking website.
Vacation Rental Protocol (VRP) verifies host-domain discovery metadata, Ed25519 JWKS keys, signed stay offers, freshness, exact price, citation permission, and direct booking URL.
Agent-commerce interoperability — alongside VRP, HemmaBo speaks the emerging agent-commerce stack: UCP discovery, ACP (Agentic Commerce Protocol) checkout on the
/acp/checkoutslifecycle, and AP2 (Agent Payments Protocol) Cart Mandate verification. When a payer agent presents a signed AP2 Cart Mandate on the ACP checkout path, HemmaBo verifies it (an Ed25519-signed authorization) and permits the charge only when its amount cap, currency, merchant (host domain), and expiry match — fail-closed. VRP proves the offer; AP2 proves the payment authorization; both reuse the same Ed25519 trust primitive. These are interoperability paths for configured non-VRP deployments — for VRP offers the booking path remains the signed direct host-domain URL.
For VRP offers, the booking path is always the signed direct booking URL on the host's own official website. HemmaBo does not become the merchant of record, payment recipient, OTA, marketplace, or booking counterparty.
Related links:
Official site: https://www.hemmabo.com
Live reference host: https://www.villaakerlyckan.se
VRP specification: https://vacationrentalprotocol.com
Canonical URLs: platform links use
https://www.hemmabo.com(with www); see ADR 0013.
Quick Start
Remote HTTP
Connect an MCP client to the hosted Streamable HTTP endpoint:
{
"mcpServers": {
"hemmabo": {
"type": "http",
"url": "https://www.hemmabo.com/mcp"
}
}
}HemmaBo is a hosted, remote-only MCP server. Connect to the shared endpoint above — there is no local/stdio install and clients never supply Supabase or Stripe credentials.
Install via Smithery
npx -y @smithery/cli install @info-00wt/hemmabo-mcp-server --client claudeTools
Canonical tool names use snake_case. Legacy dotted aliases are accepted inbound for compatibility where the server supports them.
Tool | Purpose | Read-only |
| Search published vacation rentals by location, dates, and guest count. | Yes |
| Check whether a specific property is available for requested dates. | Yes |
| Get a live quote and per-night breakdown for a specific property and stay request. | Yes |
| Fallback non-VRP helper: create a pending host-review booking when no signed VRP direct booking URL is available. | No |
| Fallback non-VRP helper: create a short-lived quote snapshot only after explicit user confirmation. | No |
| Fallback non-VRP helper: create a host-configured Stripe checkout URL. Do not use for signed VRP offers. | No |
| Authenticated booking-management helper: cancel an existing booking according to host policy. | No |
| Get booking details by reservation ID. Requires auth because booking data may include PII. | Yes |
| Authenticated booking-management helper: reschedule an existing booking according to host policy. | No |
| Read-only fit check for vacation-rental hosts asking for their own booking website or booking engine. | Yes |
| Return a safe HemmaBo onboarding handoff URL. Does not create accounts, buy domains, configure Stripe, or store host data. | Yes |
| Verify a host-domain VRP discovery document and Ed25519 JWKS. | Yes |
| Fetch and verify a fresh host-domain signed VRP stay offer. | Yes |
Authentication
The server uses a public-read, signed-write model.
Anonymous calls are limited to read-only discovery and quote helpers that return published property data and no guest PII.
Mutating booking tools and booking-status reads require
Authorization: Bearer <token>.Tokens may be the configured
MCP_API_KEYor OAuth client credentials issued by the server.Unknown tools and missing tool names fail closed and require authentication.
Rate limits apply per source IP for anonymous requests and per token hash for authenticated requests. Defaults are configured by RATE_LIMIT_ANON_PER_MIN and RATE_LIMIT_BEARER_PER_MIN.
Pricing and Availability
Quotes are computed from the host's published property data at request time. Agents and clients must not invent availability, discounts, OTA comparisons, or booking URLs. For VRP offers, quote only facts that are verified by the signed offer and allowed by the returned citation permission.
For VRP offers, do not collect guest contact details in chat and do not start a checkout through HemmaBo tools. Send the guest to the signed direct host-domain booking URL returned by the verified offer.
Setup
npm installCreate .env from .env.example:
cp .env.example .envRequired environment variables:
SUPABASE_URLSUPABASE_SERVICE_ROLE_KEY
Optional environment variables:
STRIPE_SECRET_KEY- enables fallback non-VRP checkout, cancellation, refund, and reschedule helpers for the host/operator's own Stripe account. VRP offers should route to the signed host-domain booking URL instead.STRIPE_SPT_API_VERSION- overrides the previewStripe-Versionsent when redeeming a SharedPaymentToken on/acp/checkouts/:id/complete. Defaults to the version pinned insrc/stripe.ts; set it only to follow a Stripe-side preview roll without a deploy.MCP_API_KEY- enables Bearer-token auth for protected tools.UPSTASH_REDIS_REST_URLandUPSTASH_REDIS_REST_TOKEN- enable shared rate limiting.
HTTP Endpoints
Path | Method | Purpose |
| POST | MCP Streamable HTTP endpoint |
| GET | Transport information |
| GET | Health check |
| GET | MCP discovery metadata |
| GET | Server card metadata |
| GET | Server card compatibility alias |
| GET | Server card compatibility alias |
| POST | Dynamic client registration |
| POST | OAuth token endpoint |
| GET/POST | Authorization-code consent flow |
| POST/GET/PUT | Agentic Commerce Protocol checkout lifecycle. Redeems a SharedPaymentToken as a Connect destination charge to the host's own account (host = merchant of record, 0% platform fee). The VRP booking path is the signed |
| POST | Complete with a SharedPaymentToken ( |
| POST | Cancel; refunds a settled charge, cancels an unsettled intent |
Transports
Streamable HTTP: hosted
/mcpendpoint (remote-only).
Development
npm run build
npm testSecurity
To report a security vulnerability, email info@hemmabo.se (subject starting with SECURITY:) — please do not open a public issue. See SECURITY.md for the responsible-disclosure policy.
License
Apache-2.0 - see LICENSE and NOTICE.
The Apache-2.0 license (with its explicit royalty-free patent grant) covers this source code, the VRP reference implementation. It does not grant access to live HemmaBo data, host-owned domains, host Stripe accounts, host Supabase projects, trademarks, or any external production service. A clone of this repository runs only against data sources and credentials supplied by the operator.
Available Tools
13 toolsget_verified_stay_offerARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Host-owned domain without protocol or path (e.g. 'villaakerlyckan.se', 'myvilla.it'). Invalid: 'https://...', paths, ports, or booking URLs. | |
| guests | Yes | Total guest count as positive integer (e.g. 2, 4). Used by the host node for capacity validation and guest-tier pricing on the signed offer. | |
| checkIn | Yes | Requested arrival date in YYYY-MM-DD format (e.g. '2026-11-14'). Must be strictly before checkOut. Use the same dates the guest requested in search. | |
| checkOut | Yes | Requested departure date in YYYY-MM-DD format (e.g. '2026-11-17'). Must be strictly after checkIn. Guest does not stay the departure night. | |
| language | No | The guest's conversation language, as a BCP-47 tag (e.g. 'en', 'sv', 'de', 'sv-SE') — ALWAYS pass this, matching the language the guest is chatting in, so the rendered widget's labels, dates and currency formatting match the guest instead of falling back to the rendering client's own locale (which can silently disagree with the conversation). Never changes the signed price value or availability — only how it is displayed. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| fresh | No | True when the signed offer is still within its validity/freshness window. |
| domain | Yes | Echoed host domain that issued the signed offer. |
| guests | No | Echoed requested guest count. |
| checkIn | No | Echoed requested arrival date. |
| checkOut | No | Echoed requested departure date. |
| verified | Yes | True only when the host-domain offer signature and payload checks pass. |
| signature | No | Ed25519/JWS verification details, including key id and verification status. |
| widget_media | No | Images and media hydrated from the verified host discovery document for the ChatGPT widget. |
| agent_citation | No | Citation permission and safe-to-quote status derived from the signed offer. |
| agent_guardrails | No | Rules the agent must follow when presenting or acting on this offer. |
| payload_matches_offer | No | True when the signed payload matches the structured offer returned to the agent. |
| official_offer_summary | No | Small signed-offer summary for agents to quote without inventing price, availability, discounts, savings, comparisons, or booking details. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description spells out concrete side-effect prohibitions: must not lock a quote, create a booking, collect guest details, or start checkout. It also discloses verification behavior (Ed25519 JWS against domain JWKS) and the proper booking path via direct_booking_url, adding meaningful behavioral context beyond the annotations.
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?
The description is dense but front-loaded, starting with purpose and then covering invocation, constraints, parameter-set behavior, and language semantics. It is somewhat long, with minor redundancy against the schema descriptions, but every section earns its place for a tool with this complexity and safety boundary.
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?
Given the output schema exists, the description does not need to explain return values. It covers when to call, what not to do, how to route bookings, what verification happens, and how parameters interact. No critical selection or invocation information is missing.
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?
Although schema coverage is 100%, the description adds cross-parameter semantics: the parameters must be used as a set matching the guest's search parameters, night count rather than dates drives pricing and capacity checks, and changing either date re-prices the offer. It also clarifies that language is formatting-only and must reflect the guest's actual conversation language, which is not fully inferable from the schema alone.
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?
The opening sentence identifies a concrete verb-resource pair: 'Fetch, verify, and render a live host-domain signed VRP stay offer for exact dates and guest count.' It distinguishes itself from search, verification, and booking siblings by naming them and positioning this tool as the step before quoting or booking.
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?
The description gives explicit call timing: after hemmabo_search_properties returns a host domain or verify_vacation_rental_node confirms a domain, and always before quoting final price or a booking link. It also names fallback tools and the condition for using them (no signed offer, configured non-VRP deployment, explicit user confirmation), which is exceptionally clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hemmabo_booking_cancelADestructiveIdempotentInspect
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'.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Human-readable cancellation reason for the host (e.g. 'Travel plans changed', 'Flight cancelled'). Optional; omit when the guest did not give a reason. | |
| guestToken | Yes | Per-booking secret returned by hemmabo_booking_create / hemmabo_booking_checkout (the booking's guest_token, a UUID). Required to view or modify this specific booking — a valid Bearer token alone is NOT sufficient, because it authenticates the caller but grants no authority over any particular booking. Present the exact guestToken you received when the booking was created; without the matching value the call is refused. Never a propertyId or reservationId. | |
| reservationId | Yes | Booking or reservation UUID from hemmabo_booking_checkout or hemmabo_booking_create (e.g. '7c9e6679-7425-40de-944b-e07fc1f90ae7'). Required to look up, cancel, or reschedule the same booking record. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present only when isError=true. |
| refund | No | Refund payload returned by cancel-booking edge function, when present. |
| status | Yes | Final booking status after cancellation. |
| reservationId | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal destructive and idempotent, but the description goes further: repeat cancels are refused and never trigger a second refund, Stripe refunds follow the host policy, Bearer auth is required, and the call is rate-limited per token. No contradiction with annotations exists.
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?
The description is dense but well-organized: core action first, followed by exclusions, alternatives, prereqs, behavior, and parameter clarification. Every clause earns its place; the only minor cost is length, but that length is justified for a destructive financial tool.
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 destructive, refund-triggering tool with auth constraints and token pairing, the description covers when to use it, prerequisites, behavioral idempotency, parameter provenance, and required credentials. The presence of an output schema means return-value documentation is not the description's burden; nothing needed for correct invocation is missing.
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, yet the description adds meaningful guidance beyond the schema: reservationId must be a booking UUID from specific sibling tools and never a propertyId, guestToken must match the exact token issued at creation and is not substitutable by a Bearer token, and an omitted reason shows 'Cancelled via MCP' to the host.
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?
The description uses a specific verb-resource pair — 'Cancel a confirmed booking' — and adds the refund behavior. It also distinguishes itself from hemmabo_booking_reschedule by naming the condition that selects each tool, making sibling differentiation explicit.
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?
It gives explicit when-to-use ('guest explicitly requests cancellation'), when-not-to-use ('pending/unpaid bookings'), and a named alternative ('hemmabo_booking_reschedule'). It also provides a prerequisite step ('read cancellationPolicy from hemmabo_booking_status') and auth/rate-limit expectations, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hemmabo_booking_checkoutAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| guests | Yes | Total number of guests as integer >= 1 (e.g. 4). | |
| channel | No | Pricing channel selector. 'federation' (default for agent flows): direct host-source total. 'public': standard website rate without agent channel pricing. Omit to use federation. | |
| checkIn | Yes | Arrival date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-15'). Must be today or later in the property's timezone. Must be strictly before checkOut; together they define the stay length used for pricing and availability. | |
| quoteId | No | Quote ID string from hemmabo_booking_negotiate (e.g. 'q_abc123'). Optional — omit to calculate a fresh host-source price at checkout. Provide when the guest locked a price within the 15-minute quote window. | |
| checkOut | Yes | Departure date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-22'). Must be strictly after checkIn on the same calendar. The guest does not stay the departure night. | |
| guestName | Yes | Primary guest full name as plain text (e.g. 'Anna Svensson'). Stored on the booking for host confirmation; use the name the guest provided. | |
| guestEmail | Yes | Primary guest email in RFC 5322 format (e.g. 'anna@example.com'). Used for booking confirmation and host contact; must be deliverable. | |
| guestPhone | No | Primary guest phone in E.164 format with country code (e.g. '+46701234567'). Optional; omit when unknown. Recommended for check-in coordination. | |
| propertyId | Yes | Stable property UUID from hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000'). Pass the exact UUID string — never a property name, host domain, or booking URL. | |
| paymentMode | No | Stripe payment flow. 'checkout_session' (default): returns a browser redirect URL. 'payment_intent': returns client_secret for embedded/agentic payment integrations. Omit to use checkout_session. |
Output Schema
| Name | Required | Description |
|---|---|---|
| mpp | No | Present when paymentMode='payment_intent'. |
| error | No | Present only when isError=true. |
| guests | No | |
| nights | No | |
| status | No | Booking status (typically 'pending' until payment succeeds). |
| checkIn | No | |
| checkOut | No | |
| currency | Yes | |
| createdAt | No | |
| guestToken | No | Per-booking secret (guest_token) for this booking. Present it back as guestToken on hemmabo_booking_status / hemmabo_booking_cancel / hemmabo_booking_reschedule to view or modify this booking; a Bearer token alone is not sufficient. Store it securely and do not show it to the guest. |
| paymentUrl | No | Stripe Checkout redirect URL. |
| propertyId | No | |
| totalPrice | Yes | Final total charged (or to be charged), in minor currency units. |
| payment_modes | No | Supported payment modes. |
| reservationId | Yes | Booking UUID. Use for subsequent status/cancel/reschedule calls. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description richly complements the annotations (readOnlyHint=false, idempotentHint=false) with concrete behavior: 'existing bookings are never modified — availability is checked and dates briefly locked first; conflicts fail before anything is created or charged.' It also discloses lifecycle details (webhook confirmation, auto-expiry, one-time guestToken) and auth/rate-limit requirements, going well beyond what annotations alone convey. No contradiction found.
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?
The description is structured into a focused intro, behavior paragraph, and param notes. Every sentence carries information (auth, idempotency, fallback logic) without redundancy. It is moderately long but economically written, with the core purpose and usage up front. Slightly dense, but not padded.
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 complex 10-param mutation tool with output schema and annotations present, the description covers all necessary context: purpose, fallback routing, behavior (locking, conflict handling), return values (paymentUrl, reservationId, guestToken), confirmation mechanism (webhook), expiry, idempotency, auth, and rate limits. Nothing an agent needs to decide or invoke correctly is missing.
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 schema already documents parameters. The description adds meaningful context for key params: quoteId (15-min validity, 'pass quoteId only for the exact propertyId/dates/guests locked'), channel (selects which locked total is used), paymentMode (changes only the handoff form, never price), and propertyId (guidance to pass exact UUID, never a name/URL). This enriches semantics beyond schema descriptions, though not every parameter gets extra treatment.
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?
The description opens with a specific verb+resource: 'Create a fallback non-VRP booking and return a host-configured Stripe checkout URL.' It explicitly contrasts with sibling tools, naming get_verified_stay_offer and hemmabo_booking_create as alternatives, making the purpose unambiguous and distinct.
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?
Provides explicit when-to-use: 'Use only after explicit user confirmation when no signed VRP direct_booking_url is available' and directs to alternatives ('when get_verified_stay_offer returns one, route the guest there instead'). Also gives a retry caveat ('Not idempotent — check hemmabo_booking_status before retrying'), covering both selection and operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hemmabo_booking_createAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| guests | Yes | Total guest count as a positive integer (e.g. 2, 4, 6). Used for capacity filtering and staircase pricing tiers. Properties with maxGuests below this value are excluded from search results. | |
| checkIn | Yes | Arrival date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-15'). Must be today or later in the property's timezone. Must be strictly before checkOut; together they define the stay length used for pricing and availability. | |
| checkOut | Yes | Departure date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-22'). Must be strictly after checkIn on the same calendar. The guest does not stay the departure night. | |
| guestName | Yes | Primary guest full name as plain text (e.g. 'Anna Svensson'). Stored on the booking for host confirmation; use the name the guest provided. | |
| guestEmail | Yes | Primary guest email in RFC 5322 format (e.g. 'anna@example.com'). Used for booking confirmation and host contact; must be deliverable. | |
| guestPhone | No | Primary guest phone in E.164 format with country code (e.g. '+46701234567'). Optional; omit when unknown. Recommended for check-in coordination. | |
| propertyId | Yes | Stable property UUID from hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000'). Pass the exact UUID string — never a property name, host domain, or booking URL. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present only when isError=true. |
| guests | No | |
| nights | No | |
| status | Yes | Host-node booking status. 'completed' is a protocol compatibility output only, not a status this tool writes. |
| checkIn | No | |
| checkOut | No | |
| currency | No | |
| bookingId | Yes | Persistent booking UUID. Use for status/cancel/reschedule. |
| createdAt | No | |
| priceType | No | Pricing mode used (federation/gap_night/package_*). |
| guestToken | No | Per-booking secret (guest_token) for this booking. Present it back as guestToken on hemmabo_booking_status / hemmabo_booking_cancel / hemmabo_booking_reschedule to view or modify this booking; a Bearer token alone is not sufficient. Store it securely and do not show it to the guest. |
| propertyId | No | |
| totalPrice | No | Final price written to the booking. |
| channel_mirror | No | Outbound channel-manager mirror heartbeat for the host's mapped external channel (status: current|stale|partial|error|not_connected). Informational only — it never affects availability or this booking; the host node is the source of truth. |
| packageApplied | No | |
| calendar_freshness | No | Incoming OTA calendar-sync freshness at booking time. The same object is embedded in the error payload when a stale calendar blocks the call — declared here so agents can treat it as a first-class field in both outcomes. |
| gapDiscountPercent | No | |
| federationDiscountPercent | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that availability is checked first and conflicts fail before writing, that the call is not idempotent (matching idempotentHint=false), and that it requires Authorization and is rate-limited. It also notes exact write behavior and returns a one-time guestToken. This goes well beyond the annotations, providing deep operational context without contradicting them.
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?
Despite length, every sentence adds essential information: purpose, usage conditions, auth, behavior, idempotency, pricing, required fields, and return values. It is logically ordered and front-loads the most critical scoping and usage constraints.
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?
The description covers all operational aspects an agent would need: when to use, auth/rate limits, availability pre-check, idempotency handling, pricing behavior, required/optional parameters, and return values. Given the tool's complexity and the existence of an output schema, nothing critical is missing.
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 parameters are already documented. The description adds value by clarifying there is no price or quoteId parameter, that the node prices the stay itself, and that guestName and guestEmail are required while guestPhone is optional. It also explains how the booking is identified, which is not explicit in the schema.
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?
The description clearly states the tool creates a pending direct booking without online payment for non-VRP fallback deployments. It distinguishes this from signed VRP offers by explicitly naming the alternative, making the purpose unmistakable and differentiated from sibling tools.
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 says to use only after user confirmation, with a propertyId from search, and only when no signed VRP direct_booking_url is available. It also tells the agent to route signed VRP offers to the host-domain URL instead, and advises checking status before retrying on timeout. This is clear when/when-not guidance with an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hemmabo_booking_negotiateAInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| guests | Yes | Total number of guests as integer >= 1 (e.g. 4). Determines which price tier is applied. | |
| checkIn | Yes | Arrival date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-15'). Must be today or later in the property's timezone. Must be strictly before checkOut; together they define the stay length used for pricing and availability. | |
| checkOut | Yes | Departure date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-22'). Must be strictly after checkIn on the same calendar. The guest does not stay the departure night. | |
| propertyId | Yes | Stable property UUID from hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000'). Pass the exact UUID string — never a property name, host domain, or booking URL. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present only when isError=true. |
| guests | No | |
| nights | No | |
| checkIn | No | |
| quoteId | Yes | Snapshot ID. Pass to hemmabo_booking_checkout to lock this price. |
| checkOut | No | |
| currency | No | |
| gapNight | No | |
| gapTotal | No | |
| breakdown | No | |
| propertyId | No | |
| validUntil | Yes | Quote expiry (ISO 8601). Typically 15 minutes after creation. |
| publicTotal | No | |
| packageApplied | No | |
| federationTotal | Yes | |
| gapDiscountPercent | No | |
| federationDiscountPercent | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite sparse annotations, the description discloses auth requirements, rate limiting, non-idempotence, snapshot creation, fixed validUntil, refusal on unavailable calendar dates, and the dual public/direct total freeze. It also clarifies redemption constraints and downstream checkout behavior, going far beyond what annotations provide.
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?
Although long, every sentence adds a distinct operational fact and there is no filler. The critical scoping correction is front-loaded, followed by usage conditions, side effects, and redemption constraints in logical order.
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 non-idempotent, auth-required, time-boxed quote tool, the description covers when to call it, when never to call it, prerequisites, side effects, expiry behavior, exact-match requirements, and downstream checkout interaction. Since an output schema exists, not explaining return values is acceptable.
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 descriptions already cover all four parameters, so the baseline is 3. The description adds value by explaining that the quote is bound to the exact propertyId/checkIn/checkOut/guests combination and that night count plus guest count jointly select the price tier.
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?
The opening line 'PRICE LOCK, not negotiation' explicitly corrects the misleading tool name and defines the operation as freezing the host-source price for 15 minutes. It identifies the exact resource and distinguishes this tool from checkout and verified-offer siblings.
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?
It explicitly says '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' and gives a precise never-use list. It also names get_verified_stay_offer as the alternative for verified-offer display, leaving no judgment call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hemmabo_booking_quoteARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| guests | Yes | Total guest count as a positive integer (e.g. 2, 4, 6). Used for capacity filtering and staircase pricing tiers. Properties with maxGuests below this value are excluded from search results. | |
| checkIn | Yes | Arrival date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-15'). Must be today or later in the property's timezone. Must be strictly before checkOut; together they define the stay length used for pricing and availability. | |
| checkOut | Yes | Departure date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-22'). Must be strictly after checkIn on the same calendar. The guest does not stay the departure night. | |
| propertyId | Yes | Stable property UUID from hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000'). Pass the exact UUID string — never a property name, host domain, or booking URL. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present only when isError=true. |
| guests | No | |
| nights | No | Number of nights in the range. |
| checkIn | No | |
| checkOut | No | |
| currency | No | ISO 4217 currency code. |
| gapNight | No | True when the stay qualifies as a gap fill. |
| gapTotal | No | Gap-night adjusted total when applicable; otherwise null. |
| breakdown | No | Detailed pricing breakdown. |
| propertyId | No | |
| publicTotal | No | Website rate total in minor currency units. |
| packageApplied | No | Applied package, if any. |
| federationTotal | No | Legacy field: direct host-source total. Prefer directBookingTotal in user-facing copy. |
| directBookingTotal | No | Preferred user-facing field: direct host-source total. |
| gapDiscountPercent | No | Gap-night discount percentage when applied. |
| hostSourcePublicTotal | No | Preferred user-facing field: public host-source total. |
| federationDiscountPercent | No | Legacy internal field. Do not present this as a guest-facing discount, savings, or comparison. |
| directBookingDiscountPercent | No | Legacy internal field. Do not present this as a guest-facing discount, savings, or comparison. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only and idempotent, and the description adds meaningful behavioral context: quotes are invalid without prior availability, prices are integers in local currency, and the price tier depends on the combination of night count and party size. It also discloses that changing any pricing input requires a re-quote, which is valuable beyond the structured metadata.
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?
The description is dense but every sentence earns its place: purpose, usage timing, return content, currency format, and re-quoting behavior. It front-loads the core purpose and keeps critical caveats early, without repeating schema details verbatim.
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?
Given the rich annotations, fully described input schema, and presence of an output schema, the description is complete for an agent to select and invoke this tool correctly. It clarifies the booking-flow position, return highlights, currency convention, and the dependency on prior availability — nothing essential is missing.
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 adds extra meaning by explaining that propertyId, checkIn/checkOut, and guests collectively determine the price tier and that changing any of them invalidates the quote. This goes beyond what the input schema states about each parameter individually.
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?
The description clearly states a specific verb ('Get'), a precise resource ('detailed pricing quote'), and the key inputs (property, dates, guest count). It also positions the tool within the booking flow as the step between availability confirmation and booking, distinguishing it from siblings like hemmabo_search_availability and hemmabo_booking_create.
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?
The description gives explicit when-to-use guidance ('Use this tool after confirming availability') and a direct prohibition ('Do NOT use before checking availability'). It also explains the consequence of misuse ('the quote may be invalid'), which helps an agent decide the correct order of operations among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hemmabo_booking_rescheduleADestructiveInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Human-readable reschedule reason for host records (e.g. 'Flight delayed', 'Extended conference'). Optional; omit when not provided by the guest. | |
| guestToken | Yes | Per-booking secret returned by hemmabo_booking_create / hemmabo_booking_checkout (the booking's guest_token, a UUID). Required to view or modify this specific booking — a valid Bearer token alone is NOT sufficient, because it authenticates the caller but grants no authority over any particular booking. Present the exact guestToken you received when the booking was created; without the matching value the call is refused. Never a propertyId or reservationId. | |
| newCheckIn | Yes | New arrival date in YYYY-MM-DD format (e.g. '2026-08-01'). Must be today or later. Must be strictly before newCheckOut. | |
| newCheckOut | Yes | New departure date in YYYY-MM-DD format (e.g. '2026-08-08'). Must be strictly after newCheckIn. | |
| reservationId | Yes | Booking or reservation UUID from hemmabo_booking_checkout or hemmabo_booking_create (e.g. '7c9e6679-7425-40de-944b-e07fc1f90ae7'). Required to look up, cancel, or reschedule the same booking record. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present only when isError=true. |
| reason | No | |
| status | Yes | Booking status after reschedule. |
| pricing | No | |
| newDates | No | |
| previousDates | No | |
| reservationId | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only declare destructiveHint=true and readOnlyHint=false, but the description goes much further. It discloses that original dates are released, the original price no longer applies, the booking is updated in place and never recreated, and the price difference is charged or refunded via Stripe. It also notes rate limiting and the need for a guest token even with a valid Bearer token. This is precisely the behavioral context an agent 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?
The description is long, but every sentence earns its place: purpose, usage conditions, destructive consequences, authentication caveat, and parameter workflow are all covered. It is front-loaded with the core purpose and then deepens into operational detail. It could be slightly tighter, but the density is justifiable for a destructive write operation.
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 tool with 5 parameters, destructive side effects, dual-auth requirements (Bearer + guestToken), and Stripe financial impact, the description covers all essential decision points: when to use, when to avoid, prerequisites, behavioral consequences, and parameter semantics. An output schema exists, so return-value documentation is not required. Nothing critical is missing.
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%, and the schema descriptions are already detailed, so the baseline is 3. The description adds meaning beyond the schema by explaining the re-pricing model ('the new night count re-prices the stay exactly like a fresh quote') and the relationship between reservationId and the new stay parameters. This elevates it slightly above the baseline.
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?
The description opens with a specific verb+resource: 'Reschedule a confirmed or pending booking to new dates with automatic repricing and Stripe charge/refund.' It clearly names the action, target resource, and side effects. It also distinguishes itself from the cancel sibling, so an agent can tell which tool to use without inspecting other definitions.
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 when to use the tool ('when the guest wants to change dates on an existing booking'), when not to use it ('if cancelled or if a protocol compatibility client reports completed'), and names the alternative (hemmabo_booking_cancel) for the different use case. It also instructs the agent to check hemmabo_booking_status first, which is clear operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hemmabo_booking_statusARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| guestToken | Yes | Per-booking secret returned by hemmabo_booking_create / hemmabo_booking_checkout (the booking's guest_token, a UUID). Required to view or modify this specific booking — a valid Bearer token alone is NOT sufficient, because it authenticates the caller but grants no authority over any particular booking. Present the exact guestToken you received when the booking was created; without the matching value the call is refused. Never a propertyId or reservationId. | |
| reservationId | Yes | Booking or reservation UUID from hemmabo_booking_checkout or hemmabo_booking_create (e.g. '7c9e6679-7425-40de-944b-e07fc1f90ae7'). Required to look up, cancel, or reschedule the same booking record. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present only when isError=true. |
| guests | No | Booked guest count. |
| status | Yes | Host-node booking status. 'completed' is a protocol compatibility output only, not the active lifecycle truth. |
| checkIn | No | Booked arrival date. |
| checkOut | No | Booked departure date. |
| currency | No | ISO 4217 currency code for the booking total. |
| createdAt | No | Booking creation timestamp. |
| guestName | No | Primary guest name stored on the booking. |
| updatedAt | No | Last update timestamp for the booking record. |
| guestEmail | No | Primary guest email stored on the booking. |
| propertyId | No | Property UUID associated with the booking. |
| totalPrice | No | Total amount in minor currency units. |
| propertyName | No | Display name of the booked property. |
| reservationId | Yes | Echoed booking or reservation UUID. |
| propertyDomain | No | Host-owned domain associated with the property. |
| cancellationPolicy | No | Host cancellation-policy details applicable to this booking. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint, idempotentHint, and destructiveHint, so the baseline is lower, but the description adds substantial context: read-only against the database, safe to poll after a checkout timeout, returns guest PII, requires Bearer token auth, and is rate-limited per token. It even explains the security behavior of a mismatched reservationId/guestToken pair. No contradiction with annotations.
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?
Despite its length, every sentence earns its place. The definition is front-loaded with purpose, then usage, exclusions, auth, safety, and parameter semantics, with no redundant or filler content. The density is justified by the tool's security-sensitive nature and the need to distinguish it from many siblings.
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?
The description covers the full operational picture: purpose, when to use, when not to use, alternatives, authentication, rate limits, read-only safety, PII exposure, parameter provenance, and failure semantics. Since an output schema exists, the absence of return-format details is not a gap. Nothing an agent needs for correct invocation is missing.
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%, giving a baseline of 3, but the description adds meaning beyond the schema: reservationId is the booking UUID returned by hemmabo_booking_checkout or hemmabo_booking_create and 'never a propertyId,' while guestToken is 'the secret issued with that same booking.' It also states that a mismatched pair reveals nothing, which is critical security semantics not present in the schema.
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?
The opening sentence precisely states the verb, resource, and identifier: 'Retrieve current status and full details of an existing booking by reservationId.' It also explicitly distinguishes the tool from siblings by naming the tools not to use (hemmabo_search_properties, hemmabo_search_availability, hemmabo_booking_quote), leaving no ambiguity about scope.
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?
The description gives concrete when-to-use guidance: 'Use to confirm checkout/create succeeded or before cancel/reschedule.' It also provides explicit exclusions and alternatives, saying 'Do NOT use for property discovery, availability, or pricing — use hemmabo_search_properties, hemmabo_search_availability, or hemmabo_booking_quote for those.' This leaves no inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hemmabo_host_onboarding_linkARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City or municipality (e.g. 'Kävlinge', 'Florence'). Optional; used in onboarding URL prefill when provided. | |
| domain | No | Host-owned domain without protocol or path (e.g. 'villaakerlyckan.se', 'myvilla.it'). Optional; omit when the host has not chosen a domain yet. Invalid: 'https://...', paths, ports, or booking URLs. | |
| region | No | Region or area (e.g. 'Skåne', 'Toscana', 'Marrakech-Safi'). Optional; narrows onboarding handoff and proof examples. | |
| country | No | Country where the property operates (e.g. 'Sweden', 'Italy', 'Morocco'). Optional; improves onboarding URL locale and fit assessment. | |
| language | No | ISO 639-1 language hint for onboarding copy (e.g. 'sv', 'en', 'de', 'fr'). Optional; omit to default to English. | |
| propertyName | No | Property or business display name (e.g. 'Villa Åkerlyckan'). Optional; carried into onboarding URL when provided. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| product | Yes | HemmaBo product, pricing, onboarding URL, and live proof URLs. |
| next_step | Yes | Safe handoff action for the host. |
| setup_items | Yes | Inputs the host should prepare before onboarding. |
| capabilities | Yes | Host-facing capabilities included in HemmaBo. |
| privacy_note | No | Clarifies that the call is read-only and does not store host data. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description amplifies this by listing concrete side effects it does NOT have (no account creation, domain purchase, Stripe config, Supabase writes, or booking-site provisioning) and states that no data is stored server-side. It also discloses the output substance: the URL, what the host gets, and what to prepare.
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?
Each sentence adds a distinct fact—purpose, audience exclusion, readiness-check routing, read-only side-effect exclusions, output components, and prefill semantics. The key action is front-loaded in the first sentence, and the longer parameter caveat is safely placed last.
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?
The tool has an output schema, so return-value detail is already structured, and the description covers audience, timing, alternatives, side-effect profile, and parameter semantics. An agent has everything needed to decide whether to invoke it and what to pass, with no missing prerequisites.
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?
Every parameter is already documented in the schema (100% coverage), and the description adds a crucial group-level semantic: all six are optional prefill that never changes the destination URL; blanks are omitted and nothing is stored. This tells the agent the parameters are cosmetic prefill, which is not inferable from individual schema descriptions.
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?
The description names a specific operation—'Return a safe ... onboarding handoff URL'—with the audience ('host who wants their own booking website') and immediately contrasts with hemmabo_search_properties and hemmabo_host_readiness_check, so the tool is unambiguous against its siblings.
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?
It gives explicit invocation conditions: use 'after explaining the fit or when the host asks to start'; if still evaluating, run hemmabo_host_readiness_check first because it returns the same URL in next_step; guests should use hemmabo_search_properties. This is as explicit as when/when-not guidance gets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hemmabo_host_readiness_checkARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City or municipality (e.g. 'Kävlinge', 'Florence'). Optional; used in onboarding URL prefill when provided. | |
| domain | No | Host-owned domain without protocol or path (e.g. 'villaakerlyckan.se', 'myvilla.it'). Optional; omit when the host has not chosen a domain yet. Invalid: 'https://...', paths, ports, or booking URLs. | |
| region | No | Region or area (e.g. 'Skåne', 'Toscana', 'Marrakech-Safi'). Optional; narrows onboarding handoff and proof examples. | |
| country | No | Country where the property operates (e.g. 'Sweden', 'Italy', 'Morocco'). Optional; improves onboarding URL locale and fit assessment. | |
| hasOwnDomain | No | True if the host already owns a domain or explicitly wants one (e.g. true for 'I have villaakerlyckan.se'). False or omit when still undecided. | |
| propertyName | No | Property or business display name (e.g. 'Villa Åkerlyckan'). Optional; carried into onboarding URL when provided. | |
| propertyType | No | Property category enum. Optional; omit when unknown. 'villa'/'holiday_home' fit best; 'hotel' may indicate a poor HemmaBo fit for large chains. | |
| currentChannels | No | Optional list of channels the host uses today. Omit when unknown. Helps assess migration fit from OTAs to their own booking website. | |
| preferredLanguage | No | ISO 639-1 language hint for onboarding copy (e.g. 'sv', 'en', 'de', 'fr'). Optional; omit to default to English. | |
| wantsAiAgentBooking | No | True if the host wants AI agents (ChatGPT, Claude, Cursor) to discover and book via their own official website. False or omit when they only want a guest website. | |
| wantsDirectPayments | No | True if the host wants Stripe Connect payouts direct to their account. False or omit when they expect HemmaBo to be merchant of record (not supported). |
Output Schema
| Name | Required | Description |
|---|---|---|
| ok | Yes | True when the fit check completed. |
| product | Yes | HemmaBo product summary, pricing, onboarding URL, and live proof URLs. |
| next_step | Yes | Safe handoff action for the host. |
| readiness | Yes | Fit verdict and boundaries for the host's described need. |
| setup_items | Yes | Inputs the host should prepare before onboarding. |
| capabilities | Yes | Host-facing capabilities included in HemmaBo. |
| agent_instruction | Yes | How an AI agent should describe HemmaBo without overclaiming. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive, and the description reinforces and expands on this by listing what it does not do: create an account, buy a domain, configure Stripe, store host data, or provision a website. It also explains the effect of omitting inputs, which is valuable behavioral context beyond the annotations.
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?
The description is dense but every sentence earns its place: purpose, usage boundary, behavioral exclusions, follow-up routing, and parameter impact are all covered without fluff. Key scoping information is front-loaded before parameter details.
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 tool with 11 optional parameters, no required inputs, and a rich schema, the description is remarkably complete. It covers the target user, the boundary against siblings, the non-effects, and the meaningful input semantics, while the output schema handles return-value details.
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?
Although the schema already documents all 11 parameters, the description adds crucial decision-making guidance: only five inputs sharpen the fit verdict, omission of wants* booleans never lowers the verdict, and propertyName/preferredLanguage only prefill the onboarding URL. This goes well beyond the baseline schema descriptions and helps the agent select and prioritize parameters correctly.
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?
The description clearly states a specific purpose: a read-only fit check for vacation-rental hosts evaluating HemmaBo for their own booking website or booking engine. It distinguishes this tool from guest-oriented search by explicitly naming which sibling to use instead.
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?
The description gives explicit when-to-use guidance: use for hosts or property owners, not guests, and points guests to hemmabo_search_properties. It also provides a follow-up action, hemmabo_host_onboarding_link, when the host is ready to start.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hemmabo_search_availabilityARead-onlyIdempotentInspect
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 same-month alternative date windows when unavailable; 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.
| Name | Required | Description | Default |
|---|---|---|---|
| guests | No | Optional guest count (e.g. 4). Omit when only checking date availability without pricing. When provided, alternative date windows in the response include live host-source totals for that guest count. | |
| checkIn | Yes | Arrival date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-15'). Must be today or later in the property's timezone. Must be strictly before checkOut; together they define the stay length used for pricing and availability. | |
| checkOut | Yes | Departure date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-22'). Must be strictly after checkIn on the same calendar. The guest does not stay the departure night. | |
| propertyId | Yes | Stable property UUID from hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000'). Pass the exact UUID string — never a property name, host domain, or booking URL. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present only when isError=true. |
| reason | No | Reason when available=false. |
| checkIn | No | |
| checkOut | No | |
| available | Yes | True if the property is bookable for the entire range. |
| propertyId | No | |
| channel_mirror | No | Outbound channel-manager mirror heartbeat for the host's mapped external channel (status: current|stale|partial|error|not_connected). Informational only — it never affects `available`; the host node is the source of truth for these dates. |
| alternativeDates | No | Nearby same-month date windows to offer when the requested dates are unavailable. |
| calendar_freshness | No | Incoming OTA calendar-sync freshness at answer time. The same object is embedded in the error payload when a stale calendar blocks the call — declared here so agents can treat it as a first-class field in both outcomes. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description adds valuable context beyond those: anonymous access with no Bearer token, rate limiting, no holds or date reservations, fail-closed behavior on stale calendar sync, and alignment with the host node's availability API. No contradiction with annotations.
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?
The description is dense but front-loaded with the core purpose in the first sentence and every subsequent sentence earning its place by covering usage, exclusions, behavior, failure modes, or parameter semantics. Despite its length, it avoids redundancy and reads as a coherent operational guide.
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?
Given that an output schema exists, return-value details need not be spelled out. The description covers when to use, when not to use, authentication, rate-limits, side-effect freedom, parameter-conditional behavior, failure modes, and reliability expectations. Nothing essential for correct invocation is missing.
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% with per-parameter descriptions, and the description adds meaning beyond the schema: omitting guests checks dates only, providing guests gates capacity and prices alternative windows, and min_nights_violation guidance distinguishes extending the stay from shifting dates. It also warns to pass the exact property UUID, not a name or URL.
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?
The description opens with a specific verb and resource: 'Check whether a specific property is available for the requested dates.' It clearly differentiates from siblings by explicitly routing general browsing to hemmabo_search_properties and positioning availability checks before quote creation.
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?
It states exactly when to use the tool: after the user selects a property from hemmabo_search_properties to confirm availability before a quote. It also gives an explicit exclusion: 'Do NOT use for general browsing — use hemmabo_search_properties instead,' leaving no ambiguity about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hemmabo_search_propertiesARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| guests | Yes | Total guest count as a positive integer (e.g. 2, 4, 6). Used for capacity filtering and staircase pricing tiers. Properties with maxGuests below this value are excluded from search results. | |
| region | No | Region, area, or destination to search within (e.g. 'Skåne', 'Kävlinge', 'Toscana', 'Bavaria'). Partial case-insensitive match. Provide at least one of region or country; omit only when country alone is sufficient. | |
| checkIn | Yes | Arrival date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-15'). Must be today or later in the property's timezone. Must be strictly before checkOut; together they define the stay length used for pricing and availability. | |
| country | No | Country name to filter by (e.g. 'Sweden', 'Italy', 'Morocco'). Partial case-insensitive match. Provide at least one of region or country; omit when region already narrows the destination. | |
| checkOut | Yes | Departure date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-22'). Must be strictly after checkIn on the same calendar. The guest does not stay the departure night. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present only when isError=true. |
| guests | No | Echoed guest count. |
| checkIn | No | Echoed check-in date (YYYY-MM-DD). |
| checkOut | No | Echoed check-out date (YYYY-MM-DD). |
| properties | No | Available properties matching the search criteria, with live host-source pricing. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true, but the description adds significant behavioral nuance: 'Discovery only', 'never quote a final price', 'Capacity misses are excluded', and 'date-unavailable matches return separately in unavailableMatches with up to three alternative windows'. These details are not present in annotations and help set agent expectations.
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?
The description is dense but efficient—every sentence carries purpose, front-loaded with purpose and usage. Slightly verbose with overlapping statements ('Discovery only' and 'never quote a final price'), but it remains focused and scannable.
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?
Covers purpose, usage, exclusions, workflow, return content, and parameter interaction. With an output schema and read-only annotations already present, the description provides everything an agent needs to select and invoke this tool correctly.
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%, but the description enriches semantics: it explains how params combine into a single filter, clarifies region vs country matching behavior ('region matches broadly... while country matches the country field alone'), and documents the effect of omitting both ('search spans every published property'). This goes well beyond the schema descriptions.
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?
States a specific verb and resource: 'Search available vacation rental properties by location and travel dates.' It also differentiates from siblings by defining the exact use case ('find or browse places to stay') and explicitly routing away when a propertyId or host domain already exists.
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?
Provides explicit when-to-use ('Use when the user wants to find or browse places to stay'), when-not-to-use ('Do NOT use when the user already has a propertyId or host domain'), and a workflow directive (call get_verified_stay_offer before final answer, never quote price from search alone). This gives an agent unambiguous decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_vacation_rental_nodeARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Host-owned domain without protocol or path (e.g. 'villaakerlyckan.se', 'myvilla.it'). Invalid: 'https://...', paths, ports, or booking URLs. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when verified=false or the node cannot be checked. |
| domain | Yes | Echoed canonical host domain that was checked. |
| signing | No | Summary of accepted signing algorithms, key ids, and signing-key checks. |
| jwks_url | No | Host-domain JWKS URL containing the Ed25519 public keys used to verify signed offers. |
| protocol | No | Protocol identifier discovered on the host domain. A valid node declares exactly 'vacation-rental-protocol' in its .well-known/vacation-rental.json protocol field, and that is the value returned here. |
| verified | Yes | True only when discovery, JWKS, signing metadata, and verified-offer endpoint checks pass. |
| discovery_url | No | The .well-known vacation-rental discovery URL read from the host domain. |
| protocol_version | No | VRP version declared by the host discovery document. |
| verified_stay_offer_url | No | Host-domain endpoint template or URL used to request signed verified stay offers. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, so the bar is lower, yet the description still adds real behavioral context: reads .well-known/vacation-rental.json and JWKS, refuses IPs/ports/local/private hostnames, treats www and apex as distinct identities, fails when canonical_domain mismatches, and warns that results are only as trustworthy as the exact domain passed. No contradiction with annotations.
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?
The description is long but every sentence earns its place — purpose, mechanism, exclusions, when-to-use, follow-up action, input constraints, edge cases, and trust caveat. It is front-loaded with the core purpose and the critical do-not-use warning.
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?
With one parameter, high schema coverage, an output schema, and safety annotations, the description fills every remaining gap an agent needs: input format, eligibility constraints, failure-prone identity nuances, chaining guidance, and a trust-reliability caveat. Nothing essential is missing.
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?
Even though schema coverage is 100%, the description adds meaning the schema lacks: public-domain-only restriction, explicit refusal of IPs/ports/local hostnames, the www-vs-apex identity distinction, and the canonical_domain matching requirement with its failure mode. This goes well beyond the schema's bare-hostname constraint.
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?
States a specific verb ('Verify'), a precise resource (vacation-rental host domain as a VRP node), and the intent ('before trusting it'). It differentiates from siblings by explicitly excluding availability, pricing, booking, and payment, and by naming the separate flow for hemmabo_search_properties results leading to get_verified_stay_offer.
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?
Gives an explicit when-to-use trigger ('host domain arrives from outside search — user-typed or third-party'), an explicit when-not-to-use ('do NOT use it to answer those questions'), and names the alternative path (search results go straight to get_verified_stay_offer). It even chains the follow-up action on success.
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.
3 tool updates
v4.0.9- Changed
get_verified_stay_offer1 field changed- changed
Input schema / properties / domain / descriptionPrevious value: -"Host-owned domain without protocol or path (e.g. 'villaakerlyckan.se', 'myvilla.it'). Optional; omit when the host has not chosen a domain yet. Invalid: 'https://...', paths, ports, or booking URLs."New value: +"Host-owned domain without protocol or path (e.g. 'villaakerlyckan.se', 'myvilla.it'). Invalid: 'https://...', paths, ports, or booking URLs."
- Changed
hemmabo_host_readiness_check2 fields changed- changed
Output schema / properties / product / properties / price / properties / amount / descriptionPrevious value: -"Monthly subscription price in major currency units (e.g. 399)."New value: +"Monthly subscription price in major currency units (e.g. 39)." - changed
Output schema / properties / product / properties / price / properties / currency / descriptionPrevious value: -"ISO 4217 currency code (e.g. 'SEK')."New value: +"ISO 4217 currency code (e.g. 'USD')."
- Changed
verify_vacation_rental_node2 fields changed- changed
Input schema / properties / domain / descriptionPrevious value: -"Host-owned domain without protocol or path (e.g. 'villaakerlyckan.se', 'myvilla.it'). Optional; omit when the host has not chosen a domain yet. Invalid: 'https://...', paths, ports, or booking URLs."New value: +"Host-owned domain without protocol or path (e.g. 'villaakerlyckan.se', 'myvilla.it'). Invalid: 'https://...', paths, ports, or booking URLs." - changed
Output schema / properties / protocol / descriptionPrevious value: -"Protocol identifier discovered on the host domain, typically 'vrp'."New value: +"Protocol identifier discovered on the host domain. A valid node declares exactly 'vacation-rental-protocol' in its .well-known/vacation-rental.json protocol field, and that is the value returned here."
5 tool updates
v4.0.5- Changed
hemmabo_booking_cancel2 fields changed- added
Input schema / properties / guestTokenAdded value: +{ + "description": "Per-booking secret returned by hemmabo_booking_create / hemmabo_booking_checkout (the booking's guest_token, a UUID). Required to view or modify this specific booking — a valid Bearer token alone is NOT sufficient, because it authenticates the caller but grants no authority over any particular booking. Present the exact guestToken you received when the booking was created; without the matching value the call is refused. Never a propertyId or reservationId.", + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "reservationId" -]New value: +[ + "reservationId", + "guestToken" +]
- Changed
hemmabo_booking_checkout1 field changed- added
Output schema / properties / guestTokenAdded value: +{ + "description": "Per-booking secret (guest_token) for this booking. Present it back as guestToken on hemmabo_booking_status / hemmabo_booking_cancel / hemmabo_booking_reschedule to view or modify this booking; a Bearer token alone is not sufficient. Store it securely and do not show it to the guest.", + "type": "string" +}
- Changed
hemmabo_booking_create1 field changed- added
Output schema / properties / guestTokenAdded value: +{ + "description": "Per-booking secret (guest_token) for this booking. Present it back as guestToken on hemmabo_booking_status / hemmabo_booking_cancel / hemmabo_booking_reschedule to view or modify this booking; a Bearer token alone is not sufficient. Store it securely and do not show it to the guest.", + "type": "string" +}
- Changed
hemmabo_booking_reschedule2 fields changed- added
Input schema / properties / guestTokenAdded value: +{ + "description": "Per-booking secret returned by hemmabo_booking_create / hemmabo_booking_checkout (the booking's guest_token, a UUID). Required to view or modify this specific booking — a valid Bearer token alone is NOT sufficient, because it authenticates the caller but grants no authority over any particular booking. Present the exact guestToken you received when the booking was created; without the matching value the call is refused. Never a propertyId or reservationId.", + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "reservationId", - "newCheckIn", - "newCheckOut" -]New value: +[ + "reservationId", + "guestToken", + "newCheckIn", + "newCheckOut" +]
- Changed
hemmabo_booking_status2 fields changed- added
Input schema / properties / guestTokenAdded value: +{ + "description": "Per-booking secret returned by hemmabo_booking_create / hemmabo_booking_checkout (the booking's guest_token, a UUID). Required to view or modify this specific booking — a valid Bearer token alone is NOT sufficient, because it authenticates the caller but grants no authority over any particular booking. Present the exact guestToken you received when the booking was created; without the matching value the call is refused. Never a propertyId or reservationId.", + "type": "string" +} - changed
Input schema / requiredPrevious value: -[ - "reservationId" -]New value: +[ + "reservationId", + "guestToken" +]
2 tool updates
v0.1.12- Changed
hemmabo_booking_create2 fields changed- added
Output schema / properties / calendar_freshnessAdded value: +{ + "additionalProperties": true, + "description": "Incoming OTA calendar-sync freshness at booking time. The same object is embedded in the error payload when a stale calendar blocks the call — declared here so agents can treat it as a first-class field in both outcomes.", + "type": "object" +} - added
Output schema / properties / channel_mirrorAdded value: +{ + "additionalProperties": true, + "description": "Outbound channel-manager mirror heartbeat for the host's mapped external channel (status: current|stale|partial|error|not_connected). Informational only — it never affects availability or this booking; the host node is the source of truth.", + "type": "object" +}
- Changed
hemmabo_search_availability2 fields changed- added
Output schema / properties / calendar_freshnessAdded value: +{ + "additionalProperties": true, + "description": "Incoming OTA calendar-sync freshness at answer time. The same object is embedded in the error payload when a stale calendar blocks the call — declared here so agents can treat it as a first-class field in both outcomes.", + "type": "object" +} - added
Output schema / properties / channel_mirrorAdded value: +{ + "additionalProperties": true, + "description": "Outbound channel-manager mirror heartbeat for the host's mapped external channel (status: current|stale|partial|error|not_connected). Informational only — it never affects `available`; the host node is the source of truth for these dates.", + "type": "object" +}
5 tool updates
v0.1.11- Changed
get_verified_stay_offer1 field changed- changed
Input schema / properties / language / descriptionPrevious value: -"Optional BCP-47 language tag for labels and formatting (e.g. 'en', 'sv', 'de', 'sv-SE'). Omit to use host default; does not change price or availability."New value: +"The guest's conversation language, as a BCP-47 tag (e.g. 'en', 'sv', 'de', 'sv-SE') — ALWAYS pass this, matching the language the guest is chatting in, so the rendered widget's labels, dates and currency formatting match the guest instead of falling back to the rendering client's own locale (which can silently disagree with the conversation). Never changes the signed price value or availability — only how it is displayed."
- Removed
hemmabo_compare_properties - Changed
hemmabo_host_readiness_check2 fields changed- changed
Input schema / properties / currentChannels / descriptionPrevious value: -"Optional list of channels the host uses today. Omit when unknown. Helps assess migration fit from OTAs to own-domain booking."New value: +"Optional list of channels the host uses today. Omit when unknown. Helps assess migration fit from OTAs to their own booking website." - changed
Input schema / properties / wantsAiAgentBooking / descriptionPrevious value: -"True if the host wants AI agents (ChatGPT, Claude, Cursor) to discover and book via their own domain. False or omit when they only want a guest website."New value: +"True if the host wants AI agents (ChatGPT, Claude, Cursor) to discover and book via their own official website. False or omit when they only want a guest website."
- Changed
hemmabo_search_properties1 field changed- changed
Output schema / properties / properties / items / properties / signals / descriptionPrevious value: -"Optional. Host-declared canonical discovery flags for matching requests like dog-friendly, hot tub, crib, or hen party. Grouped: amenities / policies / suitability / setting (arrays of canonical English keys, e.g. 'allows_dogs', 'has_hot_tub', 'crib_available', 'bachelorette_party_friendly') plus bestForOccasions / targetAudience. Canonical keys — render them in the user's language. Match signals, not verified guarantees: the signed verified-stay-offer and the property page are authoritative; absence of a flag means 'not detected', not 'no'."New value: +"Optional. Host-declared canonical discovery flags for matching requests like dog-friendly, hot tub, crib, or hen party. Grouped: amenities / policies / suitability / setting (arrays of canonical English keys, e.g. 'allows_dogs', 'has_hot_tub', 'crib_available', 'bachelorette_party_friendly') plus bestForOccasions / targetAudience, plus policies_negated: the host's EXPLICIT NOs from the claims ledger (e.g. 'pets_cats' there means cats are not allowed — relay as a clear, friendly no). Canonical keys — render them in the user's language. Match signals, not verified guarantees: the signed verified-stay-offer and the property page are authoritative; absence of a flag from both the affirmed groups and policies_negated means UNKNOWN, not 'no' — recommend asking the host."
- Removed
hemmabo_search_similar
15 tool updates
v0.1.6- Changed
get_verified_stay_offer9 fields changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / checkInAdded value: +{ + "description": "Requested arrival date in YYYY-MM-DD format (e.g. '2026-11-14'). Must be strictly before checkOut. Use the same dates the guest requested in search.", + "pattern": "^\\d{4}-\\d{2}-\\d{2}$", + "type": "string" +} - added
Input schema / properties / checkOutAdded value: +{ + "description": "Requested departure date in YYYY-MM-DD format (e.g. '2026-11-17'). Must be strictly after checkIn. Guest does not stay the departure night.", + "pattern": "^\\d{4}-\\d{2}-\\d{2}$", + "type": "string" +} - removed
Input schema / properties / check_inRemoved value: -{ - "description": "Requested arrival date in YYYY-MM-DD format (e.g. '2026-11-14'). Must be strictly before check_out. Use the same dates the guest requested in search.", - "pattern": "^\\d{4}-\\d{2}-\\d{2}$", - "type": "string" -} - removed
Input schema / properties / check_outRemoved value: -{ - "description": "Requested departure date in YYYY-MM-DD format (e.g. '2026-11-17'). Must be strictly after check_in. Guest does not stay the departure night.", - "pattern": "^\\d{4}-\\d{2}-\\d{2}$", - "type": "string" -} - removed
Input schema / properties / guests / maximumRemoved value: -9007199254740991 - changed
Input schema / requiredPrevious value: -[ - "domain", - "check_in", - "check_out", - "guests" -]New value: +[ + "domain", + "checkIn", + "checkOut", + "guests" +] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "agent_citation": { + "additionalProperties": true, + "description": "Citation permission and safe-to-quote status derived from the signed offer.", + "type": "object" + }, + "agent_guardrails": { + "additionalProperties": true, + "description": "Rules the agent must follow when presenting or acting on this offer.", + "type": "object" + }, + "checkIn": { + "description": "Echoed requested arrival date.", + "type": "string" + }, + "checkOut": { + "description": "Echoed requested departure date.", + "type": "string" + }, + "domain": { + "description": "Echoed host domain that issued the signed offer.", + "type": "string" + }, + "error": { + "type": "string" + }, + "fresh": { + "description": "True when the signed offer is still within its validity/freshness window.", + "type": "boolean" + }, + "guests": { + "description": "Echoed requested guest count.", + "type": "integer" + }, + "official_offer_summary": { + "additionalProperties": true, + "description": "Small signed-offer summary for agents to quote without inventing price, availability, discounts, savings, comparisons, or booking details.", + "type": "object" + }, + "payload_matches_offer": { + "description": "True when the signed payload matches the structured offer returned to the agent.", + "type": "boolean" + }, + "signature": { + "additionalProperties": true, + "description": "Ed25519/JWS verification details, including key id and verification status.", + "type": "object" + }, + "verified": { + "description": "True only when the host-domain offer signature and payload checks pass.", + "type": "boolean" + }, + "widget_media": { + "additionalProperties": true, + "description": "Images and media hydrated from the verified host discovery document for the ChatGPT widget.", + "type": "object" + } + }, + "required": [ + "domain", + "verified" + ], + "type": "object" +}
- Changed
hemmabo_booking_cancel4 fields changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false - removed
Input schema / properties / reservationId / patternRemoved value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "error": { + "description": "Present only when isError=true.", + "type": "string" + }, + "refund": { + "additionalProperties": true, + "description": "Refund payload returned by cancel-booking edge function, when present.", + "type": "object" + }, + "reservationId": { + "format": "uuid", + "type": "string" + }, + "status": { + "description": "Final booking status after cancellation.", + "enum": [ + "cancelled" + ], + "type": "string" + } + }, + "required": [ + "reservationId", + "status" + ], + "type": "object" +}
- Changed
hemmabo_booking_checkout6 fields changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false - removed
Input schema / properties / guestEmail / patternRemoved value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$" - removed
Input schema / properties / guests / maximumRemoved value: -9007199254740991 - removed
Input schema / properties / propertyId / patternRemoved value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "checkIn": { + "type": "string" + }, + "checkOut": { + "type": "string" + }, + "createdAt": { + "format": "date-time", + "type": "string" + }, + "currency": { + "type": "string" + }, + "error": { + "description": "Present only when isError=true.", + "type": "string" + }, + "guests": { + "type": "integer" + }, + "mpp": { + "additionalProperties": true, + "description": "Present when paymentMode='payment_intent'.", + "type": "object" + }, + "nights": { + "type": "integer" + }, + "paymentUrl": { + "description": "Stripe Checkout redirect URL.", + "format": "uri", + "type": "string" + }, + "payment_modes": { + "description": "Supported payment modes.", + "items": { + "type": "string" + }, + "type": "array" + }, + "propertyId": { + "format": "uuid", + "type": "string" + }, + "reservationId": { + "description": "Booking UUID. Use for subsequent status/cancel/reschedule calls.", + "format": "uuid", + "type": "string" + }, + "status": { + "description": "Booking status (typically 'pending' until payment succeeds).", + "type": "string" + }, + "totalPrice": { + "description": "Final total charged (or to be charged), in minor currency units.", + "type": "integer" + } + }, + "required": [ + "reservationId", + "totalPrice", + "currency" + ], + "type": "object" +}
- Changed
hemmabo_booking_create6 fields changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false - removed
Input schema / properties / guestEmail / patternRemoved value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$" - removed
Input schema / properties / guests / maximumRemoved value: -9007199254740991 - removed
Input schema / properties / propertyId / patternRemoved value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "bookingId": { + "description": "Persistent booking UUID. Use for status/cancel/reschedule.", + "format": "uuid", + "type": "string" + }, + "checkIn": { + "type": "string" + }, + "checkOut": { + "type": "string" + }, + "createdAt": { + "format": "date-time", + "type": "string" + }, + "currency": { + "type": "string" + }, + "error": { + "description": "Present only when isError=true.", + "type": "string" + }, + "federationDiscountPercent": { + "type": "integer" + }, + "gapDiscountPercent": { + "type": "integer" + }, + "guests": { + "type": "integer" + }, + "nights": { + "type": "integer" + }, + "packageApplied": { + "type": "string" + }, + "priceType": { + "description": "Pricing mode used (federation/gap_night/package_*).", + "type": "string" + }, + "propertyId": { + "format": "uuid", + "type": "string" + }, + "status": { + "description": "Host-node booking status. 'completed' is a protocol compatibility output only, not a status this tool writes.", + "enum": [ + "pending", + "confirmed", + "cancelled", + "completed" + ], + "type": "string" + }, + "totalPrice": { + "description": "Final price written to the booking.", + "type": "integer" + } + }, + "required": [ + "bookingId", + "status" + ], + "type": "object" +}
- Changed
hemmabo_booking_negotiate5 fields changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false - removed
Input schema / properties / guests / maximumRemoved value: -9007199254740991 - removed
Input schema / properties / propertyId / patternRemoved value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "breakdown": { + "additionalProperties": true, + "type": "object" + }, + "checkIn": { + "type": "string" + }, + "checkOut": { + "type": "string" + }, + "currency": { + "type": "string" + }, + "error": { + "description": "Present only when isError=true.", + "type": "string" + }, + "federationDiscountPercent": { + "type": "integer" + }, + "federationTotal": { + "type": "integer" + }, + "gapDiscountPercent": { + "type": "integer" + }, + "gapNight": { + "type": "boolean" + }, + "gapTotal": { + "type": "integer" + }, + "guests": { + "type": "integer" + }, + "nights": { + "type": "integer" + }, + "packageApplied": { + "type": "string" + }, + "propertyId": { + "format": "uuid", + "type": "string" + }, + "publicTotal": { + "type": "integer" + }, + "quoteId": { + "description": "Snapshot ID. Pass to hemmabo_booking_checkout to lock this price.", + "type": "string" + }, + "validUntil": { + "description": "Quote expiry (ISO 8601). Typically 15 minutes after creation.", + "format": "date-time", + "type": "string" + } + }, + "required": [ + "quoteId", + "validUntil", + "federationTotal" + ], + "type": "object" +}
- Changed
hemmabo_booking_quote5 fields changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false - removed
Input schema / properties / guests / maximumRemoved value: -9007199254740991 - removed
Input schema / properties / propertyId / patternRemoved value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "breakdown": { + "additionalProperties": true, + "description": "Detailed pricing breakdown.", + "type": "object" + }, + "checkIn": { + "type": "string" + }, + "checkOut": { + "type": "string" + }, + "currency": { + "description": "ISO 4217 currency code.", + "type": "string" + }, + "directBookingDiscountPercent": { + "description": "Legacy internal field. Do not present this as a guest-facing discount, savings, or comparison.", + "type": "integer" + }, + "directBookingTotal": { + "description": "Preferred user-facing field: direct host-source total.", + "type": "integer" + }, + "error": { + "description": "Present only when isError=true.", + "type": "string" + }, + "federationDiscountPercent": { + "description": "Legacy internal field. Do not present this as a guest-facing discount, savings, or comparison.", + "type": "integer" + }, + "federationTotal": { + "description": "Legacy field: direct host-source total. Prefer directBookingTotal in user-facing copy.", + "type": "integer" + }, + "gapDiscountPercent": { + "description": "Gap-night discount percentage when applied.", + "type": "integer" + }, + "gapNight": { + "description": "True when the stay qualifies as a gap fill.", + "type": "boolean" + }, + "gapTotal": { + "description": "Gap-night adjusted total when applicable; otherwise null.", + "type": "integer" + }, + "guests": { + "type": "integer" + }, + "hostSourcePublicTotal": { + "description": "Preferred user-facing field: public host-source total.", + "type": "integer" + }, + "nights": { + "description": "Number of nights in the range.", + "type": "integer" + }, + "packageApplied": { + "description": "Applied package, if any.", + "type": "string" + }, + "propertyId": { + "format": "uuid", + "type": "string" + }, + "publicTotal": { + "description": "Website rate total in minor currency units.", + "type": "integer" + } + }, + "type": "object" +}
- Changed
hemmabo_booking_reschedule4 fields changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false - removed
Input schema / properties / reservationId / patternRemoved value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "error": { + "description": "Present only when isError=true.", + "type": "string" + }, + "newDates": { + "additionalProperties": true, + "properties": { + "checkIn": { + "type": "string" + }, + "checkOut": { + "type": "string" + } + }, + "type": "object" + }, + "previousDates": { + "additionalProperties": true, + "properties": { + "checkIn": { + "type": "string" + }, + "checkOut": { + "type": "string" + } + }, + "type": "object" + }, + "pricing": { + "additionalProperties": true, + "properties": { + "currency": { + "type": "string" + }, + "delta": { + "type": "integer" + }, + "newPrice": { + "type": "integer" + }, + "previousPrice": { + "type": "integer" + }, + "stripeAction": { + "additionalProperties": true, + "type": "object" + } + }, + "type": "object" + }, + "reason": { + "type": "string" + }, + "reservationId": { + "format": "uuid", + "type": "string" + }, + "status": { + "description": "Booking status after reschedule.", + "type": "string" + } + }, + "required": [ + "reservationId", + "status" + ], + "type": "object" +}
- Changed
hemmabo_booking_status4 fields changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false - removed
Input schema / properties / reservationId / patternRemoved value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "cancellationPolicy": { + "additionalProperties": true, + "description": "Host cancellation-policy details applicable to this booking.", + "type": "object" + }, + "checkIn": { + "description": "Booked arrival date.", + "type": "string" + }, + "checkOut": { + "description": "Booked departure date.", + "type": "string" + }, + "createdAt": { + "description": "Booking creation timestamp.", + "format": "date-time", + "type": "string" + }, + "currency": { + "description": "ISO 4217 currency code for the booking total.", + "type": "string" + }, + "error": { + "description": "Present only when isError=true.", + "type": "string" + }, + "guestEmail": { + "description": "Primary guest email stored on the booking.", + "type": "string" + }, + "guestName": { + "description": "Primary guest name stored on the booking.", + "type": "string" + }, + "guests": { + "description": "Booked guest count.", + "type": "integer" + }, + "propertyDomain": { + "description": "Host-owned domain associated with the property.", + "type": "string" + }, + "propertyId": { + "description": "Property UUID associated with the booking.", + "format": "uuid", + "type": "string" + }, + "propertyName": { + "description": "Display name of the booked property.", + "type": "string" + }, + "reservationId": { + "description": "Echoed booking or reservation UUID.", + "format": "uuid", + "type": "string" + }, + "status": { + "description": "Host-node booking status. 'completed' is a protocol compatibility output only, not the active lifecycle truth.", + "enum": [ + "pending", + "confirmed", + "cancelled", + "completed" + ], + "type": "string" + }, + "totalPrice": { + "description": "Total amount in minor currency units.", + "type": "integer" + }, + "updatedAt": { + "description": "Last update timestamp for the booking record.", + "format": "date-time", + "type": "string" + } + }, + "required": [ + "reservationId", + "status" + ], + "type": "object" +}
- Changed
hemmabo_compare_properties5 fields changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false - removed
Input schema / properties / guests / maximumRemoved value: -9007199254740991 - removed
Input schema / properties / propertyIds / items / patternRemoved value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "checkIn": { + "type": "string" + }, + "checkOut": { + "type": "string" + }, + "comparison": { + "description": "One entry per requested propertyId, sorted by direct host-source total (cheapest first), unavailable last.", + "items": { + "additionalProperties": true, + "properties": { + "available": { + "type": "boolean" + }, + "city": { + "type": "string" + }, + "country": { + "type": "string" + }, + "currency": { + "type": "string" + }, + "domain": { + "type": "string" + }, + "error": { + "description": "Error detail for this property when present.", + "type": "string" + }, + "federationDiscountPercent": { + "type": "integer" + }, + "federationTotal": { + "description": "Legacy field: direct host-source total. Absent if unavailable.", + "type": "integer" + }, + "gapTotal": { + "type": "integer" + }, + "maxGuests": { + "type": "integer" + }, + "name": { + "type": "string" + }, + "nights": { + "type": "integer" + }, + "packageApplied": { + "type": "string" + }, + "propertyId": { + "format": "uuid", + "type": "string" + }, + "propertyType": { + "type": "string" + }, + "publicTotal": { + "description": "Standard website total. Absent if unavailable.", + "type": "integer" + }, + "reason": { + "description": "Availability reason object when unavailable.", + "type": "object" + }, + "region": { + "type": "string" + } + }, + "required": [ + "propertyId", + "available" + ], + "type": "object" + }, + "type": "array" + }, + "count": { + "description": "Number of compared properties returned.", + "type": "integer" + }, + "error": { + "description": "Present only when isError=true.", + "type": "string" + }, + "guests": { + "type": "integer" + } + }, + "type": "object" +}
- Changed
hemmabo_host_onboarding_link4 fields changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / requiredAdded value: +[] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "capabilities": { + "description": "Host-facing capabilities included in HemmaBo.", + "items": { + "type": "string" + }, + "type": "array" + }, + "next_step": { + "additionalProperties": true, + "description": "Safe handoff action for the host.", + "type": "object" + }, + "ok": { + "type": "boolean" + }, + "privacy_note": { + "description": "Clarifies that the call is read-only and does not store host data.", + "type": "string" + }, + "product": { + "additionalProperties": true, + "description": "HemmaBo product, pricing, onboarding URL, and live proof URLs.", + "type": "object" + }, + "setup_items": { + "description": "Inputs the host should prepare before onboarding.", + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "ok", + "product", + "capabilities", + "setup_items", + "next_step" + ], + "type": "object" +}
- Changed
hemmabo_host_readiness_check4 fields changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / requiredAdded value: +[] - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "agent_instruction": { + "description": "How an AI agent should describe HemmaBo without overclaiming.", + "type": "string" + }, + "capabilities": { + "description": "Host-facing capabilities included in HemmaBo.", + "items": { + "type": "string" + }, + "type": "array" + }, + "next_step": { + "additionalProperties": true, + "description": "Safe handoff action for the host.", + "properties": { + "action": { + "description": "Recommended next action.", + "enum": [ + "open_onboarding" + ], + "type": "string" + }, + "label": { + "description": "Human-readable label for the action.", + "type": "string" + }, + "url": { + "description": "Onboarding handoff URL to open.", + "format": "uri", + "type": "string" + } + }, + "type": "object" + }, + "ok": { + "description": "True when the fit check completed.", + "type": "boolean" + }, + "product": { + "additionalProperties": true, + "description": "HemmaBo product summary, pricing, onboarding URL, and live proof URLs.", + "properties": { + "category": { + "description": "Product category, e.g. 'host-owned booking engine for vacation rentals'.", + "type": "string" + }, + "live_proof_url": { + "description": "Live AI-agent booking proof page on hemmabo.com.", + "format": "uri", + "type": "string" + }, + "live_reference_domain": { + "description": "Live reference host-node domain to show the model in action.", + "format": "uri", + "type": "string" + }, + "name": { + "description": "Product name ('HemmaBo').", + "type": "string" + }, + "onboarding_url": { + "description": "Prefilled host onboarding handoff URL (utm-tagged; carries any property/location/domain/language the host provided).", + "format": "uri", + "type": "string" + }, + "price": { + "additionalProperties": true, + "description": "Subscription pricing for the host.", + "properties": { + "amount": { + "description": "Monthly subscription price in major currency units (e.g. 399).", + "type": "integer" + }, + "currency": { + "description": "ISO 4217 currency code (e.g. 'SEK').", + "type": "string" + }, + "first_month_free": { + "description": "True when the first month is free.", + "type": "boolean" + }, + "hemmabo_booking_commission_percent": { + "description": "HemmaBo booking commission percent. 0 — HemmaBo takes no booking commission.", + "type": "integer" + }, + "interval": { + "description": "Billing interval (e.g. 'month').", + "type": "string" + } + }, + "type": "object" + }, + "website": { + "description": "HemmaBo marketing site URL.", + "format": "uri", + "type": "string" + } + }, + "type": "object" + }, + "readiness": { + "additionalProperties": true, + "description": "Fit verdict and boundaries for the host's described need.", + "properties": { + "fit": { + "description": "Overall fit verdict derived from the inputs the host provided.", + "enum": [ + "strong_fit", + "possible_fit", + "needs_more_host_context" + ], + "type": "string" + }, + "not_a_fit_when": { + "description": "Situations where HemmaBo is not the right tool.", + "items": { + "type": "string" + }, + "type": "array" + }, + "product_category": { + "description": "Plain-language product category.", + "type": "string" + }, + "recommended_when": { + "description": "Situations where HemmaBo is a good fit.", + "items": { + "type": "string" + }, + "type": "array" + } + }, + "type": "object" + }, + "setup_items": { + "description": "Inputs the host should prepare before onboarding.", + "items": { + "type": "string" + }, + "type": "array" + } + }, + "required": [ + "ok", + "product", + "readiness", + "capabilities", + "setup_items", + "next_step", + "agent_instruction" + ], + "type": "object" +}
- Changed
hemmabo_search_availability5 fields changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false - removed
Input schema / properties / guests / maximumRemoved value: -9007199254740991 - removed
Input schema / properties / propertyId / patternRemoved value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "alternativeDates": { + "description": "Nearby same-month date windows to offer when the requested dates are unavailable.", + "items": { + "additionalProperties": true, + "properties": { + "available": { + "type": "boolean" + }, + "checkIn": { + "type": "string" + }, + "checkOut": { + "type": "string" + }, + "currency": { + "type": "string" + }, + "federationDiscountPercent": { + "type": "number" + }, + "federationTotal": { + "type": "number" + }, + "publicTotal": { + "type": "number" + } + }, + "type": "object" + }, + "type": "array" + }, + "available": { + "description": "True if the property is bookable for the entire range.", + "type": "boolean" + }, + "checkIn": { + "type": "string" + }, + "checkOut": { + "type": "string" + }, + "error": { + "description": "Present only when isError=true.", + "type": "string" + }, + "propertyId": { + "format": "uuid", + "type": "string" + }, + "reason": { + "description": "Reason when available=false.", + "type": "string" + } + }, + "required": [ + "available" + ], + "type": "object" +}
- Changed
hemmabo_search_properties4 fields changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false - removed
Input schema / properties / guests / maximumRemoved value: -9007199254740991 - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "checkIn": { + "description": "Echoed check-in date (YYYY-MM-DD).", + "type": "string" + }, + "checkOut": { + "description": "Echoed check-out date (YYYY-MM-DD).", + "type": "string" + }, + "error": { + "description": "Present only when isError=true.", + "type": "string" + }, + "guests": { + "description": "Echoed guest count.", + "type": "integer" + }, + "properties": { + "description": "Available properties matching the search criteria, with live host-source pricing.", + "items": { + "additionalProperties": true, + "properties": { + "available": { + "description": "Always true in search results because unavailable properties are filtered out.", + "type": "boolean" + }, + "city": { + "description": "City or locality.", + "type": "string" + }, + "country": { + "description": "Country.", + "type": "string" + }, + "currency": { + "description": "ISO 4217 currency code (e.g. 'SEK', 'EUR').", + "type": "string" + }, + "directBookingDiscountPercent": { + "description": "Legacy internal field. Do not present this as a guest-facing discount, savings, or comparison.", + "type": "integer" + }, + "directBookingTotal": { + "description": "Preferred field for user-facing copy: direct host-source total, in minor currency units.", + "type": "integer" + }, + "domain": { + "description": "Host-owned domain for this property.", + "type": "string" + }, + "federationDiscountPercent": { + "description": "Legacy internal field. Do not present this as a guest-facing discount, savings, or comparison.", + "type": "integer" + }, + "federationTotal": { + "description": "Legacy field: direct host-source total, in minor currency units. Do not label this as a HemmaBo platform, federation, OTA, marketplace, comparison, discount, or savings price in user-facing copy.", + "type": "integer" + }, + "hostSourcePublicTotal": { + "description": "Preferred field for user-facing copy: public host-source total for the date range, in minor currency units.", + "type": "integer" + }, + "maxGuests": { + "description": "Maximum guest capacity.", + "type": "integer" + }, + "name": { + "description": "Property display name.", + "type": "string" + }, + "nights": { + "description": "Number of nights between check-in and check-out.", + "type": "integer" + }, + "packageApplied": { + "description": "Package applied (e.g. week or two_weeks), if any.", + "type": "string" + }, + "propertyId": { + "description": "Stable UUID. Pass to subsequent tools (availability, quote, checkout).", + "format": "uuid", + "type": "string" + }, + "propertyType": { + "description": "Property type classification.", + "type": "string" + }, + "publicTotal": { + "description": "Standard website total for the date range, in minor currency units.", + "type": "integer" + }, + "region": { + "description": "Region or area.", + "type": "string" + }, + "signals": { + "additionalProperties": true, + "description": "Optional. Host-declared canonical discovery flags for matching requests like dog-friendly, hot tub, crib, or hen party. Grouped: amenities / policies / suitability / setting (arrays of canonical English keys, e.g. 'allows_dogs', 'has_hot_tub', 'crib_available', 'bachelorette_party_friendly') plus bestForOccasions / targetAudience. Canonical keys — render them in the user's language. Match signals, not verified guarantees: the signed verified-stay-offer and the property page are authoritative; absence of a flag means 'not detected', not 'no'.", + "type": "object" + } + }, + "required": [ + "propertyId", + "name", + "maxGuests", + "federationTotal" + ], + "type": "object" + }, + "type": "array" + } + }, + "type": "object" +}
- Changed
hemmabo_search_similar5 fields changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false - removed
Input schema / properties / guests / maximumRemoved value: -9007199254740991 - removed
Input schema / properties / propertyId / patternRemoved value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "checkIn": { + "type": "string" + }, + "checkOut": { + "type": "string" + }, + "count": { + "description": "Number of similar properties returned.", + "type": "integer" + }, + "error": { + "description": "Present only when isError=true.", + "type": "string" + }, + "guests": { + "description": "Effective guest count used for matching and pricing.", + "type": "integer" + }, + "similarProperties": { + "description": "Similar available properties (same region, same type, same/larger capacity), sorted by direct host-source total.", + "items": { + "additionalProperties": true, + "properties": { + "available": { + "type": "boolean" + }, + "city": { + "type": "string" + }, + "country": { + "type": "string" + }, + "currency": { + "type": "string" + }, + "domain": { + "type": "string" + }, + "federationDiscountPercent": { + "type": "integer" + }, + "federationTotal": { + "type": "integer" + }, + "maxGuests": { + "type": "integer" + }, + "name": { + "type": "string" + }, + "nights": { + "type": "integer" + }, + "packageApplied": { + "type": "string" + }, + "propertyId": { + "format": "uuid", + "type": "string" + }, + "propertyType": { + "type": "string" + }, + "publicTotal": { + "type": "integer" + }, + "region": { + "type": "string" + } + }, + "required": [ + "propertyId", + "federationTotal" + ], + "type": "object" + }, + "type": "array" + }, + "sourcePropertyId": { + "description": "The property similar listings were found for.", + "format": "uuid", + "type": "string" + } + }, + "type": "object" +}
- Changed
verify_vacation_rental_node3 fields changed- removed
Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / (root)Previous value: -nullNew value: +{ + "additionalProperties": true, + "properties": { + "discovery_url": { + "description": "The .well-known vacation-rental discovery URL read from the host domain.", + "format": "uri", + "type": "string" + }, + "domain": { + "description": "Echoed canonical host domain that was checked.", + "type": "string" + }, + "error": { + "description": "Present when verified=false or the node cannot be checked.", + "type": "string" + }, + "jwks_url": { + "description": "Host-domain JWKS URL containing the Ed25519 public keys used to verify signed offers.", + "format": "uri", + "type": "string" + }, + "protocol": { + "description": "Protocol identifier discovered on the host domain, typically 'vrp'.", + "type": "string" + }, + "protocol_version": { + "description": "VRP version declared by the host discovery document.", + "type": "string" + }, + "signing": { + "additionalProperties": true, + "description": "Summary of accepted signing algorithms, key ids, and signing-key checks.", + "type": "object" + }, + "verified": { + "description": "True only when discovery, JWKS, signing metadata, and verified-offer endpoint checks pass.", + "type": "boolean" + }, + "verified_stay_offer_url": { + "description": "Host-domain endpoint template or URL used to request signed verified stay offers.", + "format": "uri", + "type": "string" + } + }, + "required": [ + "domain", + "verified" + ], + "type": "object" +}
15 tool updates
v0.1.5- Changed
get_verified_stay_offer5 fields changed- changed
Input schema / properties / check_in / descriptionPrevious value: -"Requested arrival date in YYYY-MM-DD format, e.g. 2026-11-14. Must be before check_out."New value: +"Requested arrival date in YYYY-MM-DD format (e.g. '2026-11-14'). Must be strictly before check_out. Use the same dates the guest requested in search." - changed
Input schema / properties / check_out / descriptionPrevious value: -"Requested departure date in YYYY-MM-DD format, e.g. 2026-11-15. Must be after check_in."New value: +"Requested departure date in YYYY-MM-DD format (e.g. '2026-11-17'). Must be strictly after check_in. Guest does not stay the departure night." - changed
Input schema / properties / domain / descriptionPrevious value: -"Canonical public host-owned vacation-rental domain returned by search or verify_vacation_rental_node, e.g. villaakerlyckan.se. Provide only the domain, not a URL or path."New value: +"Host-owned domain without protocol or path (e.g. 'villaakerlyckan.se', 'myvilla.it'). Optional; omit when the host has not chosen a domain yet. Invalid: 'https://...', paths, ports, or booking URLs." - changed
Input schema / properties / guests / descriptionPrevious value: -"Total guest count for the stay as an integer >= 1. The host node uses this for capacity checks and guest-based pricing."New value: +"Total guest count as positive integer (e.g. 2, 4). Used by the host node for capacity validation and guest-tier pricing on the signed offer." - changed
Input schema / properties / language / descriptionPrevious value: -"Optional BCP-47/RFC 5646 language hint for labels and formatting, e.g. en, sv, de, or sv-SE."New value: +"Optional BCP-47 language tag for labels and formatting (e.g. 'en', 'sv', 'de', 'sv-SE'). Omit to use host default; does not change price or availability."
- Changed
hemmabo_booking_cancel4 fields changed- changed
Input schema / properties / reason / descriptionPrevious value: -"Cancellation reason for host notification (e.g. 'Travel plans changed'). Optional but recommended."New value: +"Human-readable cancellation reason for the host (e.g. 'Travel plans changed', 'Flight cancelled'). Optional; omit when the guest did not give a reason." - changed
Input schema / properties / reservationId / descriptionPrevious value: -"Booking or reservation UUID returned by hemmabo_booking_checkout or hemmabo_booking_create. Use this exact id for status, cancellation, or rescheduling."New value: +"Booking or reservation UUID from hemmabo_booking_checkout or hemmabo_booking_create (e.g. '7c9e6679-7425-40de-944b-e07fc1f90ae7'). Required to look up, cancel, or reschedule the same booking record." - added
Input schema / properties / reservationId / formatAdded value: +"uuid" - added
Input schema / properties / reservationId / patternAdded value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
- Changed
hemmabo_booking_checkout9 fields changed- changed
Input schema / properties / channel / descriptionPrevious value: -"'federation' is the compatibility name for direct host-source pricing. 'public': uses standard website rate."New value: +"Pricing channel selector. 'federation' (default for agent flows): direct host-source total. 'public': standard website rate without agent channel pricing. Omit to use federation." - changed
Input schema / properties / checkIn / descriptionPrevious value: -"Arrival date in ISO 8601 format (YYYY-MM-DD, e.g. '2026-07-15'). Must be today or later."New value: +"Arrival date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-15'). Must be today or later in the property's timezone. Must be strictly before checkOut; together they define the stay length used for pricing and availability." - changed
Input schema / properties / checkOut / descriptionPrevious value: -"Departure date in ISO 8601 format (YYYY-MM-DD, e.g. '2026-07-22'). Must be after checkIn."New value: +"Departure date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-22'). Must be strictly after checkIn on the same calendar. The guest does not stay the departure night." - changed
Input schema / properties / guestEmail / descriptionPrevious value: -"Email for booking confirmation (e.g. 'anna@example.com'). Must be a valid email address."New value: +"Primary guest email in RFC 5322 format (e.g. 'anna@example.com'). Used for booking confirmation and host contact; must be deliverable." - changed
Input schema / properties / guestName / descriptionPrevious value: -"Full name of primary guest (e.g. 'Anna Svensson')."New value: +"Primary guest full name as plain text (e.g. 'Anna Svensson'). Stored on the booking for host confirmation; use the name the guest provided." - changed
Input schema / properties / guestPhone / descriptionPrevious value: -"Phone with country code (e.g. '+46701234567'). Optional but recommended."New value: +"Primary guest phone in E.164 format with country code (e.g. '+46701234567'). Optional; omit when unknown. Recommended for check-in coordination." - changed
Input schema / properties / paymentMode / descriptionPrevious value: -"'checkout_session' (default): returns a host-configured Stripe redirect URL. 'payment_intent': returns client_secret for configured fallback non-VRP payment integrations."New value: +"Stripe payment flow. 'checkout_session' (default): returns a browser redirect URL. 'payment_intent': returns client_secret for embedded/agentic payment integrations. Omit to use checkout_session." - changed
Input schema / properties / propertyId / descriptionPrevious value: -"Stable property UUID returned by hemmabo_search_properties. Use the exact UUID, not the property name, domain, or booking URL."New value: +"Stable property UUID from hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000'). Pass the exact UUID string — never a property name, host domain, or booking URL." - changed
Input schema / properties / quoteId / descriptionPrevious value: -"Quote ID from hemmabo_booking_negotiate to lock the price. Optional - if omitted, a fresh direct host-source price is calculated at checkout time."New value: +"Quote ID string from hemmabo_booking_negotiate (e.g. 'q_abc123'). Optional — omit to calculate a fresh host-source price at checkout. Provide when the guest locked a price within the 15-minute quote window."
- Changed
hemmabo_booking_create7 fields changed- changed
Input schema / properties / checkIn / descriptionPrevious value: -"Booking arrival date in YYYY-MM-DD format."New value: +"Arrival date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-15'). Must be today or later in the property's timezone. Must be strictly before checkOut; together they define the stay length used for pricing and availability." - changed
Input schema / properties / checkOut / descriptionPrevious value: -"Booking departure date in YYYY-MM-DD format; must be after checkIn."New value: +"Departure date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-22'). Must be strictly after checkIn on the same calendar. The guest does not stay the departure night." - changed
Input schema / properties / guestEmail / descriptionPrevious value: -"Primary guest email for confirmation and host contact."New value: +"Primary guest email in RFC 5322 format (e.g. 'anna@example.com'). Used for booking confirmation and host contact; must be deliverable." - changed
Input schema / properties / guestName / descriptionPrevious value: -"Primary guest name for host confirmation."New value: +"Primary guest full name as plain text (e.g. 'Anna Svensson'). Stored on the booking for host confirmation; use the name the guest provided." - changed
Input schema / properties / guestPhone / descriptionPrevious value: -"Primary guest phone with country code; optional but recommended."New value: +"Primary guest phone in E.164 format with country code (e.g. '+46701234567'). Optional; omit when unknown. Recommended for check-in coordination." - changed
Input schema / properties / guests / descriptionPrevious value: -"Total number of guests as integer >= 1 (e.g. 4)."New value: +"Total guest count as a positive integer (e.g. 2, 4, 6). Used for capacity filtering and staircase pricing tiers. Properties with maxGuests below this value are excluded from search results." - changed
Input schema / properties / propertyId / descriptionPrevious value: -"Property UUID returned by hemmabo_search_properties for this fallback non-VRP booking. Use the exact UUID, not a property name, domain, or booking URL."New value: +"Stable property UUID from hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000'). Pass the exact UUID string — never a property name, host domain, or booking URL."
- Changed
hemmabo_booking_negotiate3 fields changed- changed
Input schema / properties / checkIn / descriptionPrevious value: -"Arrival date in ISO 8601 format (YYYY-MM-DD, e.g. '2026-07-15'). Must be today or later."New value: +"Arrival date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-15'). Must be today or later in the property's timezone. Must be strictly before checkOut; together they define the stay length used for pricing and availability." - changed
Input schema / properties / checkOut / descriptionPrevious value: -"Departure date in ISO 8601 format (YYYY-MM-DD, e.g. '2026-07-22'). Must be after checkIn."New value: +"Departure date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-22'). Must be strictly after checkIn on the same calendar. The guest does not stay the departure night." - changed
Input schema / properties / propertyId / descriptionPrevious value: -"Stable property UUID returned by hemmabo_search_properties. Use the exact UUID, not the property name, domain, or booking URL."New value: +"Stable property UUID from hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000'). Pass the exact UUID string — never a property name, host domain, or booking URL."
- Changed
hemmabo_booking_quote4 fields changed- changed
Input schema / properties / checkIn / descriptionPrevious value: -"Arrival date in ISO 8601 format (YYYY-MM-DD, e.g. '2026-07-15'). Must be today or later."New value: +"Arrival date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-15'). Must be today or later in the property's timezone. Must be strictly before checkOut; together they define the stay length used for pricing and availability." - changed
Input schema / properties / checkOut / descriptionPrevious value: -"Departure date in ISO 8601 format (YYYY-MM-DD, e.g. '2026-07-22'). Must be after checkIn."New value: +"Departure date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-22'). Must be strictly after checkIn on the same calendar. The guest does not stay the departure night." - changed
Input schema / properties / guests / descriptionPrevious value: -"Total number of guests as integer >= 1 (e.g. 4). Determines which price tier is applied (staircase pricing by guest count)."New value: +"Total guest count as a positive integer (e.g. 2, 4, 6). Used for capacity filtering and staircase pricing tiers. Properties with maxGuests below this value are excluded from search results." - changed
Input schema / properties / propertyId / descriptionPrevious value: -"Stable property UUID returned by hemmabo_search_properties. Use the exact UUID, not the property name, domain, or booking URL."New value: +"Stable property UUID from hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000'). Pass the exact UUID string — never a property name, host domain, or booking URL."
- Changed
hemmabo_booking_reschedule6 fields changed- changed
Input schema / properties / newCheckIn / descriptionPrevious value: -"New arrival date in ISO 8601 format (YYYY-MM-DD, e.g. '2026-07-20'). Must be today or later."New value: +"New arrival date in YYYY-MM-DD format (e.g. '2026-08-01'). Must be today or later. Must be strictly before newCheckOut." - changed
Input schema / properties / newCheckOut / descriptionPrevious value: -"New departure date in ISO 8601 format (YYYY-MM-DD, e.g. '2026-07-27'). Must be after newCheckIn."New value: +"New departure date in YYYY-MM-DD format (e.g. '2026-08-08'). Must be strictly after newCheckIn." - changed
Input schema / properties / reason / descriptionPrevious value: -"Reason for rescheduling (e.g. 'Flight delayed'). Optional but recommended for host records."New value: +"Human-readable reschedule reason for host records (e.g. 'Flight delayed', 'Extended conference'). Optional; omit when not provided by the guest." - changed
Input schema / properties / reservationId / descriptionPrevious value: -"Booking UUID to reschedule (e.g. '550e8400-e29b-41d4-a716-446655440000'). Must be in 'confirmed' or 'pending' status."New value: +"Booking or reservation UUID from hemmabo_booking_checkout or hemmabo_booking_create (e.g. '7c9e6679-7425-40de-944b-e07fc1f90ae7'). Required to look up, cancel, or reschedule the same booking record." - added
Input schema / properties / reservationId / formatAdded value: +"uuid" - added
Input schema / properties / reservationId / patternAdded value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
- Changed
hemmabo_booking_status3 fields changed- changed
Input schema / properties / reservationId / descriptionPrevious value: -"Booking or reservation UUID returned by checkout/create. Required to look up the exact booking."New value: +"Booking or reservation UUID from hemmabo_booking_checkout or hemmabo_booking_create (e.g. '7c9e6679-7425-40de-944b-e07fc1f90ae7'). Required to look up, cancel, or reschedule the same booking record." - added
Input schema / properties / reservationId / formatAdded value: +"uuid" - added
Input schema / properties / reservationId / patternAdded value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"
- Changed
hemmabo_compare_properties5 fields changed- changed
Input schema / properties / checkIn / descriptionPrevious value: -"Arrival date in ISO 8601 format (YYYY-MM-DD). Must be today or later."New value: +"Arrival date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-15'). Must be today or later in the property's timezone. Must be strictly before checkOut; together they define the stay length used for pricing and availability." - changed
Input schema / properties / checkOut / descriptionPrevious value: -"Departure date in ISO 8601 format (YYYY-MM-DD). Must be after checkIn."New value: +"Departure date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-22'). Must be strictly after checkIn on the same calendar. The guest does not stay the departure night." - changed
Input schema / properties / guests / descriptionPrevious value: -"Total number of guests as integer >= 1."New value: +"Total guest count as a positive integer (e.g. 2, 4, 6). Used for capacity filtering and staircase pricing tiers. Properties with maxGuests below this value are excluded from search results." - changed
Input schema / properties / propertyIds / descriptionPrevious value: -"Array of 2 to 10 property UUIDs returned by hemmabo_search_properties. Use UUIDs only; do not pass domains, names, or booking URLs."New value: +"Ordered list of 2–10 property UUIDs to compare on the same dates. All IDs must come from hemmabo_search_properties; do not pass host domains, names, or booking URLs." - changed
Input schema / properties / propertyIds / items / descriptionPrevious value: -"Property UUID returned by hemmabo_search_properties."New value: +"Single property UUID from hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000'). Repeat one entry per property to compare."
- Changed
hemmabo_host_onboarding_link6 fields changed- changed
Input schema / properties / city / descriptionPrevious value: -"Optional city or municipality where the property is located."New value: +"City or municipality (e.g. 'Kävlinge', 'Florence'). Optional; used in onboarding URL prefill when provided." - changed
Input schema / properties / country / descriptionPrevious value: -"Optional country where the property is located."New value: +"Country where the property operates (e.g. 'Sweden', 'Italy', 'Morocco'). Optional; improves onboarding URL locale and fit assessment." - changed
Input schema / properties / domain / descriptionPrevious value: -"Optional existing or intended host-owned domain, without https:// or path."New value: +"Host-owned domain without protocol or path (e.g. 'villaakerlyckan.se', 'myvilla.it'). Optional; omit when the host has not chosen a domain yet. Invalid: 'https://...', paths, ports, or booking URLs." - changed
Input schema / properties / language / descriptionPrevious value: -"Optional language hint for onboarding, e.g. sv, en, de."New value: +"ISO 639-1 language hint for onboarding copy (e.g. 'sv', 'en', 'de', 'fr'). Optional; omit to default to English." - changed
Input schema / properties / propertyName / descriptionPrevious value: -"Optional property or business name to carry into the onboarding URL."New value: +"Property or business display name (e.g. 'Villa Åkerlyckan'). Optional; carried into onboarding URL when provided." - changed
Input schema / properties / region / descriptionPrevious value: -"Optional region or area where the property is located."New value: +"Region or area (e.g. 'Skåne', 'Toscana', 'Marrakech-Safi'). Optional; narrows onboarding handoff and proof examples."
- Changed
hemmabo_host_readiness_check12 fields changed- changed
Input schema / properties / city / descriptionPrevious value: -"Optional city or municipality where the property is located."New value: +"City or municipality (e.g. 'Kävlinge', 'Florence'). Optional; used in onboarding URL prefill when provided." - changed
Input schema / properties / country / descriptionPrevious value: -"Optional country where the property is located."New value: +"Country where the property operates (e.g. 'Sweden', 'Italy', 'Morocco'). Optional; improves onboarding URL locale and fit assessment." - changed
Input schema / properties / currentChannels / descriptionPrevious value: -"Optional existing places the host uses today, e.g. Airbnb, Booking.com, Vrbo, manual calendar, own website, PMS."New value: +"Optional list of channels the host uses today. Omit when unknown. Helps assess migration fit from OTAs to own-domain booking." - added
Input schema / properties / currentChannels / items / descriptionAdded value: +"Single distribution channel name (e.g. 'Airbnb', 'Booking.com', 'Vrbo', 'own website'). Up to 8 entries." - changed
Input schema / properties / domain / descriptionPrevious value: -"Optional existing or intended host-owned domain, without https:// or path."New value: +"Host-owned domain without protocol or path (e.g. 'villaakerlyckan.se', 'myvilla.it'). Optional; omit when the host has not chosen a domain yet. Invalid: 'https://...', paths, ports, or booking URLs." - changed
Input schema / properties / hasOwnDomain / descriptionPrevious value: -"Whether the host already has or wants to use an own domain."New value: +"True if the host already owns a domain or explicitly wants one (e.g. true for 'I have villaakerlyckan.se'). False or omit when still undecided." - changed
Input schema / properties / preferredLanguage / descriptionPrevious value: -"Optional language hint for onboarding, e.g. sv, en, de."New value: +"ISO 639-1 language hint for onboarding copy (e.g. 'sv', 'en', 'de', 'fr'). Optional; omit to default to English." - changed
Input schema / properties / propertyName / descriptionPrevious value: -"Optional property or business name the host gave, e.g. Villa Akerlyckan."New value: +"Property or business display name (e.g. 'Villa Åkerlyckan'). Optional; carried into onboarding URL when provided." - changed
Input schema / properties / propertyType / descriptionPrevious value: -"Optional property category. HemmaBo is optimized for vacation-rental hosts and independent properties."New value: +"Property category enum. Optional; omit when unknown. 'villa'/'holiday_home' fit best; 'hotel' may indicate a poor HemmaBo fit for large chains." - changed
Input schema / properties / region / descriptionPrevious value: -"Optional region or area where the property is located."New value: +"Region or area (e.g. 'Skåne', 'Toscana', 'Marrakech-Safi'). Optional; narrows onboarding handoff and proof examples." - changed
Input schema / properties / wantsAiAgentBooking / descriptionPrevious value: -"Whether the host wants AI agents to discover, verify, and route bookings to the host-owned domain."New value: +"True if the host wants AI agents (ChatGPT, Claude, Cursor) to discover and book via their own domain. False or omit when they only want a guest website." - changed
Input schema / properties / wantsDirectPayments / descriptionPrevious value: -"Whether the host wants Stripe payments direct to the host rather than HemmaBo as merchant of record."New value: +"True if the host wants Stripe Connect payouts direct to their account. False or omit when they expect HemmaBo to be merchant of record (not supported)."
- Changed
hemmabo_search_availability4 fields changed- changed
Input schema / properties / checkIn / descriptionPrevious value: -"Arrival date in ISO 8601 format (YYYY-MM-DD, e.g. '2026-07-15'). Must be today or later."New value: +"Arrival date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-15'). Must be today or later in the property's timezone. Must be strictly before checkOut; together they define the stay length used for pricing and availability." - changed
Input schema / properties / checkOut / descriptionPrevious value: -"Departure date in ISO 8601 format (YYYY-MM-DD, e.g. '2026-07-22'). Must be after checkIn."New value: +"Departure date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-22'). Must be strictly after checkIn on the same calendar. The guest does not stay the departure night." - changed
Input schema / properties / guests / descriptionPrevious value: -"Optional guest count. When provided, alternative date windows include live pricing."New value: +"Optional guest count (e.g. 4). Omit when only checking date availability without pricing. When provided, alternative date windows in the response include live host-source totals for that guest count." - changed
Input schema / properties / propertyId / descriptionPrevious value: -"Property UUID returned by hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000')."New value: +"Stable property UUID from hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000'). Pass the exact UUID string — never a property name, host domain, or booking URL."
- Changed
hemmabo_search_properties5 fields changed- changed
Input schema / properties / checkIn / descriptionPrevious value: -"Arrival date in ISO 8601 format (YYYY-MM-DD, e.g. '2026-07-15'). Must be today or later."New value: +"Arrival date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-15'). Must be today or later in the property's timezone. Must be strictly before checkOut; together they define the stay length used for pricing and availability." - changed
Input schema / properties / checkOut / descriptionPrevious value: -"Departure date in ISO 8601 format (YYYY-MM-DD, e.g. '2026-07-22'). Must be after checkIn."New value: +"Departure date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-22'). Must be strictly after checkIn on the same calendar. The guest does not stay the departure night." - changed
Input schema / properties / country / descriptionPrevious value: -"Country name to filter by (e.g. 'Sweden', 'Italy'). Partial match. At least one of region or country should be provided; omit only when the user has given a specific region."New value: +"Country name to filter by (e.g. 'Sweden', 'Italy', 'Morocco'). Partial case-insensitive match. Provide at least one of region or country; omit when region already narrows the destination." - changed
Input schema / properties / guests / descriptionPrevious value: -"Total number of guests as integer >= 1 (e.g. 4). Determines price tier and filters out properties with insufficient capacity."New value: +"Total guest count as a positive integer (e.g. 2, 4, 6). Used for capacity filtering and staircase pricing tiers. Properties with maxGuests below this value are excluded from search results." - changed
Input schema / properties / region / descriptionPrevious value: -"Region, area, or destination name to search within. Partial match (e.g. 'Skane', 'Toscana', 'Bavaria'). At least one of region or country should be provided."New value: +"Region, area, or destination to search within (e.g. 'Skåne', 'Kävlinge', 'Toscana', 'Bavaria'). Partial case-insensitive match. Provide at least one of region or country; omit only when country alone is sufficient."
- Changed
hemmabo_search_similar5 fields changed- changed
Input schema / properties / checkIn / descriptionPrevious value: -"Arrival date in ISO 8601 format (YYYY-MM-DD). Must be today or later."New value: +"Arrival date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-15'). Must be today or later in the property's timezone. Must be strictly before checkOut; together they define the stay length used for pricing and availability." - changed
Input schema / properties / checkOut / descriptionPrevious value: -"Departure date in ISO 8601 format (YYYY-MM-DD). Must be after checkIn."New value: +"Departure date in ISO 8601 calendar format YYYY-MM-DD (e.g. '2026-07-22'). Must be strictly after checkIn on the same calendar. The guest does not stay the departure night." - changed
Input schema / properties / guests / descriptionPrevious value: -"Number of guests. Defaults to source property's max_guests."New value: +"Optional guest count (e.g. 4). Omit to use the source property's maxGuests for matching and pricing. When provided, filters alternatives that cannot accommodate this count." - changed
Input schema / properties / limit / descriptionPrevious value: -"Max results. Default 5, max 20."New value: +"Maximum number of similar properties to return (integer 1–20). Omit to use server default 5. Increase when the guest wants more alternatives." - changed
Input schema / properties / propertyId / descriptionPrevious value: -"UUID of the source property to find alternatives for."New value: +"Stable property UUID from hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000'). Pass the exact UUID string — never a property name, host domain, or booking URL."
- Changed
verify_vacation_rental_node1 field changed- changed
Input schema / properties / domain / descriptionPrevious value: -"Canonical public host-owned vacation-rental domain to verify, e.g. villaakerlyckan.se. Provide only the domain: no https:// prefix, path, query string, port, or booking URL."New value: +"Host-owned domain without protocol or path (e.g. 'villaakerlyckan.se', 'myvilla.it'). Optional; omit when the host has not chosen a domain yet. Invalid: 'https://...', paths, ports, or booking URLs."
12 tool updates
v0.1.4- Changed
get_verified_stay_offer5 fields changed- changed
Input schema / properties / check_in / descriptionPrevious value: -"Arrival date in YYYY-MM-DD format."New value: +"Requested arrival date in YYYY-MM-DD format, e.g. 2026-11-14. Must be before check_out." - changed
Input schema / properties / check_out / descriptionPrevious value: -"Departure date in YYYY-MM-DD format. Must be after check_in."New value: +"Requested departure date in YYYY-MM-DD format, e.g. 2026-11-15. Must be after check_in." - changed
Input schema / properties / domain / descriptionPrevious value: -"Host-owned vacation rental domain, e.g. villaakerlyckan.se."New value: +"Canonical public host-owned vacation-rental domain returned by search or verify_vacation_rental_node, e.g. villaakerlyckan.se. Provide only the domain, not a URL or path." - changed
Input schema / properties / guests / descriptionPrevious value: -"Total number of guests as integer >= 1."New value: +"Total guest count for the stay as an integer >= 1. The host node uses this for capacity checks and guest-based pricing." - changed
Input schema / properties / language / descriptionPrevious value: -"Optional preferred response language, e.g. en or sv."New value: +"Optional BCP-47/RFC 5646 language hint for labels and formatting, e.g. en, sv, de, or sv-SE."
- Changed
hemmabo_booking_cancel1 field changed- changed
Input schema / properties / reservationId / descriptionPrevious value: -"Booking UUID from hemmabo_booking_checkout or hemmabo_booking_create (e.g. '550e8400-e29b-41d4-a716-446655440000')."New value: +"Booking or reservation UUID returned by hemmabo_booking_checkout or hemmabo_booking_create. Use this exact id for status, cancellation, or rescheduling."
- Changed
hemmabo_booking_checkout4 fields changed- changed
Input schema / properties / channel / descriptionPrevious value: -"'federation' (default): applies direct booking discount. 'public': uses standard website rate."New value: +"'federation' is the compatibility name for direct host-source pricing. 'public': uses standard website rate." - changed
Input schema / properties / paymentMode / descriptionPrevious value: -"'checkout_session' (default): returns Stripe redirect URL. 'payment_intent': returns client_secret for programmatic payment (AI agent MPP flow)."New value: +"'checkout_session' (default): returns a host-configured Stripe redirect URL. 'payment_intent': returns client_secret for configured fallback non-VRP payment integrations." - changed
Input schema / properties / propertyId / descriptionPrevious value: -"Property UUID from hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000')."New value: +"Stable property UUID returned by hemmabo_search_properties. Use the exact UUID, not the property name, domain, or booking URL." - changed
Input schema / properties / quoteId / descriptionPrevious value: -"Quote ID from hemmabo_booking_negotiate to lock the price. Optional — if omitted, a fresh federation price is calculated at checkout time."New value: +"Quote ID from hemmabo_booking_negotiate to lock the price. Optional - if omitted, a fresh direct host-source price is calculated at checkout time."
- Changed
hemmabo_booking_create6 fields changed- changed
Input schema / properties / checkIn / descriptionPrevious value: -"Arrival date in ISO 8601 format (YYYY-MM-DD, e.g. '2026-07-15'). Must be today or later."New value: +"Booking arrival date in YYYY-MM-DD format." - changed
Input schema / properties / checkOut / descriptionPrevious value: -"Departure date in ISO 8601 format (YYYY-MM-DD, e.g. '2026-07-22'). Must be after checkIn."New value: +"Booking departure date in YYYY-MM-DD format; must be after checkIn." - changed
Input schema / properties / guestEmail / descriptionPrevious value: -"Email for booking confirmation (e.g. 'anna@example.com'). Must be a valid email address."New value: +"Primary guest email for confirmation and host contact." - changed
Input schema / properties / guestName / descriptionPrevious value: -"Full name of primary guest (e.g. 'Anna Svensson')."New value: +"Primary guest name for host confirmation." - changed
Input schema / properties / guestPhone / descriptionPrevious value: -"Phone with country code (e.g. '+46701234567'). Optional but recommended for check-in coordination."New value: +"Primary guest phone with country code; optional but recommended." - changed
Input schema / properties / propertyId / descriptionPrevious value: -"Property UUID from hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000')."New value: +"Property UUID returned by hemmabo_search_properties for this fallback non-VRP booking. Use the exact UUID, not a property name, domain, or booking URL."
- Changed
hemmabo_booking_negotiate1 field changed- changed
Input schema / properties / propertyId / descriptionPrevious value: -"Property UUID from hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000')."New value: +"Stable property UUID returned by hemmabo_search_properties. Use the exact UUID, not the property name, domain, or booking URL."
- Changed
hemmabo_booking_quote1 field changed- changed
Input schema / properties / propertyId / descriptionPrevious value: -"Property UUID from hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000')."New value: +"Stable property UUID returned by hemmabo_search_properties. Use the exact UUID, not the property name, domain, or booking URL."
- Changed
hemmabo_booking_status1 field changed- changed
Input schema / properties / reservationId / descriptionPrevious value: -"Booking UUID from hemmabo_booking_checkout or hemmabo_booking_create (e.g. '550e8400-e29b-41d4-a716-446655440000')."New value: +"Booking or reservation UUID returned by checkout/create. Required to look up the exact booking."
- Changed
hemmabo_compare_properties2 fields changed- changed
Input schema / properties / propertyIds / descriptionPrevious value: -"Array of 2 to 10 property UUIDs to compare side by side."New value: +"Array of 2 to 10 property UUIDs returned by hemmabo_search_properties. Use UUIDs only; do not pass domains, names, or booking URLs." - added
Input schema / properties / propertyIds / items / descriptionAdded value: +"Property UUID returned by hemmabo_search_properties."
- Added
hemmabo_host_onboarding_link - Added
hemmabo_host_readiness_check - Changed
hemmabo_search_properties1 field changed- changed
Input schema / properties / country / descriptionPrevious value: -"Country name to filter by (e.g. 'Sweden', 'Italy'). Partial match. At least one of region or country should be provided."New value: +"Country name to filter by (e.g. 'Sweden', 'Italy'). Partial match. At least one of region or country should be provided; omit only when the user has given a specific region."
- Changed
verify_vacation_rental_node1 field changed- changed
Input schema / properties / domain / descriptionPrevious value: -"Host-owned vacation rental domain to verify, e.g. villaakerlyckan.se. Do not include a path."New value: +"Canonical public host-owned vacation-rental domain to verify, e.g. villaakerlyckan.se. Provide only the domain: no https:// prefix, path, query string, port, or booking URL."
7 tool updates
v0.1.3- Changed
hemmabo_booking_cancel1 field changed- changed
Input schema / properties / reservationId / descriptionPrevious value: -"Booking UUID from booking.checkout or booking.create (e.g. '550e8400-e29b-41d4-a716-446655440000')."New value: +"Booking UUID from hemmabo_booking_checkout or hemmabo_booking_create (e.g. '550e8400-e29b-41d4-a716-446655440000')."
- Changed
hemmabo_booking_checkout2 fields changed- changed
Input schema / properties / propertyId / descriptionPrevious value: -"Property UUID from search.properties (e.g. '550e8400-e29b-41d4-a716-446655440000')."New value: +"Property UUID from hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000')." - changed
Input schema / properties / quoteId / descriptionPrevious value: -"Quote ID from booking.negotiate to lock the price. Optional — if omitted, a fresh federation price is calculated at checkout time."New value: +"Quote ID from hemmabo_booking_negotiate to lock the price. Optional — if omitted, a fresh federation price is calculated at checkout time."
- Changed
hemmabo_booking_create1 field changed- changed
Input schema / properties / propertyId / descriptionPrevious value: -"Property UUID from search.properties (e.g. '550e8400-e29b-41d4-a716-446655440000')."New value: +"Property UUID from hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000')."
- Changed
hemmabo_booking_negotiate1 field changed- changed
Input schema / properties / propertyId / descriptionPrevious value: -"Property UUID from search.properties (e.g. '550e8400-e29b-41d4-a716-446655440000')."New value: +"Property UUID from hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000')."
- Changed
hemmabo_booking_quote1 field changed- changed
Input schema / properties / propertyId / descriptionPrevious value: -"Property UUID from search.properties (e.g. '550e8400-e29b-41d4-a716-446655440000')."New value: +"Property UUID from hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000')."
- Changed
hemmabo_booking_status1 field changed- changed
Input schema / properties / reservationId / descriptionPrevious value: -"Booking UUID from booking.checkout or booking.create (e.g. '550e8400-e29b-41d4-a716-446655440000')."New value: +"Booking UUID from hemmabo_booking_checkout or hemmabo_booking_create (e.g. '550e8400-e29b-41d4-a716-446655440000')."
- Changed
hemmabo_search_availability1 field changed- changed
Input schema / properties / propertyId / descriptionPrevious value: -"Property UUID returned by search.properties (e.g. '550e8400-e29b-41d4-a716-446655440000')."New value: +"Property UUID returned by hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000')."
17 tool updates
v0.1.1- Removed
check_availability - Removed
create_booking - Removed
get_canonical_quote - Added
get_verified_stay_offer - Added
hemmabo_booking_cancel - Added
hemmabo_booking_checkout - Added
hemmabo_booking_create - Added
hemmabo_booking_negotiate - Added
hemmabo_booking_quote - Added
hemmabo_booking_reschedule - Added
hemmabo_booking_status - Added
hemmabo_compare_properties - Added
hemmabo_search_availability - Added
hemmabo_search_properties - Added
hemmabo_search_similar - Removed
search_properties - Added
verify_vacation_rental_node
4 tool updates
v0.1.0- First observed
check_availability - First observed
create_booking - First observed
get_canonical_quote - First observed
search_properties
TDQS
Scored across 13 tools
Most tools have clear boundaries: search vs. availability vs. offer vs. quote are distinct stages, and booking lifecycle tools (create/status/cancel/reschedule) are well-separated. The main ambiguity is between hemmabo_booking_checkout and hemmabo_booking_create, which both create pending bookings in the fallback flow, though checkout adds Stripe payment while create does not.
The hemmabo_ prefix is consistent, and most tools follow verb_noun patterns (search_properties, booking_cancel, host_onboarding_link). Minor deviations: get_verified_stay_offer and verify_vacation_rental_node use different verb styles, and hemmabo_booking_negotiate is misleadingly named since it locks a price rather than negotiating.
13 tools is within the well-scoped range and each tool covers a distinct stage of the guest/host journey. Slightly heavy due to the fallback booking flow requiring three tools (negotiate, create, checkout) that overlap in purpose, but the count is reasonable for the domain.
The guest booking lifecycle is well covered: search, availability, quote, offer, create/checkout, status, cancel, reschedule. Host-side coverage is thinner (readiness check and onboarding link only, no host management tools), and there is no explicit tool for updating a booking's guest details, but core workflows are complete.
Maintenance
Related MCP Connectors
Book vacation rentals direct: search homes, check live availability, get a real total.
Vacation rental discovery, direct booking, and property protection for AI agents.
Booking.com stays by destination and dates, and full property details, as structured JSON.
Read-only property facts, indicative availability, authorised booking links and guest-safe support.
Related MCP Servers
- AlicenseNot gradedqualityNot gradedmaintenanceAn MCP server that provides tools for interacting with Supabase databases, storage, and edge functions.45MIT
- AlicenseNot gradedqualityCmaintenanceThe Stripe Model Context Protocol server allows you to integrate with Stripe APIs through function calling. This protocol supports various tools to interact with different Stripe services.13,246 npm1,827-
- AlicenseNot gradedqualityDmaintenanceEnables management of vacation rental properties through the Hostex API, including reservations, guest communications, availability calendars, reviews, and channel listings.1MIT
- AlicenseCqualityDmaintenanceThe only MCP server with AI guest risk scoring and extortion detection. Search properties, book instantly, protect hosts. 41 tools across 5 layers. Instant API key, 10 free credits.6MIT