HemmaBo

Check Availability

hemmabo_check_availability

Read-only

Check if a specific vacation rental property is available for chosen check-in and check-out dates. Returns a yes/no verdict with conflict details and alternative dates before a quote.

Instructions

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.

Input Schema

TableJSON Schema

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

TableJSON 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	The host node's own next available window (at most one) to offer when the requested dates are unavailable — identical to the node's /api/availability nextAvailable. Empty when the node offers none.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv7.0.5Oct 14, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover read-only/non-destructive, but the description adds substantial context beyond them: anonymous access with no Bearer token, rate limiting, no hold or reservation ever placed, fail-closed behavior on stale inbound calendar sync (calendar_freshness), and the exact failure reasonCodes (guests_exceed_max, min_nights_violation). It also clarifies that booking and payment happen only on the host domain, giving the agent a complete behavioral picture.

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 routing and never-present-as-price warnings are front-loaded, and most sentences carry unique constraints. There is mild redundancy between 'the same window the node's /api/availability reports' and the later 'verdict always matches the host node's own availability API,' and the block is long, but it is dense with non-repeating rules rather than 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?

An output schema exists so return values need not be spelled out, yet the description still summarizes the key response semantics (available=true/false with conflict details, at most one alternativeDates window). Combined with the auth, rate-limit, capacity, and min-nights rules, an agent has everything required to invoke it correctly and interpret the result.

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 baseline is 3, but the description adds real meaning beyond it: omitting guests checks dates only, and passing it both prices alternative windows and gates capacity, with counts above the property maximum returning available=false. It also ties checkIn/checkOut to stay length and the min-nights rule, though it does not add format detail to propertyId beyond the schema.

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?

States a specific verb and resource ('Check whether a specific property is available for the requested dates') and frames it as the yes/no availability question for one known propertyId. It distinguishes itself from hemmabo_search_properties (browsing) and vrp_get_verified_stay_offer (signed price/booking link) without the agent needing to open either 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?

Explicitly names when to use it (after the user selects a property and wants to confirm availability before a quote) and when not to (general browsing -> hemmabo_search_properties; final price -> vrp_get_verified_stay_offer). It also instructs the agent to never present this tool's numbers as the final price, which is a concrete routing constraint.

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

Deploy Server