Skip to main content
Glama

Gondola Award Travel Search

by ai.gondola
OverviewDiscussionsAdmin

get_hotel_details

Read-only

Get stored property information for a specific hotel: address, chain and brand, property type, star and guest ratings, all-inclusive and adults-only flags, themes, description, check-in and check-out times and instructions, amenities, photo links, room types with beds, size, max adults, and views, policies, and fees. Content only, with no dates or availability. Long lists are capped and end with a '+N more' count, so an amenity missing here may still exist. Use this after search_hotels when the traveler wants to learn more about a property; use get_hotel_rates for prices.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hotel_idYesThe hotel's Vervotech property ID (returned by search_hotels).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • removedInput schema / properties / checkin
      Removed value: -{
-  "description": "Check-in date in YYYY-MM-DD format.",
-  "type": "string"
-}
    • removedInput schema / properties / checkout
      Removed value: -{
-  "description": "Check-out date in YYYY-MM-DD format.",
-  "type": "string"
-}
    • removedInput schema / properties / num_adults
      Removed value: -{
-  "default": 2,
-  "description": "Number of adult guests.",
-  "type": "integer"
-}
    • changedInput schema / required
      Previous value: -[
-  "hotel_id",
-  "checkin",
-  "checkout"
-]New value: +[
+  "hotel_id"
+]
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "get_hotel_detailsOutput",
+  "type": "object"
+}
  3. Changed10 schema fields changed
    • 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_id / description
      Added value: +"The hotel's Vervotech property ID (returned by search_hotels)."
    • removedInput schema / properties / hotel_id / title
      Removed value: -"Hotel Id"
    • 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: -"get_hotel_detailsArguments"
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "get_hotel_detailsOutput",
-  "type": "object"
-}New value: +null
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, but the description adds important behavioral context: 'Content only, with no dates or availability' and the '+N more' truncation for long lists. This warns the agent about data incompleteness, which is valuable beyond annotations. No contradiction.

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 front-loaded with the core purpose and includes a detailed list of content. Every sentence serves a purpose, and the critical usage guidance appears at the end without cluttering the main message. It is comprehensive without being redundant.

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 an output schema, so return structure is covered. The description covers the input source, the scope (content vs. availability), the truncation behavior, and the sibling distinction. For a single-parameter read-only tool, nothing an agent needs to invoke it correctly 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?

Schema coverage is 100%, and the schema already describes hotel_id as 'The hotel's Vervotech property ID (returned by search_hotels).' The description adds no new semantics beyond that, so it relies on the schema. Baseline 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 states a specific verb ('Get') and resource ('stored property information for a specific hotel') and enumerates the exact attributes returned. It also distinguishes itself from siblings by naming search_hotels as its precursor and get_hotel_rates for prices, making its scope unambiguous.

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?

Explicitly states when to use ('after search_hotels when the traveler wants to learn more about a property') and when not to ('use get_hotel_rates for prices'), plus clarifies it is content-only with no dates/availability. This gives clear routing guidance.

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