Skip to main content
Glama

HotelUse - Hotel Metasearch

Search hotels

search_hotels
Read-only

Search a destination or latitude/longitude (with country) for explicit hotel-local dates (including today), or date_intent: tonight. Tonight is resolved server-side in the destination time zone, never UTC. Returns hotel summaries and the lowest eligible full-stay total from Expedia, Booking, Agoda and Brek, with direct provider booking links. Search starts at a 20 km core radius, expanding to 40 km then 60 km while fewer than 50 matching static candidates exist, within the same tool call and deadline. Explicit max_distance_km disables expansion. Providers are queried once after the final candidate scope is chosen. Default order is nearest 5 km distance bands first, then greatest Brek price advantage over the cheapest other provider in each band. The advantage uses comparable full-stay totals in the same currency; missing comparisons go last within their band. Preserve the returned hotel order unless the user requests another sort. Supports star ranges or exact stars, guest-review minimum and review count, facilities, property types, distance and full-stay price budgets. Hotel and rate filters can be combined; budgets cover all nights and requested rooms, including mandatory taxes and fees. Guest scores and hotel star classifications have separate filters. no_matching_offer means prices/terms failed the requested filters, not sold out. Room types and room-level rate plans are not included. No HotelUse account or API credits required. Device detection is automatic with a desktop fallback. For a fresh search supply destination or latitude/longitude with country, and either check_in/check_out or date_intent. Search pagination accepts only quote_session_id and cursor. Omit unknown optional values; do not send null. On follow-ups that change destination, dates, guests, hotel/rate filters or sort, call search_hotels again once with the updated criteria and preserve unchanged itinerary/preferences from the latest relevant search. Do not filter or reorder an earlier result page and present it as a new destination search: that page may omit matching hotels. For nearest, closest, or distance order use sort: distance_asc. The geographic_scope.radius_km value is the search radius, never any hotel’s distance. Per-hotel distance_meters is measured from the destination center. For cheapest hotels use sort: stay_total_asc. For "4-star only" use hotel_filters.star_ratings: [4]; for "4- and 5-star only" use [4,5], not star_rating_min: 4 (which includes 4.5). Never broaden explicit criteria silently. Omit providers unless the user requests specific providers; the server handles occupancy support. A successful partial response is the result of this search: show the returned prices and do not automatically repeat the search to fill missing provider quotes. An explicit user refresh calls the tool again. Pagination with quote_session_id/cursor is only for unchanged criteria.

Input Schema

NameRequiredDescriptionDefault
sortNoFor nearest, closest, or sorting by distance use distance_asc (exact straight-line distance ascending). Default: nearest 5 km distance bands first (0–5, 5–10, 10–15, 15–20 km), then greatest Brek price advantage over the cheapest other provider within each band (other provider total minus Brek total, in context.currency). Only comparable full-stay totals including mandatory taxes and fees qualify. Missing comparisons are last within their band; ties use lowest total, distance and hotel ID. Unpriced hotels are last. distance_price_asc retains lowest-price ordering within the same bands. stay_total_asc sorts all matched hotels by total without distance bands. distance_asc uses straight-line distance; stay_total_desc uses descending whole-stay price; review_score_desc uses the displayed normalized guest score, then review count. Unpriced hotels remain last in every order. Sorting happens before pagination.distance_brek_savings_desc
roomsNo
cursorNoCopy the returned next_cursor exactly. Do not calculate an offset or mix new filters with a quote page.
deviceNoOptional traveler device. Omission uses trusted client hints, then desktop. Room follow-ups inherit the effective search device. Mobile app rates require an approved native-app integration.
localeNoTraveler BCP 47 language, such as en-GB, independent of the destination.
regionNo
countryNo
check_inNoHotel-local calendar date; today is allowed in the destination time zone, even after UTC midnight.
currencyNoRequested display currency. Omission defaults to client visitor country, then locale, then USD.
latitudeNoSearch center latitude. Supply together with longitude. Explicit coordinates take precedence over city/region.
check_outNo
longitudeNoSearch center longitude. Supply together with latitude.
page_sizeNo
providersNo
date_intentNoA one-night stay resolved server-side in the destination or hotel time zone. Mutually exclusive with check_in/check_out.
destinationNo
user_localeNoOptional traveler locale from client context, such as en-GB. Independent of the hotel destination.
rate_filtersNo
hotel_filtersNo
quote_session_idNoCopy the exact quote_session_id from the result being paged.
residency_countryNo
user_location_countryNoOptional traveler country from client context, used for default currency and residency. Independent of the hotel destination.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the read-only/open-world annotations, the description discloses radius expansion behavior, provider query timing, server-side timezone resolution, default ordering rules, partial response semantics, no_matching_offer meaning, and no account/API credit requirement. These are substantial behavioral details an agent needs before invoking the tool.

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?

The description is long but information-dense and front-loads the core search behavior before detailed guidance. Some repetition exists around pagination and follow-up searches, and the single-paragraph structure makes it dense, but most sentences add actionable value for a complex 22-parameter tool.

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, nested filters, and lack of an output schema, the description provides enough context about returned hotel summaries, pricing, booking links, ordering, partial results, and pagination to use the tool correctly. No critical invocation behavior appears missing.

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?

With only 55% schema description coverage across 22 parameters, the description compensates heavily by explaining sort semantics, date_intent, quote_session_id/cursor pagination, star_ratings versus star_rating_min, max_distance_km disabling expansion, provider omission, and full-stay budget meaning. Some parameters such as rooms and page_size receive little explanation, but the critical search semantics are well covered.

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: searching hotels by destination or latitude/longitude for explicit dates or date_intent. It also clarifies that room types and rate plans are not included, which implicitly distinguishes it from get_room_rates and get_hotel.

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 gives extensive when-to-use guidance: fresh searches require destination plus dates or date_intent; follow-ups that change criteria should call search_hotels again; pagination is only for unchanged criteria; sort mappings are provided for nearest, cheapest, and star requests. It also states what not to do, such as filtering/reordering an earlier page or silently broadening explicit criteria.

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