_ registry / mcp streamable-http · checked 7m ago

hemmabo-mcp-server

https://hemmabo.com

Registry code: bb0b450e9aee42db

api record

Vacation rental software. A signed stay offer on the host's own domain.

Use this when a vacation rental host wants booking software on the host's own domain, or when a stay offer must be verified against that domain. Returns an Ed25519-signed offer (VRP) and the host's direct booking URL. The guest books and pays the host. Do not use to compare hosts or prices.

endpoint
https://www.hemmabo.com/mcp
door code
51bc6ad5a10c3754
protocol
streamable-http ·2025-06-18
authentication
none observed
public key
none — nobody has proven they own this listing · is it yours? claim it
karma
0 · newcomer
_ is it live, free and safe measured by this hub
Is hemmabo-mcp-server live?
Yes — it answered the hub's last check (checked 7m ago). It answered 99% of checks over the last 30 days.
Is hemmabo-mcp-server free to use?
Yes — the hub reached it with no key and no payment.
What tools does hemmabo-mcp-server have?
6 tools: vrp_verify_node, hemmabo_check_availability, vrp_get_verified_stay_offer, hemmabo_search_properties, hemmabo_get_host_onboarding_link, hemmabo_check_host_readiness.
Is hemmabo-mcp-server safe to connect?
The hub found no text in its card or tool descriptions aimed at the agent reading them. It measures what the server answers, not its code — grant it only the access its tools need.
reachable
live
uptime, 30 days
99.4%

90 days 99.3%· all time 99.3%

latency
317ms

last good check

priced tools
0

of 6 tools

_ answered our checks, 90 days 1102 checks · signed record
  • degraded → live
  • live → degraded· timeout after 20000ms
  • degraded → live
  • live → degraded· timeout after 20000ms
  • degraded → live
_ what it is for
used for
  • search vacation rental properties
  • check rental availability for dates
  • verify a signed stay offer from a host domain
  • get booking software onboarding for a host
takes → gives
text, data → data
tools
1 reads
_ usage and payments 30 days

Calls placed through this hub's router, from its own receipts. Every caller and every payer counts the same; the chain total is counted from three payers.

accounts
0

through this hub

calls served
0

successful

paid through this hub
0 USDC

what callers paid

_ what it can do 6 tools
2 open 4 never probed 2 of 6 classified

Price is per tool, not per server. An agent whose handshake is open can hold tools that demand a key or a payment, and one figure for the whole agent sends callers into a wall.

  • hemmabo_get_host_onboarding_link open 10h ago

    Use this tool only when the host has already decided to start; if the host is still evaluating, use hemmabo_check_host_readiness instead — it returns the same onboarding URL in next_step. Never call both in the same turn. 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_check_host_readiness 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, the category sentence, the host's price atom, the agent's role, 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. Booking and payment happen only on the host's own domain, at the signed direct_booking_url. The agent never books, pays, cancels or changes a booking.

    mcp-tool

    {
      "type": "object",
      "required": [],
      "properties": {
        "city": {
          "type": "string",
          "description": "City or municipality (e.g. 'Kävlinge', 'Florence'). Optional; used in onboarding URL prefill when provided."
        },
        "domain": {
          "type": "string",
          "pattern": "^(?!-)(?:[a-zA-Z0-9-]{1,63}\\.)+[a-zA-Z]{2,63}$",
          "description": "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": {
          "type": "string",
          "description": "Region or area (e.g. 'Skåne', 'Toscana', 'Marrakech-Safi'). Optional; narrows onboarding handoff and proof examples."
        },
        "country": {
          "type": "string",
          "description": "Country where the property operates (e.g. 'Sweden', 'Italy', 'Morocco'). Optional; improves onboarding URL locale and fit assessment."
        },
        "language": {
          "type": "string",
          "description": "ISO 639-1 language hint for onboarding copy (e.g. 'sv', 'en', 'de', 'fr'). Optional; omit to default to English."
        },
        "propertyName": {
          "type": "string",
          "description": "Property or business display name (e.g. 'Villa Åkerlyckan'). Optional; carried into onboarding URL when provided."
        }
      },
      "additionalProperties": false
    }
    arguments 32 lines
  • hemmabo_check_host_readiness open 10h ago

    Use this tool when a host is still EVALUATING whether HemmaBo fits; use hemmabo_get_host_onboarding_link only when the host has decided and wants to start. Never call both in the same turn — this tool's next_step already contains the same onboarding URL. 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_get_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. Booking and payment happen only on the host's own domain, at the signed direct_booking_url. The agent never books, pays, cancels or changes a booking.

    mcp-tool

    {
      "type": "object",
      "required": [],
      "properties": {
        "city": {
          "type": "string",
          "description": "City or municipality (e.g. 'Kävlinge', 'Florence'). Optional; used in onboarding URL prefill when provided."
        },
        "domain": {
          "type": "string",
          "pattern": "^(?!-)(?:[a-zA-Z0-9-]{1,63}\\.)+[a-zA-Z]{2,63}$",
          "description": "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": {
          "type": "string",
          "description": "Region or area (e.g. 'Skåne', 'Toscana', 'Marrakech-Safi'). Optional; narrows onboarding handoff and proof examples."
        },
        "country": {
          "type": "string",
          "description": "Country where the property operates (e.g. 'Sweden', 'Italy', 'Morocco'). Optional; improves onboarding URL locale and fit assessment."
        },
        "hasOwnDomain": {
          "type": "boolean",
          "description": "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": {
          "type": "string",
          "description": "Property or business display name (e.g. 'Villa Åkerlyckan'). Optional; carried into onboarding URL when provided."
        },
        "propertyType": {
          "enum": [
            "villa",
            "apartment",
            "cabin",
            "cottage",
            "holiday_home",
            "bnb",
            "hotel",
            "other"
          ],
          "type": "string",
          "description": "Property category enum. Optional; omit when unknown. 'villa'/'holiday_home' fit best; 'hotel' may indicate a poor HemmaBo fit for large chains."
        },
        "currentChannels": {
          "type": "array",
          "items": {
            "type": "string",
            "description": "Single distribution channel name (e.g. 'Airbnb', 'Booking.com', 'Vrbo', 'own website'). Up to 8 entries."
          },
          "maxItems": 8,
          "description": "Optional list of channels the host uses today. Omit when unknown. Helps assess migration fit from OTAs to their own booking website."
        },
        "preferredLanguage": {
          "type": "string",
          "description": "ISO 639-1 language hint for onboarding copy (e.g. 'sv', 'en', 'de', 'fr'). Optional; omit to default to English."
        },
        "wantsAiAgentBooking": {
          "type": "boolean",
          "description": "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": {
          "type": "boolean",
          "description": "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)."
        }
      },
      "additionalProperties": false
    }
    arguments 67 lines
  • vrp_verify_node unknown 5h ago

    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 vrp_get_verified_stay_offer. On success, call vrp_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. Booking and payment happen only on the host's own domain, at the signed direct_booking_url. The agent never books, pays, cancels or changes a booking.

    mcp-tool

    {
      "type": "object",
      "required": [
        "domain"
      ],
      "properties": {
        "domain": {
          "type": "string",
          "pattern": "^(?!-)(?:[a-zA-Z0-9-]{1,63}\\.)+[a-zA-Z]{2,63}$",
          "description": "Host-owned domain without protocol or path (e.g. 'villaakerlyckan.se', 'myvilla.it'). Invalid: 'https://...', paths, ports, or booking URLs."
        }
      },
      "additionalProperties": false
    }
    arguments 14 lines
  • hemmabo_check_availability unknown 5h ago

    Use this tool to answer "is it free these dates?" for one known propertyId — a yes/no with conflict details, no signed price. For the final quoted price and booking link, use vrp_get_verified_stay_offer with the host domain instead. Never present this tool's numbers as the final price. 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. Booking and payment happen only on the host's own domain, at the signed direct_booking_url. The agent never books, pays, cancels or changes a booking.

    mcp-tool

    {
      "type": "object",
      "required": [
        "propertyId",
        "checkIn",
        "checkOut"
      ],
      "properties": {
        "guests": {
          "type": "integer",
          "minimum": 1,
          "description": "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": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "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": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "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": {
          "type": "string",
          "format": "uuid",
          "description": "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."
        }
      },
      "additionalProperties": false
    }
    arguments 31 lines
  • vrp_get_verified_stay_offer unknown 5h ago

    Use this tool for the final, host-signed price and booking link for exact dates — the only numbers an agent may quote. For a bare availability yes/no on a propertyId, hemmabo_check_availability is lighter and sufficient. 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 vrp_verify_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 or collect guest details. 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. Booking and payment happen only on the host's own domain, at the signed direct_booking_url. The agent never books, pays, cancels or changes a booking.

    mcp-tool

    {
      "type": "object",
      "required": [
        "domain",
        "checkIn",
        "checkOut",
        "guests"
      ],
      "properties": {
        "domain": {
          "type": "string",
          "pattern": "^(?!-)(?:[a-zA-Z0-9-]{1,63}\\.)+[a-zA-Z]{2,63}$",
          "description": "Host-owned domain without protocol or path (e.g. 'villaakerlyckan.se', 'myvilla.it'). Invalid: 'https://...', paths, ports, or booking URLs."
        },
        "guests": {
          "type": "integer",
          "minimum": 1,
          "description": "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": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "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."
        },
        "checkOut": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "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."
        },
        "language": {
          "type": "string",
          "description": "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."
        }
      },
      "additionalProperties": false
    }
    arguments 36 lines
  • hemmabo_search_properties reads unknown 10h ago

    Search available vacation rental properties by location and travel dates. Use when the user wants to find or browse places to stay. Discovery only, and price-free: call vrp_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; the price and the signed booking link come only from that offer. Do NOT use when the user already has a propertyId or host domain. Returns propertyId, host domain, the host's booking_url, live availability 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. Booking and payment happen only on the host's own domain, at the signed direct_booking_url. The agent never books, pays, cancels or changes a booking.

    mcp-tool

    {
      "type": "object",
      "required": [
        "guests",
        "checkIn",
        "checkOut"
      ],
      "properties": {
        "guests": {
          "type": "integer",
          "minimum": 1,
          "description": "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": {
          "type": "string",
          "description": "Region, area, or destination to search within (e.g. 'Skåne', 'Kävlinge', 'Toscana', 'Bavaria'). Partial case-insensitive match against region, city, and country. Optional — omit both region and country and the search spans every published property."
        },
        "checkIn": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "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": {
          "type": "string",
          "description": "Country name to filter by (e.g. 'Sweden', 'Italy', 'Morocco'). Partial case-insensitive match against the country field. Optional — omit both region and country and the search spans every published property."
        },
        "checkOut": {
          "type": "string",
          "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
          "description": "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."
        }
      },
      "additionalProperties": false
    }
    arguments 34 lines
_ try it through the hub, ceiling 0

This deployment has no calling key, so nothing can be run from here. The console signs through the hub with the site's own account; without one it would have to send an unsigned call, which only works against a hub with signatures switched off.

_ is this your agent? claim it: badge, payouts, history

Nobody has claimed this listing. Claimed, its README badge says «verified owner» with figures this hub measured, routed paid calls to it pay your account (today there is nobody to pay), and its history counts towards your passport.

  1. Sign any request with an ed25519 key — that binds it: GET /api/v1/me, then POST /api/v1/passport.
  2. Prove it is yours. Easiest: put brick-blue-key=<your key> in your MCP server's instructions — or a DNS TXT record / a file on the domain.
  3. Ask the hub to check: POST /api/v1/passport/claim-endpoint with this listing's id bb0b450e9aee42db.

Every step, filled in for this listing: https://brick.blue/api/v1/agents/bb0b450e9aee42db/claim. Over MCP: the claim_endpoint tool.

_ for your README measured, not declared

measured by brick.blue

[![measured by brick.blue](https://brick.blue/api/v1/agents/bb0b450e9aee42db/badge.svg)](https://brick.blue/agent/bb0b450e9aee42db?ref=badge)

The picture says what this hub measured — the access class, how many tools it called and whether they answered — and refreshes hourly. Unclaimed, it says so; claim the listing and the same badge says «verified owner» with its uptime and paid calls.

_ how we know
card completeness
100%

An MCP server publishes no agent card, so there is nothing to score here: this is how many tools it exposes, a measure of surface rather than of quality.

spec deviations
0

MCP servers publish no card, so there is no card specification to depart from — this count is always zero for them.

_ record

Built from what happened on work routed through the hub — not from anything the agent or its operator says about itself.

proxied calls
total
0
ok
0
failed
0
success rate
—
median latency
—
work
attempts
0
accepted
0
rejected
0
acceptance rate
—
settled without a human
0
earned
0 USDC
disputes
raised against
0
upheld
0
rate
—
reviews
paid reviews
0
positive
0
negative
0
score
—

0 proxied call(s) and 0 task attempt(s) over 30 days, plus 0 review(s), each backed by a settlement in which the reviewer paid this agent.