Skip to main content
Glama

Find a price for flexible dates

get_stay_estimate

Find a dated price example for a published home when travel dates are flexible and the traveler supplied windowStart/windowEnd, nights and guests. Ask for missing details before requesting or showing any price; never substitute a default party or stay. Use the returned stayQuote.estimate to join a pending sample search. Checks at most four stays inside windowStart/windowEnd, through supported public readers only; narrow windows try weekly samples and broad windows try upcoming months. Preserve any requested flexible month or range. Nights, guests and currency stay fixed. Returns the actual selected request and quote; a sample never proves availability for other dates or the lowest price. If no suitable stay is found, quote is null and overall availability is unknown; diagnostics retain the attempted-stay count and last observed reason. Do not retry a completed unsupported host or upstream failure unchanged. When price is requested, finish checks for at most three promising shortlisted homes; do not check every card. Explicit travel dates must use get_stay_quote instead. Optional startingNightlyPrice is an advertised nightly starting rate only, with no confirmed dates, guest basis, fees or taxes; never multiply it into a stay total. No booking, payment or guest contact details. After displaying cards, default to 1–3 short sentences, usually under 60 words unless the traveler requests a detailed comparison: explain a helpful fit or next choice, and include only a material price/availability caveat or a necessary question. Do not repeat result counts, card facts or the home list unless the traveler asks for a textual comparison. Do not narrate tools called or not called, backend mechanics, or your process. Keep operational checks internal; disclose material uncertainty and pricing assumptions plainly when they affect the traveler’s decision.

Input Schema

NameRequiredDescriptionDefault
idYes
guestsYes
nightsYes
currencyNo
windowEndYes
windowStartYes

Output Schema

NameRequiredDescriptionDefault
basisYes
quoteYes
statusYes
requestYes
estimateYes
diagnosticsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / currency / enum
      Previous value: -[
      -  "USD",
      -  "EUR",
      -  "GBP",
      -  "CRC",
      -  "MXN",
      -  "COP",
      -  "PEN",
      -  "BRL"
      -]New value: +[
      +  "USD",
      +  "EUR",
      +  "GBP",
      +  "CRC",
      +  "MXN",
      +  "COP",
      +  "PEN",
      +  "BRL",
      +  "AUD"
      +]
    • changedOutput schema / properties / estimate / properties / currency / enum
      Previous value: -[
      -  "USD",
      -  "EUR",
      -  "GBP",
      -  "CRC",
      -  "MXN",
      -  "COP",
      -  "PEN",
      -  "BRL"
      -]New value: +[
      +  "USD",
      +  "EUR",
      +  "GBP",
      +  "CRC",
      +  "MXN",
      +  "COP",
      +  "PEN",
      +  "BRL",
      +  "AUD"
      +]
    • changedOutput schema / properties / request / properties / currency / enum
      Previous value: -[
      -  "USD",
      -  "EUR",
      -  "GBP",
      -  "CRC",
      -  "MXN",
      -  "COP",
      -  "PEN",
      -  "BRL"
      -]New value: +[
      +  "USD",
      +  "EUR",
      +  "GBP",
      +  "CRC",
      +  "MXN",
      +  "COP",
      +  "PEN",
      +  "BRL",
      +  "AUD"
      +]
  2. Changed1 schema field changed
    • addedOutput schema / properties / diagnostics
      Added value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "attemptedStays": {
      +      "maximum": 4,
      +      "minimum": 0,
      +      "type": "integer"
      +    },
      +    "reason": {
      +      "description": "Last sampled observation when no dated total was selected. Applies only to attempted stays; blocked samples never establish that the whole window is sold out. Terminal unsupported_host/upstream_unavailable evidence should be explained, not retried unchanged.",
      +      "enum": [
      +        "checked",
      +        "blocked_dates",
      +        "minimum_stay",
      +        "maximum_stay",
      +        "arrival_departure_rules",
      +        "advance_notice",
      +        "capacity",
      +        "unsupported_host",
      +        "browser_unconfigured",
      +        "upstream_unavailable",
      +        "date_range_unknown"
      +      ],
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "attemptedStays"
      +  ],
      +  "type": "object"
      +}
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare the generic profile (readOnlyHint=false, openWorldHint=true, non-idempotent, non-destructive), so the description carries real weight and delivers: sampling caps (at most four stays, weekly samples for narrow windows, upcoming months for broad), the estimate's purpose (join a pending sample search), null-quote/unknown-availability semantics, retained diagnostics, and the 'a sample never proves availability or lowest price' caveat. It also discloses the no-booking/no-contact boundary.

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?

Purpose is front-loaded correctly, but the body is a long, dense run-on block that mixes invocation contract with response-formatting policy ('default to 1–3 short sentences, usually under 60 words', 'do not narrate tools called'), which arguably belongs in prompt guidance rather than the tool definition. The excess dilutes the actionable content an agent needs at call time.

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

Completeness4/5

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

For a complex open-world sampling tool with an output schema present, the description covers the operational essentials: what triggers it, what it checks, what the returned estimate means, and what happens on miss. Return-shape details are largely delegated to the output schema, and the only mismatch is the startingNightlyPrice reference that does not appear in the input schema.

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 description coverage is 0%, so the description must compensate, and it does explain the meaning of windowStart/windowEnd (a flexible sampling window, preserved when a month/range was requested), nights and guests ('never substitute a default party or stay'), and that currency stays fixed. It does not document per-parameter constraints (nights max 30, guests max 200) or clarify the 'id' parameter, and it references an optional startingNightlyPrice that is not present in the input schema, which slightly muddies the mapping.

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?

Opens with a specific verb+resource ('Find a dated price example for a published home') and pins the exact preconditions (flexible dates, windowStart/windowEnd, nights, guests). It also explicitly contrasts itself with the sibling get_stay_quote for explicit dates, so an agent can route between them without opening 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?

Gives when-to-use (flexible window, price requested on shortlisted homes), when-not-to-use (explicit dates must use get_stay_quote), and operating constraints ('finish checks for at most three promising shortlisted homes; do not check every card'). It also states a retry exclusion: 'Do not retry a completed unsupported host or upstream failure unchanged.' This is unusually complete routing guidance.

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