Skip to main content
Glama

create_booking_intent

Creates a short-lived link where the traveller reviews the full price and terms, signs in or creates an account, and books and pays on autonomad.ai. It creates no reservation and makes no charge: payment and identity checks happen on the website, and bookings are not made inside the chat.

When to use it: after the person has chosen something specific, such as a flight, a hotel, or both for one trip. It is not needed for browsing. intent_type is one of 'flight', 'hotel' or 'trip' — there is no activity, event or experiences link. Activities, experiences and events are chosen as add-ons on autonomad.ai after the person opens a flight, hotel or trip link, so describe them in the reply rather than creating a link for them.

intent_type (choose one):

  • 'flight': the person chose a flight only. offer_data is the flight offer from search_flights, unchanged, plus a top-level passengers number (the TOTAL number of travellers the person asked for; flight offers do not include it). When children or lap infants travel, also add the same adults, children_ages and infants_on_lap used in search_flights, so the booking page asks for each traveller (every traveller's date of birth is entered on autonomad.ai, never here).

  • 'hotel': the person chose a hotel only. offer_data is the hotel offer from search_hotels plus top-level check_in and check_out as YYYY-MM-DD strings (the dates used in the search; hotel offers do not include them, and without them the booking page opens an empty form), and adults and rooms numbers. A hotel from find_hotels_on_route is different: offer_data is that hotel's booking_offer exactly as find_hotels_on_route returned it — copy it whole, never rebuild it from the hotel's name, address or price and never add or drop keys (it already carries check_in, check_out, adults and rooms, and the room to book).

  • 'trip': the person chose a flight and a hotel for the same trip. offer_data is { flight: { ...offer, passengers: }, hotel: { ...offer, adults: , rooms: , check_in, check_out } }. One link covers both, so one intent per trip is enough; two separate links for one trip are confusing.

Include the traveller count in offer_data: without it the booking page defaults to 2 travellers. Travellers can be any age, including children and babies; only the account holder who books and pays must be 18 or older.

What the reply to the person should include: the deep_link as a clickable link, and when the link expires (about 30 minutes by default; a new one can be created if it lapses).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
offer_dataYes
intent_typeYesflight, hotel, or trip (a flight and a hotel together). Activities, experiences and events are added on autonomad.ai after opening one of these links.
expires_minutesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / intent_type / description
      Added value: +"flight, hotel, or trip (a flight and a hotel together). Activities, experiences and events are added on autonomad.ai after opening one of these links."
    • changedInput schema / properties / intent_type / enum
      Previous value: -[
      -  "flight",
      -  "hotel",
      -  "activity",
      -  "event",
      -  "trip",
      -  "experiences"
      -]New value: +[
      +  "flight",
      +  "hotel",
      +  "trip"
      +]
  2. Changed1 schema field changed
    • changedInput schema / properties / intent_type / enum
      Previous value: -[
      -  "flight",
      -  "hotel",
      -  "activity",
      -  "event",
      -  "transport",
      -  "trip",
      -  "experiences"
      -]New value: +[
      +  "flight",
      +  "hotel",
      +  "activity",
      +  "event",
      +  "trip",
      +  "experiences"
      +]
  3. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations set readOnlyHint=false and destructiveHint=false, and the description goes well beyond that: no reservation is made, no charge occurs, payment and identity checks happen on the website, and the link expires in about 30 minutes with a new one creatable. The no-charge/no-reservation claims are consistent with destructiveHint=false rather than contradicting it.

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?

Long, but front-loaded and segmented with bolded labels (when to use, intent_type choices, reply contents) so each block is scannable. Some sentences are dense and repetitive (the no-charge/no-reservation point recurs), but they earn their place given the schema's low coverage.

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?

For a tool with no output schema, the description covers what an agent needs: the required offer_data shape per type, the passenger-count trap that defaults to 2 travellers, the age rule for the account holder, and the instruction to surface deep_link and its expiry in the reply.

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?

Schema coverage is only 33% and offer_data is a free-form nested object, so the description must carry the load — and it does, giving the exact shape for each of the three intent_type values, warning against rebuilding find_hotels_on_route offers, and explaining the passenger/adults/rooms/check_in/check_out additions. Only expires_minutes lacks an explicit definition, but its ~30-minute default is disclosed.

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?

States a specific verb and resource — a short-lived booking link the traveller reviews, signs in for, and pays on autonomad.ai — and immediately clarifies it creates no reservation and takes no payment. It distinguishes itself from siblings by naming search_flights, search_hotels and find_hotels_on_route as inputs and by ruling out activity/event links.

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 it (after the person has chosen a specific flight, hotel, or both for one trip) and when not to (browsing needs none). It also routes the agent away from this tool for activities/experiences/events, telling it to describe them in the reply instead.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources