Skip to main content
Glama

book_hotel

Destructive

Complete a hotel booking by providing a rate ID and payment method. Optionally include guest details, travel profile, or loyalty account.

Instructions

Book a hotel room using a rate from get_hotel_details.

Requires a Gondola account (API key) and a saved payment method.
Use get_payment_methods to find your payment ID.

The gondola_rate_id comes from the room rates returned by get_hotel_details —
each room option has a rate ID you can use here.

Guest details (given_name, family_name, email_address, phone_number) can either be
passed directly or prefilled from a saved travel profile: pass travel_profile_id
(from get_travel_profiles) to book "as <traveler>" without collecting each field.
Any field you also pass explicitly overrides the profile.

To earn points and elite credit, pass loyalty_account_id — use the Member Number from
get_loyalty_accounts that matches the hotel's chain (e.g. the World of Hyatt account
for a Hyatt property). When a loyalty_account_id is passed, the booking goes out under
the email registered to that membership (overriding any travel profile or email_address),
so the stay credits to the right account.

Args:
    gondola_rate_id: The rate ID from get_hotel_details room rates.
    payment_id: Payment method ID from get_payment_methods.
    given_name: Guest's first name (optional if travel_profile_id is provided).
    family_name: Guest's last name (optional if travel_profile_id is provided).
    email_address: Guest's email for confirmation (optional if travel_profile_id is provided).
    phone_number: Guest's phone number with country code (optional if travel_profile_id is provided).
    special_request: Optional special request for the hotel (e.g. "high floor", "late check-in").
    loyalty_account_id: Optional Member Number (from get_loyalty_accounts) to earn points.
    travel_profile_id: Optional travel profile ID (from get_travel_profiles) to prefill guest details.

Returns:
    Booking confirmation with ID and details, or an error message.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
given_nameNo
payment_idYes
family_nameNo
phone_numberNo
email_addressNo
gondola_rate_idYes
special_requestNo
travel_profile_idNo
loyalty_account_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by stating it creates a booking. Adds behavioral context: rate ID source, payment method requirement, loyalty account override, and error message return. No contradictions.

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 well-structured with a clear first paragraph (purpose and prerequisites) followed by detailed parameter explanations. While somewhat lengthy, every sentence is informative and avoids redundancy. Could be slightly more concise, but structure is effective.

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?

Given the tool's complexity (9 parameters, dependencies on multiple sibling tools, and destructive nature), the description is thorough. It covers all prerequisites, parameter interdependencies (e.g., travel_profile_id and loyalty_account_id overrides), and the return type. An output schema exists, so the brief return description is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by explaining each parameter's meaning, source, and optionality. For example, it clarifies that gondola_rate_id comes from get_hotel_details room rates, and loyalty_account_id overrides email. This adds significant value beyond the bare schema.

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 explicitly states the tool books a hotel room using a rate from get_hotel_details. It clearly differentiates from sibling tools like book_vehicle and cancel_vehicle_booking. The verb 'book' and resource 'hotel room' are specific and 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?

Provides detailed usage context: requires Gondola account (API key), saved payment method, and rate ID from get_hotel_details. Explains alternatives like using travel_profile_id to prefill guest details, and loyalty_account_id to earn points. Explicitly mentions when not to use (e.g., if no account) and references sibling tools for prerequisites.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gondola-ai/gondola-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server