Skip to main content
Glama

Gondola Award Travel Search

by ai.gondola
OverviewDiscussionsAdmin

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "search_hotelsOutput",
+  "type": "object"
+}
  2. Changed19 schema fields changed
    • removedInput schema / properties / chain_name / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / chain_name / default
      Removed value: -null
    • addedInput schema / properties / chain_name / description
      Added value: +"Optional 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."
    • removedInput schema / properties / chain_name / title
      Removed value: -"Chain Name"
    • addedInput schema / properties / chain_name / type
      Added value: +"string"
    • addedInput schema / properties / checkin / description
      Added value: +"Check-in date in YYYY-MM-DD format."
    • removedInput schema / properties / checkin / title
      Removed value: -"Checkin"
    • addedInput schema / properties / checkout / description
      Added value: +"Check-out date in YYYY-MM-DD format."
    • removedInput schema / properties / checkout / title
      Removed value: -"Checkout"
    • addedInput schema / properties / hotel_name
      Added value: +{
+  "description": "Optional 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.",
+  "type": "string"
+}
    • removedInput schema / properties / limit
      Removed value: -{
-  "default": 20,
-  "title": "Limit",
-  "type": "integer"
-}
    • addedInput schema / properties / location / description
      Added value: +"City name, address, or area (e.g. \"Tokyo\", \"Manhattan, New York\", \"near LAX airport\")."
    • removedInput schema / properties / location / title
      Removed value: -"Location"
    • removedInput schema / properties / loyalty_points
      Removed value: -{
-  "anyOf": [
-    {
-      "additionalProperties": {
-        "type": "integer"
-      },
-      "type": "object"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Loyalty Points"
-}
    • removedInput schema / properties / loyalty_programs
      Removed value: -{
-  "anyOf": [
-    {
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Loyalty Programs"
-}
    • addedInput schema / properties / num_adults / description
      Added value: +"Number of adult guests."
    • removedInput schema / properties / num_adults / title
      Removed value: -"Num Adults"
    • removedInput schema / title
      Removed value: -"search_hotelsArguments"
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "search_hotelsOutput",
-  "type": "object"
-}New value: +null
  3. First observed

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
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources