travel

create_booking_intent

Create a booking intent — returns a deep-link the user clicks to complete the booking on autonomad.ai. Signing up is free, with no trial and no subscription. ALWAYS call this instead of trying to book directly through MCP — bookings require payment + identity verification that must happen on the web.

WHEN TO CALL — generate a deep-link ONLY after the user has picked something concrete: a specific flight, a specific hotel, or both (a trip). Do NOT call this for browsing or for activities/events alone. Activities and events are picked on the autonomad.ai add-ons page AFTER the user lands via the deep-link — Claude should describe them but not generate per-activity/per-event intents.

INTENT TYPE GUIDE — pick exactly one:

'flight' → user picked a flight only. offer_data = the flight offer object verbatim from search_flights, PLUS a top-level passengers: <number> field (the number of travelers the user originally requested — search_flights individual offers don't echo this back, so you must add it explicitly).
'hotel' → user picked a hotel only. offer_data = the hotel offer from search_hotels PLUS top-level check_in and check_out (YYYY-MM-DD) as STRINGS. CRITICAL: search_hotels does NOT echo dates back inside the offer object — you MUST add them yourself (use the same dates you passed to search_hotels) or the booking page will fall back to an empty form and the user will have to re-enter everything. Also include adults: <number> and rooms: <number>.
'trip' → user picked BOTH a flight AND a hotel together for the same trip. Pack them in offer_data as { flight: { ...offer, passengers: }, hotel: { ...offer, adults: , rooms: , check_in, check_out } }. ONE deep-link covers both. Don't generate two separate intents (flight + hotel) for the same trip — that produces two deep-links and a confusing user experience.

For activities, events, and experience browsing: describe what's available in your reply, but do NOT call create_booking_intent. Tell the user they'll pick those on autonomad.ai's add-ons page after they click the deep-link for their flight/hotel.

USER-FACING REPLY REQUIREMENTS — every time you create a booking intent, your reply text MUST include:

The deep_link as a clickable markdown link, e.g. 'Complete on autonomad.ai →' or 'Open: '.
That the account is free. Autonomad costs the traveller nothing — no subscription, no trial, no card required to sign up; they pay only for the travel they book. NEVER describe a trial, a free month, or Premium: none of those exist, and promising one is a claim we cannot honour.
The link expiry window (e.g. '~30 minutes — say the word and I'll regenerate if it lapses.').

CRITICAL: always echo the original passenger / adults / travelers count into offer_data. Without it the booking page defaults to 2 travelers regardless of what the user asked for.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`offer_data`	Yes
`intent_type`	Yes
`expires_minutes`	No

Schema Changelog

Changes observed during successful MCP inspections.

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.8/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly=false, idempotent=false, openWorld=true). The description goes well beyond that, disclosing that payment and identity verification must occur on the web, the free/no-trial/no-subscription account model, and a link expiry window (~30 minutes). These are behavioral facts an agent could not derive from the annotations.

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?

It is long, but the length is justified by nested object semantics and multiple intent branches, and it is front-loaded with purpose and when-to-call before the per-type detail. Headers make it scannable, though the repeated 'CRITICAL' emphasis and restated passenger-count warning add some redundancy.

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 mutation tool with a nested object parameter, 0% schema coverage, and no output schema, the description supplies everything needed: the return value (deep_link), the per-intent payload contract, the reply-format requirements, and the expiry behavior. Nothing an agent needs to call this correctly is missing.

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?

With 0% schema coverage the description carries the full burden, and it does so thoroughly: it enumerates the intended intent_type values, dictates exactly-one selection, and specifies the nested offer_data shape per type including passengers/adults/rooms/check_in/check_out. The one gap is that the schema enum still lists 'activity', 'event', and 'experiences' while the description forbids calling for those, leaving an unresolved mismatch.

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+resource ('Create a booking intent') and states the concrete output ('returns a deep-link the user clicks to complete the booking on autonomad.ai'). It explicitly separates itself from the sibling search_* tools by declaring it is the only booking path and that direct MCP booking is not permitted.

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?

The 'WHEN TO CALL' section gives explicit preconditions (only after the user picked a concrete flight/hotel/trip) and explicit exclusions (do not call for browsing, or for activities/events alone). It also names alternatives and the correct moment to route users to the add-ons page, so nothing is left to inference.

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?