HemmaBo

Host Onboarding Link

hemmabo_get_host_onboarding_link

Read-only

Generate a prefilled onboarding URL for vacation-rental hosts ready to launch their own booking website or booking engine.

Instructions

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.

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

TableJSON Schema

Name	Required	Description
`ok`	Yes
`product`	Yes	HemmaBo: the category sentence, the host's subscription price atom ($39/month; the host pays it, a guest never does), and the onboarding URL.
`next_step`	Yes	Safe handoff action for the host.
`agent_role`	Yes	What a compatible agent does: discover the host domain, verify the signed stay offer, send the guest to that domain to book. The agent does not book.
`setup_items`	Yes	Inputs the host should prepare before onboarding.
`privacy_note`	No	Clarifies that the call is read-only and does not store host data.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv7.0.5Oct 14, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already cover the read-only/non-destructive profile, but the description adds substantial context: it does not create an account, buy a domain, configure Stripe, write to Supabase, or provision a site; it lists what is returned (URL, category sentence, price atom, role, preparation items); nothing is stored server-side; and booking/payment only occur on the host's own domain. This is rich disclosure 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.

Conciseness3/5

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

The content is valuable but the readiness alternative is stated twice in near-identical terms ('it returns the same onboarding URL in next_step' / 'it already returns the same prefilled URL in its next_step'), which is redundant. The purpose statement is also buried in the middle rather than front-loaded, so the definition reads longer than necessary.

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?

With annotations carrying the safety profile, a fully described 6-param schema, and an output schema, the description still covers prerequisites, exclusions, side-effect boundaries, and what the result contains. Nothing an agent needs to call it correctly is missing.

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 collective semantics: all parameters are optional prefill, they never change where the host lands, blank values are simply omitted, and nothing is persisted. That clarifies the intent of the parameters beyond the per-field schema text.

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 — it returns a HemmaBo onboarding handoff URL for a vacation-rental host — and explicitly carves out what it is not (not for guests) and which sibling it corresponds to. An agent can distinguish it from hemmabo_check_host_readiness and hemmabo_search_properties without opening any 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 (host has already decided to start, or asks to start), when-not (host still evaluating), and the exact alternative (hemmabo_check_host_readiness), plus a hard constraint not to call both in the same turn. Routing is unambiguous.

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

Deploy Server