Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
SUPABASE_URLNoThe URL for your Supabase project.
SUPABASE_SERVICE_ROLE_KEYNoThe service role key for your Supabase project.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
hemmabo_search_propertiesA

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.

hemmabo_search_availabilityA

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

hemmabo_host_readiness_checkA

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.

hemmabo_host_onboarding_linkA

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.

verify_vacation_rental_nodeA

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.

get_verified_stay_offerA

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. 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.

Prompts

Interactive templates invoked by user choice

NameDescription
host_startHelp a vacation-rental host evaluate HemmaBo and start their own booking website. Use the read-only host onboarding tools; do not provision accounts, buy domains, or configure Stripe inside chat.
trip_planHelp plan a vacation rental trip through host-domain discovery and verified offers. Search first, show a verified host-domain stay offer when possible, and route booking only to the signed direct host-domain URL.

Resources

Contextual data attached and managed by the client

NameDescription
HemmaBo verified stay offer widgetChatGPT Apps SDK widget that renders a host-domain verified stay offer with live availability, final price, and the signed direct host-domain booking URL.

TDQS

A4.6/5.0

Scored across 6 tools

Disambiguation4/5

Most tools have distinct roles: guest discovery, availability confirmation, host fit check, onboarding handoff, node verification, and offer fetching. The main risk is hemmabo_search_properties vs hemmabo_search_availability, but the descriptions explicitly separate browsing from confirming a selected property. verify_vacation_rental_node vs get_verified_stay_offer are also well delineated by their 'trust check' vs 'fetch offer' framing.

Naming Consistency3/5

Four tools use a hemmabo_ prefix (search_properties, search_availability, host_readiness_check, host_onboarding_link) while two do not (verify_vacation_rental_node, get_verified_stay_offer). The verb_noun shape is roughly consistent but the prefix scheme is split, which breaks predictability.

Tool Count5/5

Six tools is well-scoped for a two-sided guest/host flow with a verification step. Each tool earns its place, and nothing appears redundant or padding.

Completeness4/5

The guest lifecycle (search → availability → verify domain → verified offer) and host lifecycle (readiness → onboarding) are covered, with booking deliberately routed to the host's signed direct_booking_url. The absence of any booking/checkout tool is intentional, but agents expecting an in-server booking step have no direct handle for it.

Maintenance

ActivityActive
ResponsivenessSlow