Skip to main content
Glama
gondola-ai

Gondola AI

by gondola-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript

get_booking_link

Read-only

Generate a checkout link for a selected hotel and dates. Use after searching hotels to let travelers review rooms and complete payment on Gondola's web checkout.

Instructions

Get booking options for a hotel.

Returns a link to Gondola's checkout for this hotel, where the traveler reviews the room
and completes payment on the web. This is the booking path for this connection.

(Connections belonging to an approved booking partner — which requires the mcp:book OAuth
scope — additionally get an in-conversation option here. If you don't see booking tools in
your tool list, this connection isn't one of those, and the link is the way to book.)

Use this after search_hotels or get_hotel_details when a user wants to book.
Pass ``gondola_rate_id`` whenever a specific rate has been surfaced (from
get_hotel_details or compare_rates) so the link lands on that rate's
checkout page instead of the generic hotel page.

Args:
    hotel_id: The hotel's Vervotech property ID (from search_hotels results).
    checkin: Check-in date in YYYY-MM-DD format.
    checkout: Check-out date in YYYY-MM-DD format.
    num_adults: Number of adult guests. Defaults to 2.
    children_ages: Comma-separated ages of children (e.g. "5,8"). Empty string if no children.
    gondola_rate_id: Optional rate ID from get_hotel_details/compare_rates. When provided,
        the link deep-links straight to that rate's checkout page.

Returns:
    Booking instructions tailored to the user's auth status.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
checkinYes
checkoutYes
hotel_idYes
num_adultsNo
children_agesNo
gondola_rate_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already indicate readOnlyHint=true (safe, no side effects) and destructiveHint=false. The description adds value by explaining the booking path: it returns a link to an external checkout page, and behavior varies by auth status (OAuth scope). It doesn't contradict annotations; it complements them with context about the external redirection and auth-dependent behavior.

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 longer but well-structured: it starts with the core purpose, then context, usage sequence, and parameter details. No fluff, each sentence adds value. Minor redundancy in repeating format for checkin/checkout could be trimmed but is not excessive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present (though not provided fully here), the description doesn't need to detail return structure. It covers prerequisites (prior search), optional parameters, and auth-dependent behavior. Gaps: doesn't mention error cases or what happens if hotel_id is invalid, but these are minor given the richness of the description and annotations.

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 0%, so the description must compensate, and it does. It explains each parameter's purpose: hotel_id as Vervotech property ID, checkin/checkout formats, num_adults default, children_ages format, and gondola_rate_id's deep-linking behavior. This adds meaningful semantics beyond the bare schema types.

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 clearly states it gets booking options and returns a checkout link for a hotel, distinguishing it from siblings like get_booking (which likely retrieves existing bookings) and get_vehicle_booking_link (vehicle-specific). The verb 'get' plus resource 'booking link' is specific and the scope is 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 says to use after search_hotels or get_hotel_details when the user wants to book, and mentions when to pass gondola_rate_id (when a specific rate is surfaced). It also notes the OAuth scope requirement for the in-conversation booking alternative, providing clear when-to-use and when-not-to-use guidance.

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

Deploy Server

Other Tools