Skip to main content
Glama

EscapeStays by Luxury Lodging

Get availability calendar

get_availability
Read-onlyIdempotent

Open and blocked nights for one property over a date range of up to 93 days. minimum_nights is the smallest positive min_stay value among calendar dates returned in that range. It is a hint; individual arrival dates may require more. This result shows which alternative dates are open but does not price or confirm a stay. An exact quote determines eligibility and price for a specific stay.

Input Schema

NameRequiredDescriptionDefault
end_dateYesLast date to check, YYYY-MM-DD. At most 93 days after start_date.
start_dateYesFirst date to check, YYYY-MM-DD.
property_idYesProperty id or slug.

Output Schema

NameRequiredDescriptionDefault
noteYes
end_dateYes
open_datesYesYYYY-MM-DD nights that are open. They still have to satisfy minimum stay and arrival rules.
start_dateYes
nights_openYes
property_idYes
blocked_datesYes
minimum_nightsNoThe smallest positive min_stay value among calendar dates returned for the requested range. It is a hint, not a guarantee that every arrival is allowed. An exact quote checks a specific stay.
nights_blockedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / minimum_nights / description
      Added value: +"The smallest positive min_stay value among calendar dates returned for the requested range. It is a hint, not a guarantee that every arrival is allowed. An exact quote checks a specific stay."
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "blocked_dates": {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "end_date": {
      +      "type": "string"
      +    },
      +    "minimum_nights": {
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "nights_blocked": {
      +      "type": "integer"
      +    },
      +    "nights_open": {
      +      "type": "integer"
      +    },
      +    "note": {
      +      "type": "string"
      +    },
      +    "open_dates": {
      +      "description": "YYYY-MM-DD nights that are open. They still have to satisfy minimum stay and arrival rules.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "property_id": {
      +      "type": "integer"
      +    },
      +    "start_date": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "property_id",
      +    "start_date",
      +    "end_date",
      +    "nights_open",
      +    "nights_blocked",
      +    "open_dates",
      +    "blocked_dates",
      +    "note"
      +  ],
      +  "type": "object"
      +}
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "properties": {
      -    "blocked_dates": {
      -      "items": {
      -        "type": "string"
      -      },
      -      "type": "array"
      -    },
      -    "end_date": {
      -      "type": "string"
      -    },
      -    "minimum_nights": {
      -      "type": [
      -        "number",
      -        "null"
      -      ]
      -    },
      -    "nights_blocked": {
      -      "type": "integer"
      -    },
      -    "nights_open": {
      -      "type": "integer"
      -    },
      -    "note": {
      -      "type": "string"
      -    },
      -    "open_dates": {
      -      "description": "YYYY-MM-DD nights that are open. They still have to satisfy minimum stay and arrival rules.",
      -      "items": {
      -        "type": "string"
      -      },
      -      "type": "array"
      -    },
      -    "property_id": {
      -      "type": "integer"
      -    },
      -    "start_date": {
      -      "type": "string"
      -    }
      -  },
      -  "required": [
      -    "property_id",
      -    "start_date",
      -    "end_date",
      -    "nights_open",
      -    "nights_blocked",
      -    "open_dates",
      -    "blocked_dates",
      -    "note"
      -  ],
      -  "type": "object"
      -}New value: +null
  4. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "blocked_dates": {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "end_date": {
      +      "type": "string"
      +    },
      +    "minimum_nights": {
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "nights_blocked": {
      +      "type": "integer"
      +    },
      +    "nights_open": {
      +      "type": "integer"
      +    },
      +    "note": {
      +      "type": "string"
      +    },
      +    "open_dates": {
      +      "description": "YYYY-MM-DD nights that are open. They still have to satisfy minimum stay and arrival rules.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "property_id": {
      +      "type": "integer"
      +    },
      +    "start_date": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "property_id",
      +    "start_date",
      +    "end_date",
      +    "nights_open",
      +    "nights_blocked",
      +    "open_dates",
      +    "blocked_dates",
      +    "note"
      +  ],
      +  "type": "object"
      +}
  5. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover the safe-read profile (readOnly, idempotent, non-destructive). The description adds genuinely non-structured behavior: the 93-day range ceiling, that minimum_nights is a hint rather than a guarantee, and that results are non-binding. It does not mention rate limits or response shape, but coverage is solid.

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?

Front-loaded with scope, then the caveat about minimum_nights, then the boundary with quoting tools. Four sentences with almost no waste, though the 'does not price or confirm a stay' idea is slightly restated in the closing sentence.

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?

For a read-only availability tool with an output schema present, the description supplies everything an agent needs: the hard range limit, the semantics of the returned minimum_nights value, and the explicit boundary that pricing/confirmation belong elsewhere.

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 coverage is 100%, so start_date, end_date and property_id are already documented, including the 93-day cap the description restates. The description adds no parameter-level detail (e.g. slug vs id tradeoffs) beyond what the schema provides, so the baseline 3 applies.

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 first sentence gives a specific verb and resource: open and blocked nights for one property over a bounded date range. Combined with 'does not price or confirm a stay', an agent can immediately separate this from get_live_quote and get_booking_link without opening a schema.

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

Usage Guidelines4/5

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

It clearly states the context of use — browsing which alternative dates are open — and explicitly rules out pricing/confirmation, pointing at 'an exact quote' as the tool that determines eligibility. It never names get_live_quote directly, so the routing is implied rather than spelled out.

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.

Resources