Skip to main content
Glama

Hotel & Vacation Rental MCP - live prices & reviews across Booking, Airbnb, Vrbo & Google Hotels

Check listing availability

check_availability
Read-onlyIdempotent

Day-by-day availability for known listing(s) on one platform over a date range.

Input Schema

NameRequiredDescriptionDefault
urlNoA listing URL (alternative to listingId). For Vrbo, use the url from search_stays (it carries expediaPropertyId=).
countryNoISO-3166 alpha-2 country hint (booking) — pass the search result location.country with a bare booking.com slug.
endDateNoWindow end, YYYY-MM-DD.
platformYesThe platform the listing belongs to.
listingIdNoA single listing id: the platformListingId from search_stays. For Vrbo this is required — the number in a vrbo.com address is a different id and is rejected.
startDateNoWindow start, YYYY-MM-DD.
listingIdsNoMultiple listing ids (same rule as listingId). Airbnb: ONE listing per call (call once per listing). Vrbo: at most 12 per call; split larger batches. Vrbo answers rentals only (hotel-type listings return no dates).
onlyAvailableNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / listingIds / description
      Previous value: -"Multiple listing ids (same rule as listingId). Vrbo: at most 12 per call; split larger batches. Vrbo answers rentals only (hotel-type listings return no dates)."New value: +"Multiple listing ids (same rule as listingId). Airbnb: ONE listing per call (call once per listing). Vrbo: at most 12 per call; split larger batches. Vrbo answers rentals only (hotel-type listings return no dates)."
  2. Changed4 schema fields changed
    • addedInput schema / properties / country
      Added value: +{
      +  "description": "ISO-3166 alpha-2 country hint (booking) — pass the search result location.country with a bare booking.com slug.",
      +  "type": "string"
      +}
    • changedInput schema / properties / listingId / description
      Previous value: -"A single listing id."New value: +"A single listing id: the platformListingId from search_stays. For Vrbo this is required — the number in a vrbo.com address is a different id and is rejected."
    • changedInput schema / properties / listingIds / description
      Previous value: -"Multiple listing ids."New value: +"Multiple listing ids (same rule as listingId). Vrbo: at most 12 per call; split larger batches. Vrbo answers rentals only (hotel-type listings return no dates)."
    • changedInput schema / properties / url / description
      Previous value: -"A listing URL (alternative to listingId)."New value: +"A listing URL (alternative to listingId). For Vrbo, use the url from search_stays (it carries expediaPropertyId=)."
  3. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the day-by-day granularity and single-platform constraint, but says nothing about rate limits, failure behavior for invalid ids, or response shape.

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?

A single front-loaded sentence with no filler; every clause (day-by-day, known listings, one platform, date range) constrains the call meaningfully.

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

Completeness3/5

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

For an 8-parameter, multi-platform tool with no output schema and platform-specific edge cases handled only in the schema, the description is thin: it omits the search-then-check workflow and any notion of what a result looks like.

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

Parameters3/5

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

Schema description coverage is 88%, so the schema itself carries the parameter meaning, including the platform-specific rules for listingIds. The description only echoes 'known listing(s)' and 'one platform', adding no syntax or format detail beyond the schema, matching the baseline 3.

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

Purpose4/5

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

States a specific verb+resource ('Day-by-day availability') with scope qualifiers (known listing(s), one platform, date range). The word 'known' implicitly routes discovery to search_stays, but it never names that sibling, so differentiation is partial.

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

Usage Guidelines3/5

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

'Known listing(s)' implies this runs after a search and not for discovery, which is a useful hint. However, it never states the alternative explicitly (search_stays) nor the prerequisite that listingId/platformListingId must come from a prior search.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.