JetSetGo Booking MCP — AI Agent Booking Integration

The JetSetGo Booking MCP is a Model Context Protocol (MCP) server that gives authorised AI agents a booking-only toolset over the JetSetGo platform. It runs the same codebase as JetSetGo's Operations & Configuration MCP, deployed with a booking-only module configuration: the catalogue it advertises contains exactly the booking journey plus two documentation-discovery tools, and nothing from the internal staff or configuration surface is reachable through it.

It is built for teams adding agentic booking to their own products: AI product teams embedding a travel assistant in an app, travel agencies whose assistant books on behalf of travellers, and distribution partners building agent experiences over the catalogues of operators who run on JetSetGo.

Two properties define how it works. First, the JetSetGo Booking API remains the authority at every step: choices, availability, prices and lifecycle results always come from a current API response, never from values an agent invents, remembers or estimates. Second, every operation that changes a real booking is guarded: it returns an exact preview first and executes only when a single-use confirmation token is presented back unchanged against a fresh read of live state.

What the agent can do

A complete sale follows one journey through the tools. Identifiers flow forward: each step returns the opaque identifiers the next step needs, so the agent never constructs a price, an action id or an option value itself.

Discover products. booking_list_products lists the non-package products currently representable on the platform, and booking_get_product reads one product's current projection — the fare options, traveller categories and details it publishes today. Both are read-only.

Open a booking context. booking_start_context opens a booking context — the platform's working record of one trip being assembled — for a chosen product. This is a provisional write: it requires an explicitly allowed tenant, and if its outcome cannot be proved after a network failure the server reports that honestly instead of inviting a blind retry. An optional input can attach the new context to an existing booking already issued to this identity.

Answer what the trip requires. Trips can require decisions before they are sellable: party details, vehicle selection, parking dates and space type, accommodation room and dates, pre-booked extras. The Booking API publishes each outstanding requirement as an action inside the context, which booking_get_context reads. For direct actions the agent answers once with booking_answer_action, submitting exactly the action identifier and value format the API published. Where the API supplies a resolver, booking_resolve_action walks the prompt step by step: the first call passes empty state, no prompt id and no answer; each later call passes the returned public state through unchanged and submits exactly one answer for the returned prompt. Resolution itself changes nothing — its final value still goes back through booking_answer_action.

Check availability and read the price. booking_check_availability confirms the configured trip can be supplied; it creates no hold. booking_get_current_price returns the price as it stands immediately before commitment. Both results are deliberate, time-sensitive facts that the agent re-reads at decision time rather than caches.

Commit the booking. Called without confirmation, booking_commit returns a preview of the exact context and price about to be committed together with a single-use preview token. Confirming with that token re-reads the live context and price and executes only if neither has moved. If either changed, the confirm is refused and the agent re-previews against fresh facts rather than overriding them.

Hand over payment, then manage the booking. booking_get reads the created booking, including the hosted payment link it may publish and its current payment state; its description embeds bounded-wait guidance so the agent waits honestly for settlement instead of declaring success early. booking_list_bookings lists this identity's authorised bookings with cursor pagination. booking_update revises a booking's contact details and booking_cancel cancels a booking — both use the same preview-then-confirm handshake as commit.

The full tool catalogue

This list is complete: thirteen booking tools and two discovery tools are everything the server exposes in booking-only deployment.

Class meanings: read tools change nothing anywhere; provisional writes create or progress working records and require an explicitly allowed tenant argument; guarded writes change real bookings and always follow preview then confirm, with cancellation additionally counted against a destructive-volume cap.

Notable inputs: product identifiers are integers issued by earlier responses; contexts and bookings are universally unique ids returned by earlier calls; booking_update accepts only the contact fields the API allows — names, email address, phone number, country, postal code and notes — with at least one field present; booking_cancel accepts an optional free-text reason. No booking tool accepts card data, refund instructions or activation commands.

How it stays safe

The same engine decides everything. The MCP is a thin projection of the Booking API: it stores no bookings, computes no availability, calculates no prices. Validation, availability checks, pricing and lifecycle rules run exactly where they run for JetSetGo's own web and staff channels. An agent cannot inject a price, invent an option, or supply values the current action does not ask for; answers are validated against the requirements the API publishes for the action being answered.

