HemmaBo

hemmabo_search_availability

Read-onlyIdempotent

Check a property's availability for specific dates, returning true/false with conflict details and alternative date windows. Confirm before requesting a quote.

Instructions

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 same-month alternative date windows when unavailable; 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.

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	Nearby same-month date windows to offer when the requested dates are unavailable.
`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.

Changed2 schema fields changedv0.1.12Aug 4, 2026

addedOutput schema / properties / calendar_freshness

Added value: +{
+  "additionalProperties": true,
+  "description": "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.",
+  "type": "object"
+}

addedOutput schema / properties / channel_mirror

Added value: +{
+  "additionalProperties": true,
+  "description": "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.",
+  "type": "object"
+}

Changed5 schema fields changedv0.1.6Jun 28, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

addedInput schema / additionalProperties
```
Added value: +false
```
removedInput schema / properties / guests / maximum
```
Removed value: -9007199254740991
```

removedInput schema / properties / propertyId / pattern

Removed value: -"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "alternativeDates": {
+      "description": "Nearby same-month date windows to offer when the requested dates are unavailable.",
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "available": {
+            "type": "boolean"
+          },
+          "checkIn": {
+            "type": "string"
+          },
+          "checkOut": {
+            "type": "string"
+          },
+          "currency": {
+            "type": "string"
+          },
+          "federationDiscountPercent": {
+            "type": "number"
+          },
+          "federationTotal": {
+            "type": "number"
+          },
+          "publicTotal": {
+            "type": "number"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "available": {
+      "description": "True if the property is bookable for the entire range.",
+      "type": "boolean"
+    },
+    "checkIn": {
+      "type": "string"
+    },
+    "checkOut": {
+      "type": "string"
+    },
+    "error": {
+      "description": "Present only when isError=true.",
+      "type": "string"
+    },
+    "propertyId": {
+      "format": "uuid",
+      "type": "string"
+    },
+    "reason": {
+      "description": "Reason when available=false.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "available"
+  ],
+  "type": "object"
+}

Changed4 schema fields changedv0.1.5Jun 15, 2026

changedInput schema / properties / checkIn / description

Previous value: -"Arrival date in ISO 8601 format (YYYY-MM-DD, e.g. '2026-07-15'). Must be today or later."New value: +"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."

changedInput schema / properties / checkOut / description

Previous value: -"Departure date in ISO 8601 format (YYYY-MM-DD, e.g. '2026-07-22'). Must be after checkIn."New value: +"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."

changedInput schema / properties / guests / description

Previous value: -"Optional guest count. When provided, alternative date windows include live pricing."New value: +"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."

changedInput schema / properties / propertyId / description

Previous value: -"Property UUID returned by hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000')."New value: +"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."

Changed1 schema field changedv0.1.3May 19, 2026

changedInput schema / properties / propertyId / description

Previous value: -"Property UUID returned by search.properties (e.g. '550e8400-e29b-41d4-a716-446655440000')."New value: +"Property UUID returned by hemmabo_search_properties (e.g. '550e8400-e29b-41d4-a716-446655440000')."

Addedv0.1.1May 19, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description adds valuable context beyond those: anonymous access with no Bearer token, rate limiting, no holds or date reservations, fail-closed behavior on stale calendar sync, and alignment with the host node's availability API. No contradiction with annotations.

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

Conciseness5/5

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

The description is dense but front-loaded with the core purpose in the first sentence and every subsequent sentence earning its place by covering usage, exclusions, behavior, failure modes, or parameter semantics. Despite its length, it avoids redundancy and reads as a coherent operational guide.

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 that an output schema exists, return-value details need not be spelled out. The description covers when to use, when not to use, authentication, rate-limits, side-effect freedom, parameter-conditional behavior, failure modes, and reliability expectations. Nothing essential for correct invocation is missing.

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

Parameters5/5

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

Schema coverage is 100% with per-parameter descriptions, and the description adds meaning beyond the schema: omitting guests checks dates only, providing guests gates capacity and prices alternative windows, and min_nights_violation guidance distinguishes extending the stay from shifting dates. It also warns to pass the exact property UUID, not a name or URL.

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 opens with a specific verb and resource: 'Check whether a specific property is available for the requested dates.' It clearly differentiates from siblings by explicitly routing general browsing to hemmabo_search_properties and positioning availability checks before quote creation.

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 states exactly when to use the tool: after the user selects a property from hemmabo_search_properties to confirm availability before a quote. It also gives an explicit exclusion: 'Do NOT use for general browsing — use hemmabo_search_properties instead,' leaving no ambiguity about alternatives.

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

Deploy Server