Skip to main content
Glama

Gondola Award Travel Search

by ai.gondola

search_hotels

Read-only

Search for hotels by location and dates. Returns a list of matching hotels with cash and points rates and deal scores. To produce a focused cash-vs-points decision widget for a hotel the user is considering — for one or several top picks — follow up with compare_rates rather than narrating rates from search results. This tool searches one fixed stay window. If the user asks for a flexible window (for example, 2 nights between September 8 and 22), either ask which check-in date they prefer or pick one concrete window and explicitly tell the user why you chose it; do not silently default to the earliest possible dates. When the user wants date options, use get_multi_night_rates on the top hotel_ids after search_hotels to surface alternate check-in dates where available.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
checkinYesCheck-in date in YYYY-MM-DD format.
checkoutYesCheck-out date in YYYY-MM-DD format.
locationYesCity name, address, or area (e.g. "Tokyo", "Manhattan, New York", "near LAX airport").
chain_nameNoOptional hotel chain filter (e.g. "marriott", "hilton", "hyatt", "ihg"). Case-insensitive substring match against each result's chain. If no result matches, the unfiltered results are returned with an explicit note in the summary so you don't keep retrying with different chain values.
hotel_nameNoOptional hotel name to boost to the top of results (e.g. "Conrad Las Vegas", "Park Hyatt Tokyo"). Use this when the user names a specific hotel — the matching property will be ranked first so you can pass its hotel_id to compare_rates without guessing. Case-insensitive substring match against the property name. Boosting (rather than filtering) preserves nearby alternatives the user may want to see.
num_adultsNoNumber of adult guests.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint/openWorldHint/destructiveHint annotations, the description discloses a key behavioral trait: 'This tool searches one fixed stay window.' It also specifies the return payload ('cash and points rates and deal scores') and the no-silent-default policy for flexible dates, giving the agent behavioral context the annotations alone do not provide.

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 front-loaded with the one-sentence purpose, then layers follow-up routing, a fixed-window constraint, and a flexible-window handling rule in a logical order. Every sentence addresses a distinct decision an agent will face, and there is no filler or restatement of schema content.

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 description covers what the tool returns, how to branch to compare_rates and get_multi_night_rates, and how to handle ambiguous flexible-date requests. With a fully described input schema and an output schema present, nothing needed for correct selection or invocation is missing.

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?

All six parameters are fully described in the input schema (100% coverage), so the schema carries the parameter documentation burden. The description only echoes 'location and dates' and adds no parameter-level detail beyond what the schema already states, so the baseline score of 3 is appropriate.

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: 'Search for hotels by location and dates,' and states exactly what is returned (cash and points rates and deal scores). It also differentiates from sibling tools by explicitly naming compare_rates and get_multi_night_rates as follow-ups rather than describing the same function.

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 direct, actionable routing: use compare_rates for a cash-vs-points decision widget instead of narrating rates, and use get_multi_night_rates on top hotel_ids when the user wants alternate date options. It also provides a concrete rule for flexible stay windows (ask or pick and disclose, never silently default to earliest dates), leaving no ambiguity about when to use this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Gondola Award Travel Search toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation5/5

Each tool targets a distinct resource and action; no two tools have overlapping purposes. For example, search_hotels, get_hotel_details, get_hotel_reviews, and get_hotel_stats all address different aspects of hotel research.

Naming Consistency5/5

Tool names follow consistent patterns: search_ for searches, get_ for retrievals, book_ for bookings, and a few standalone verbs like cancel_, create_, delete_. All use snake_case with no mixing of conventions.

Tool Count4/5

With 31 tools, the server is on the high side but covers a broad domain (hotels, flights, vehicles, loyalty, payments). Most tools are justified, though a few hotel analysis tools could potentially be consolidated.

Completeness3/5

Hotels and vehicles have near-complete lifecycle coverage (search, details, book, manage), but flights are missing a book_flight tool, and hotel cancellation is not present. These gaps limit completeness.

Resources