Isolation is structural. Every operator business on JetSetGo has an isolated workspace — a tenant. The deployment pins the connection to one tenant, and that pin overrides any tenant argument an agent might supply; where no pin exists, writes fail closed rather than guess. Credentials narrow scope further. A customer credential acts as, and for, one signed-in customer account verified inside the pinned tenant. An integration key carries authority recorded at issue time: either bound to one customer account, or deliberately tenant-wide, with client and channel identity derived by the server rather than taken from request headers or payloads. A key presented to this server is accepted only by booking tools, so it cannot acquire staff or configuration authority anywhere else in the shared platform.

Guarded writes confirm before they act. booking_commit, booking_update and booking_cancel return a preview carrying the exact intended change plus a signed, single-use preview token bound to the operation, the tenant, the arguments and a fingerprint of the state being changed. Confirmation re-reads live state and executes only when everything still matches. Changed arguments, moved underlying state, a mismatched tenant, an expired token, a reused token or a different caller all produce distinct refusal errors and require a fresh preview. Tokens expire within minutes, at most one fresh re-preview follows a refusal, and there is no automatic retry loop.

Uncertainty is reported, not papered over. If a mutation may have reached the booking engine but its result cannot be proved — typically after a network interruption — the server returns an explicit unknown-outcome error marked as not safe to retry automatically. The correct response is always to re-read the current context or booking and decide from live evidence. Error details are sanitised on the way out: contact details, payment data and other sensitive values are redacted before an error reaches the agent.

Payments

Booking through an agent never means handing card details to software that does not need them. No booking tool accepts payment data: no card numbers, no payment tokens, nothing from a payment instrument. Payment happens after the booking exists.

When a created booking is read with booking_get, it may publish a hosted payment link. The agent passes that link to the traveller — or to the partner application, which passes it on — and the traveller completes payment inside JetSetGo's hosted checkout. The agent's job ends at delivery of the link; it cannot take payment instructions, and the platform accepts none from it.

Settlement is then confirmed honestly rather than assumed. Completing hosted checkout is payment submission, not immediate proof the platform has recorded it: the booking changes only after the payment provider's confirmation webhook has been processed by JetSetGo. Tool guidance therefore directs the agent to poll booking_get on a bounded cadence until the booking reports its payment state as paid and its current state as active. While waiting, the agent never retries or recreates the payment; a transient intermediate state right after checkout is not evidence of failure. If the bounded wait expires without confirmation, the agent reports exactly what is true — payment submitted, backend confirmation pending — instead of claiming either success or failure.

How agents connect

Connections use the standard Model Context Protocol over its network-oriented streamable HTTP transport, so any conformant MCP client can integrate. Access is provisioned per partner by JetSetGo: contact JetSetGo to request access, and credentials are issued against your integration. Two credential kinds exist. A customer credential lets an agent act for one signed-in customer account. A JetSetGo integration key suits partners booking under their own commercial identity; keys are issued once, stored only as a prefix plus a cryptographic hash, and must be rotated if lost.

Once connected, discovery comes first. jsg_list_apps lists the namespaces this deployment exposes, and jsg_app_context returns the full context document for the booking namespace: what each tool is for, how the journey fits together, and the rules of engagement — the same document JetSetGo's engineers maintain alongside the code. Both discovery tools run without credentials so a client can orient before authenticating. Per-app documentation is also exposed as MCP resources and in the server's instruction block, so conformant clients receive orientation automatically.

From there the agent needs no other configuration surface: the tenant pin, the credential checks and the guarded-write handshake are all enforced by the deployment, not negotiated per call.

Where the booking data lives

Everything the agent sees — products, fare options, availability, prices, cancellation rules — originates in domains operators maintain through their own governed tools. Those domains have full reference pages in the MCP module documentation: the sellable product catalogue, passenger and vehicle types, pricing, schedules, and cancellation policies. The booking tools never edit those domains; they read what operators configure and enforce it at sale time.

What it doesn't try to be

The Booking MCP has deliberately narrow scope, stated here plainly.

It is a booking surface, not a staff console. It sells non-package products through the standardised Booking API; package products are outside its scope. It manages bookings after sale only where the API exposes them: contact-detail updates and cancellation. Operations that remain staff work on purpose — confirming or extending bookings, issuing refunds, activating anything — are not part of this toolset, because the tools do not exist.

It is not a second source of truth. It stores no state between calls beyond short-lived signed preview tokens; every question about a booking is answered by re-reading the platform. When this server and a direct JetSetGo channel ever appear to disagree, the API response wins, and the agent is instructed to treat it that way.

And it does not replace the experience of JetSetGo's own channels: those remain the reference implementation of the booking journey, and this server follows the same contracts they do.