Skip to main content
Glama

Best Western Hotels

Search hotels

search_hotels
Read-onlyIdempotent

Search the chain's hotels (worldwide, several thousand) by location, stars, brand, status and amenities, with pagination.

All filters are optional and combined with AND. Always pass `country` (ISO code, e.g. "FR") together with `city`
when the country is known or implied: a search on "Paris" alone returns Paris (Kentucky, US) and
Paris (Ontario, CA) before Paris (France).

Returns {"language", "total", "offset", "limit", "count", "next_offset", "hotels"}: `total` is the number of matching hotels,
`next_offset` is null on the last page. Each hotel is a summary (hotel_id, name, brand, city, country, state,
stars, status, lat, lng, cover_photo); use get_hotel_details for the full record.

Geographic search: give a center (lat + lng, or near_hotel_id) and radius_km. Results are then sorted by
distance, each hotel gets a `distance_km` field and the response a `center` field. Coordinates you supply
for a landmark are approximate, so prefer a generous radius. Hotels without coordinates are excluded.

No availability, rates or booking: this tool only returns descriptive information.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
latNoLatitude of the search center (-90 to 90). Use with `lng` and `radius_km`.
lngNoLongitude of the search center (-180 to 180). Use with `lat` and `radius_km`.
cityNoCity name, partial match ignoring case, accents, hyphens and St/Ste abbreviations (e.g. 'Saint-Étienne' = 'saint etienne' = 'St Etienne'; 'Saint' matches every city containing 'Saint'). If no city matches, the response lists close city names in `city_suggestions`. City names are ambiguous worldwide: combine with `country` whenever the country is known.
brandNoPartial match on the sub-brand, ignoring case and accents (e.g. 'Plus', 'Premier', 'Signature Collection')
limitNoMaximum number of hotels to return (1-100)
offsetNoNumber of matching hotels to skip, for pagination. Pass the `next_offset` value of the previous response.
statusNoHotel status
countryNoISO 3166-1 alpha-2 country code, uppercase (FR, US, CA, DE...). Strongly recommended together with `city` to avoid homonyms (Paris FR vs Paris US/CA).
languageNoLanguage of the multilingual fields of the results. Accepted values: fr, en, de, it, es. A text missing in the requested language is returned in French.fr
min_starsNoMinimum star rating (1-5). Hotels without a star rating are excluded when set. For an exact rating, filter the results on their `stars` field.
radius_kmNoSearch radius in kilometres (up to 200). Required with lat/lng or near_hotel_id.
near_hotel_idNoUse this hotel's coordinates as the search center (instead of lat/lng) to find other hotels around it; the hotel itself is excluded. Use with `radius_km`.
required_amenitiesNoAmenity IDs the hotel must ALL have, uppercase (e.g. ["POOL", "PARKING"]). Unknown IDs raise an error listing the valid ones; the catalogue is also available via get_amenities without hotel_id.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYesNumber of hotels in this page
limitYes
totalYesNumber of hotels matching the filters
centerNoCenter of a geographic search: {lat, lng, radius_km}, plus near_hotel_id if used
hotelsYes
offsetYes
languageYesLanguage of the returned texts
next_offsetYesOffset of the next page, null on the last page
city_suggestionsNoWhen `city` matches no hotel: close city names to retry with

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive/closed-world, so the description's job is to add behavior. It does: distance-sorted results with an added `distance_km` field, hotels lacking coordinates being excluded, approximate landmark coordinates warranting a generous radius, and unknown amenity IDs raising an error listing valid ones. This is well beyond what the annotations convey.

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?

Four tight paragraphs, each with a distinct job (filters/disambiguation, return shape, geographic mode, capability boundary), front-loading the most actionable guidance. Despite the length, no sentence is redundant with the schema or annotations.

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?

The tool has 13 optional parameters and an output schema; the description still summarizes the response envelope (total, next_offset, hotel summary fields) and names the companion tool for detail. For a search tool of this complexity, an agent has everything needed to call it correctly on the first attempt.

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 coverage is 100%, so the baseline is 3, but the description adds real semantics: the country+city homonym rule, the city-fallback `city_suggestions` behavior, and that min_stars excludes unrated hotels rather than acting as an exact-match filter. The only gap is it never mentions the lat/lng/radius_km vs near_hotel_id mutual exclusivity beyond the schema text.

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?

States a specific verb and resource ('Search the chain's hotels'), scopes the corpus ('worldwide, several thousand'), and enumerates the filterable dimensions plus pagination. An agent immediately knows what this tool does and can distinguish it from get_hotel_details, which is explicitly named as the full-record alternative.

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 explicit when-to-use guidance ('Always pass country together with city when the country is known or implied') with the concrete disambiguation example (Paris KY/ON vs Paris FR). It also states exclusions up front: 'No availability, rates or booking' and 'use get_hotel_details for the full record', routing the agent to the right sibling.

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