travel

create_booking_intent

Creates a short-lived link where the traveler 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 from search_flights, unchanged, with the CHOSEN fare: when the person picked a fare other than the first in fare_options, set offer_id, price_usd, fare_brand and cabin_class to that fare option's values (the booking page opens exactly that fare). Plus a top-level passengers number (the TOTAL number of travelers 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 traveler (every traveler'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 (with the chosen fare, as for 'flight'), 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 traveler count in offer_data: without it the booking page defaults to 2 travelers. Travelers 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).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "intent_type": "<intent_type>",
      "offer_data": "<offer_data>"
    },
    "name": "create_booking_intent"
  }
}

Input Schema

Name	Required	Description
`offer_data`	Yes
`intent_type`	Yes	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.
`expires_minutes`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 20, 2026

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"
+]

Changed1 schema field changedSep 9, 2026

changedInput schema / properties / intent_type / enum

Previous value: -[
-  "flight",
-  "hotel",
-  "activity",
-  "event",
-  "transport",
-  "trip",
-  "experiences"
-]New value: +[
+  "flight",
+  "hotel",
+  "activity",
+  "event",
+  "trip",
+  "experiences"
+]

First observedMay 11, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description goes well beyond by stating no reservation is made, no charge occurs, payment and identity verification happen on the website, and the account holder must be 18+. It also discloses link lifetime (~30 min default, recreatable) and that two links per trip should be avoided, which implicitly covers the non-idempotent behavior flagged by idempotentHint=false.

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?

Front-loaded with purpose then usage then per-intent_type construction, which is the right order for a complex tool. It is long and slightly repetitive around the no-charge/no-booking guarantee, but nearly every sentence carries operational detail that would otherwise cause a malformed offer_data.

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?

No output schema exists, and the description compensates by telling the agent exactly what the reply must contain (the deep_link as a clickable link plus the expiry time). Combined with the field-level offer_data rules and the traveler-count default warning, an agent has everything needed to invoke this correctly and report the result.

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 bare untyped object, so the description carries the burden and does: it specifies offer_data construction per intent_type, the chosen-fare override fields (offer_id, price_usd, fare_brand, cabin_class), the required top-level passengers/adults/rooms/check_in/check_out, and the special rule to copy booking_offer verbatim from find_hotels_on_route. The only soft spot is expires_minutes, which is only implied by the 'about 30 minutes by default' remark.

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 opening sentence names a specific verb and artifact: it creates a short-lived link where the traveler reviews price/terms and pays on autonomad.ai. It immediately clarifies what the tool is NOT (no reservation, no charge, no booking inside chat), which separates it cleanly from siblings like confirm_route_hotel or request_booking_change.

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?

Explicit when-to-use (after the person has chosen a specific flight, hotel, or both for one trip) and when-not-to (browsing). It also names the alternative path for a whole category: activities, experiences and events are add-ons on autonomad.ai and should be described in the reply instead of generating a link, so the agent knows not to force them into intent_type.

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

All travel tools Inspect

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

Need Help?