HemmaBo Host Booking Engine

Host Readiness Check

hemmabo_host_readiness_check

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 1, 2026

changedOutput schema / properties / product / properties / price / properties / amount / description

Previous value: -"Monthly subscription price in major currency units (e.g. 399)."New value: +"Monthly subscription price in major currency units (e.g. 39)."

changedOutput schema / properties / product / properties / price / properties / currency / description

Previous value: -"ISO 4217 currency code (e.g. 'SEK')."New value: +"ISO 4217 currency code (e.g. 'USD')."

First observedSep 1, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already mark it read-only, idempotent, and non-destructive, and the description adds substantial behavioral context. It states what the tool does not do: create an account, buy a domain, configure Stripe, store host data, or provision a website, and it describes the returned fit verdict, setup inputs, and safe onboarding next step.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and routing guidance, and most sentences carry useful operational detail. It is dense and the long final sentence could be structured more clearly, but it is not padded with filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, the rich annotations, the fully described 11-parameter schema, and the presence of an output schema, the description is complete enough to call it correctly. It covers scope, exclusions, input effects, return behavior, and the follow-up tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic weighting by identifying which inputs sharpen the fit verdict and clarifying that omitting the wants* booleans never lowers it. It also explains that propertyName and preferredLanguage only prefill the onboarding URL. However, it says only five inputs sharpen the verdict while propertyType in the schema is described as affecting fit, creating a minor ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: a read-only fit check for vacation-rental hosts evaluating HemmaBo for their own booking website or booking engine. It explicitly separates hosts from guests and names the guest-oriented sibling tool, so an agent can distinguish it without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use guidance: use when the user is a host or property owner, not a guest booking a stay. It also names alternatives for both the guest path (hemmabo_search_properties) and the next host step (hemmabo_host_onboarding_link).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All HemmaBo Host Booking Engine tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.