Skip to main content
Glama

Search stays

search_stays
Read-onlyIdempotent

Returns bookable hotels with photos, guest scores, policies, member rates and a Book link, with or without dates. For questions about hotels, stays, where to sleep, resorts or neighbourhoods to stay in. Returns the top 10 by default (limit up to 50, offset to page), nearest distance band first, then guest score, each with hotel_id, whole-stay price and book_link, plus total_available, has_more and next. Reads only; nothing is booked. With no dates it uses a labelled sample window and returns needs: ["dates"]: show the hotels, then ask for dates. Filters apply after ranking and the result names those applied. Use get_stay_details for one hotel in depth, compare_stays for 2 to 4 side by side.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "city": "<city>"
    },
    "name": "search_stays"
  }
}

Input Schema

NameRequiredDescriptionDefault
areaNoA neighbourhood to centre on, e.g. a name from get_trip's next.areas; distance_km is then from it. An unknown name falls back to the whole city and the note says so.
cityYesCity or town, e.g. Lisbon.
sortNobest (default: nearest band, then guest score), price_low, price_high, rating (guest score), distance (from the centre or area).
limitNoHow many stays to return, up to 50 (default 10). Use more than 10 only when the traveller asks.
adultsNoNumber of adults, 1 to 8. Optional: the trip's party when a trip is in the session, else 2.
budgetNoPrice band: budget, mid or luxury.
offsetNoSkip this many ranked stays (default 0). For 'more', pass the previous offset plus limit.
checkinNoCheck-in date, YYYY-MM-DD. Optional: leave out when the traveller gave no dates (a sample window is used and labelled).
countryNoCountry name, e.g. Portugal. Send it when known; it keeps same-named cities apart.
trip_idNoThe trip's id (trip_id), as returned by start_trip or list_trips. Optional: that trip's stop in this city supplies the dates and party (else the signed-in traveller's latest trip with a stop here).
checkoutNoCheck-out date, YYYY-MM-DD, at least one night after checkin. Optional.
describeNoThe kind of stay in words, e.g. 'quiet boutique near the old town with a rooftop pool'. Matches by meaning; results come in best-match order.
amenitiesNoEvery one listed must be present (the app's amenity chips).
min_starsNoStar rating floor, like the app's 4+ stars chip. A hotel with no star rating fails it.
intent_refNoThe reference at the end of a chat line an Adonde card posted, e.g. K7Q2MD from "Code: K7Q2MD." (older cards: "(ref K7Q2MD)"). Pass it on its own: the card's exact arguments load on our side. Add only what the line says is still missing (for a route, the travellers).
max_per_nightNoNightly ceiling in the search currency. If nothing fits, the cheapest ten come back with a note.
min_per_nightNoNightly floor in the search currency.
property_typeNoKind of property, when the provider states it; otherwise the result says it was not applied.
refundable_onlyNoFree cancellation only; the price shown is the cheapest refundable rate.
min_guest_ratingNoGuest score floor on the 0 to 10 scale (9 wonderful, 8 very good, 7 good).
breakfast_includedNoOnly rates that include breakfast; the price shown is the cheapest such rate.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare read-only, open-world, idempotent, non-destructive behavior, and the description reinforces this with 'Reads only; nothing is booked.' Beyond that, it discloses ranking order, pagination fields, the sample-window fallback when dates are absent, the needs: ["dates"] flow, and that filters apply after ranking and are named in the result.

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 appropriately sized for a 21-parameter search tool. Purpose and key behavior are front-loaded, and each sentence contributes routing, return-shape, pagination, fallback, or alternative-tool guidance.

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 the tool's complexity, high schema coverage, and absence of an output schema, the description is complete enough for correct invocation. It covers return fields, paging behavior, date fallback, ranking, filter application, and sibling-tool routing.

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 100%, so the baseline is 3. The description adds some useful context such as limit up to 50 and offset paging, but most parameter meaning is already fully specified in 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?

It states a specific verb and resource: returns bookable hotels with photos, guest scores, policies, member rates, and a Book link, with or without dates. It also names the user questions it answers and explicitly distinguishes itself from get_stay_details and compare_stays.

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?

The description gives clear when-to-use guidance for hotel/stay/neighbourhood questions and explicitly names alternatives: get_stay_details for one hotel in depth and compare_stays for 2 to 4 side by side. It also explains the no-dates fallback and what the agent should do next.

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