What is the JetSetGo Operations MCP?

It is a Model Context Protocol server that exposes JetSetGo's operational capabilities — routes, pricing, inventory, bookings, customers, policies, communications and configuration — as governed tools. Each capability mirrors one JetSetGo child app, so an AI agent works through the same surface operators use. Every change is previewed and approved before anything is applied.

How does JetSetGo stop an AI agent making unwanted changes?

Writes are guarded end to end. An agent must request a preview first, which returns a signed token bound to the exact change and to a fingerprint of the current data. Applying the change requires that token plus human confirmation, and the server re-checks the data immediately before executing. If anything moved since the preview, the change is refused and a fresh preview is required.

Whose permissions does an AI assistant use when it acts on JetSetGo?

Yours. In production, every request forwards the calling operator's own identity token, so the platform authorizes each action exactly as if the operator had done it manually. The tenant is fixed by the connection, not chosen by the model, and tenants must be explicitly allowed for AI access.

Is this only for JetSetGo's built-in assistant?

No. JetSetGo's own assistant, Hubert, is built on this layer, but any authorised MCP client can connect to the same governed surface. External clients go through the same discovery flow, the same permission forwarding, and the same preview-and-confirm rules.

Does connecting an AI client expose our JetSetGo data publicly?

No. Access is provisioned per operator through JetSetGo, scoped to your tenant, and limited by your existing permissions. Discovery information about available capabilities can be read without a token, but reading or writing any operational data requires authenticated access tied to a permitted operator account.

Can an agent bulk-edit or delete large parts of our catalogue?

No. Records are deactivated rather than deleted, consecutive destructive operations are rate-limited per tenant, and every individual change still passes through preview and approval. Bulk work happens as many reviewed steps, not as one blanket authorisation.

JetSetGo Operations & Configuration MCP — Governed AI Access for Operators

The JetSetGo Operations & Configuration MCP is a Model Context Protocol (MCP) server that turns what operators already do in JetSetGo into tools an AI agent can use. Routes, fares, capacity layouts, timetabled services, customer records, cancellation policies, email templates, ledger mappings, tenant settings: each capability area is exposed as a named module of tools, one module per JetSetGo child app, covering the same actions the app itself offers.

Two things make this different from a generic database connector. First, every module ships contextual documentation, so an agent learns what a domain means and how it connects to the rest of the platform before it picks a tool. Second, nothing consequential happens without a person: writes follow a strict preview-then-confirm handshake, and every request is authorized against the calling operator's own permissions.

This is the same surface JetSetGo's in-platform assistant, Hubert, runs on. Authorised external MCP clients connect to the identical governed layer. For the customer-facing counterpart — agents that sell trips rather than run operations — see the Booking MCP.

Context before action

An agent that understands the domain makes better requests. Before touching any tool, an MCP client connected to this server can ask two discovery questions:

jsg_list_apps — returns the roster of capability modules with a short description of each, so the agent can see that "routes" means stops and journeys, that "pricing" owns fares, and that cancellation policies live in their own module.
jsg_app_context — takes one module name and returns its full contextual documentation: what the domain is for, how it fits the wider platform, which upstream records feed it, which downstream behaviour depends on it (for example, how a route's leg times feed scheduled services), plus a glossary of terms.

These documents are curated per child app and served directly by the server. They matter because JetSetGo's domains interlock: changing a fare type ripples into quotes, editing a capacity layout affects future departures, and deactivating a stop affects timetabled journeys. The context tells the agent these connections up front, and safety-relevant warnings are also written directly into write-tool descriptions so they appear at the moment of decision, not just in background reading.

The result is fewer wrong-tool mistakes and better-formed requests: the agent arrives at each tool already knowing the vocabulary operators use.

What it covers

Coverage tracks the operator-facing apps one for one. If operators manage it in JetSetGo, there is a module for it — roughly three dozen modules today, exposing more than 400 individual operations (tools). The roster grows as apps gain capabilities.

Routes, scheduling & day-of-travel operations

Module	What an operator uses it for
`routes`	Stops and routes: locations, journey legs, leg times, route optimisation, ordering
`schedule`	Timetabled departures: generating, adjusting, cancelling services from a product, route and capacity layout
`serviceprogression`	Day-of-service progression profiles: the checkpoint steps a departure moves through
`tickets`	Boarding sequences and ticket/pass conditions: how passengers board and how multi-use passes behave
`localevents`	Local events and public holidays that shift demand or block availability
`printers`	On-site printing: receipt/ticket templates, print servers, queued print jobs

Pricing & revenue

Module	What an operator uses it for
`pricing`	The fare catalogue: price lists per product, dated versions, prices per passenger/vehicle kind
`pattypes`	What can be booked: top-level categories (passenger, vehicle) and the concrete bookable kinds beneath them (adult, child, car)
`business_rules`	Conditional pricing rules: automatic discounts, surcharges and fees applied at quote time
`revenuemanagement`	Revenue management actions on specific departures, with demand signals
`commissions`	Agent and partner commission setup
`policies`	Cancellation policies, time-based fee tiers, and the tenant-wide default policy

Products, inventory & capacity

Module	What an operator uses it for
`resources`	The sellable-product catalogue: anything bookable, with fare-class variations, add-ons, checkout recommendations, pickup/dropoff details
`behaviours`	Booking eligibility and consumption rules: which passenger and vehicle types are bookable on a product and how much capacity each consumes; whether a product is inventory-controlled or ticket-controlled
`blueprints`	Capacity-layout templates — decks, areas, seats, lanes, cabins — copied onto each departure
`tracks`	Consumable capacity units (seats, lane metres) and checked limits such as height ceilings
`inventorycitizens`	Allocation categories deciding which trade partners, corporate accounts or walk-up segments can draw on inventory, with priority
`inventorymaps`	Seat maps and cabin layouts
`rooms`	Rooms and room types for accommodation stock
`vehicleoptions`	Vehicle fittings: attachments, towing options, hire categories
`producttypes`	Product-type classification
`assets`	The physical fleet — vessels, buses and other vehicles that deliver services — distinct from the bookable products they run

Customers & selling

Module	What an operator uses it for
`clients`	Customer CRM: contacts, communication history, files, invoices, financial summaries
`clienttypes`	Customer-type taxonomy
`giftvouchers`	Gift vouchers: issue, adjust, void, report
`packages`	Package builder: bundling several separately-bookable products into one sellable package
`channels`	Booking and payment channel configuration

Communications & documents

Module	What an operator uses it for
`emailtemplates`	Email and document templates
`gallery`	Image library
`customfields`	Custom questions attached to bookings, products and departures (definitions, validation, display groups)

Finance & payments

Module	What an operator uses it for
`glrules`	General-ledger mapping rules
`paymenttypes`	Payment methods, gateways and surcharges
`paymentterms`	Payment terms

Platform administration

Module	What an operator uses it for
`settings`	Tenant-wide configuration: branding, checkout, regional formats, ticketing, email defaults
`tenantpermissions`	Users, groups and roles: who can use the platform and with what authority
`knowledge`	The operator-curated knowledge base an assistant searches: brand voice, procedures, FAQs, with a propose-and-approve write-back path

Analytics (provision-gated)

Module	What an operator uses it for
`bi`	Reporting queries through the analytics stack: find fields, run queries, save charts and dashboards

Every module inherits the same safety machinery described below. There is no per-module opt-out: a tool cannot exist outside the preview-and-confirm model.

Guarded writes

Reading is straightforward: an authenticated agent queries the same data operators see, filtered by its permissions. Writing follows a deliberate two-step ritual.

Step one: preview. When an agent calls a write tool without confirming, the server computes exactly what would change — the record, the field values before and after, the operation type — and returns that as a preview along with a signed preview token. Nothing is mutated. The token is bound to four things: the operation, the resolved tenant, the exact arguments, and a fingerprint of the data as it stands right now.

Step two: confirm. The human reviews the preview — in Hubert's case, an operator taps approve on a card showing the precise change. Only then does the agent replay the call with the token. At execution time the server re-reads the target data and recomputes the fingerprint. If anything drifted since the preview — a colleague edited the record, another process changed the order — the write is refused with a clear DATA_CHANGED_REPREVIEW result and a fresh preview must be minted. Mismatched arguments and mismatched tenants are refused the same way. After one refusal the loop ends; the server never auto-retries.

Three further guards sit around this handshake:

Deactivate, don't delete. Core records such as stops, routes and products are switched inactive rather than destroyed. Reversible by design.
A cap on consecutive destructive operations per tenant bounds how much damage a confused sequence of calls could do, even one individually-approved step at a time.
Internal system records are invisible and untouchable — never listed, never mutated.

The practical effect: an agent can do genuine bulk work — rebuilding a season's timetable, updating forty price rows — because each step is cheap to review, while no step ever carries blank-cheque authority. Approval binds to the exact state of the world the human saw. This is what lets operators hand an assistant real operational work instead of read-only summaries.

Permissions and isolation

An agent connected through this server never gains power its human lacks.

In production deployments, every request forwards the calling operator's own identity token. The JetSetGo backend then authorizes each read and write exactly as it would for that operator working in the apps directly — same role, same tenant scope, same boundaries. If an operator cannot edit commission rates, neither can their assistant acting on their behalf. There is no elevated service identity on the data path: a request without a caller token fails closed.

Tenancy is enforced structurally. The tenant is pinned by the connection's request header and overrides anything the model supplies as an argument, so a prompt cannot steer work at the wrong company's data. The default-tenant convenience that exists for local development is deliberately unavailable in production mode — the server refuses to start configured that way.

On top of platform permissions, each deployment maintains an explicit allowlist of tenants enabled for AI access. It fails closed: an empty list permits nothing, and the pinned tenant is checked against it on every single call. Enabling AI access for a new tenant is a deliberate administrative act, not a side effect.

Validation closes the gap between what a form enforces and what a database would accept. Each tool re-implements the mandatory fields, formats, ranges and required combinations its source app checks, rejecting malformed input before a preview is even produced — so an agent gets the same feedback an operator would get from the app's own forms.

Hubert

Hubert is JetSetGo's built-in AI assistant. Operators open the assistant panel and ask in plain language — create a product, adjust a fare, look up a customer, reschedule a departure — and Hubert does the work through this exact tool layer. It acts as the operator: it forwards that operator's own token, prepares a preview for every write, and waits for the operator's approval before anything applies. Its understanding of each domain comes from the same per-module documentation served to any client.

Authorised external MCP clients connect to the same server, the same tools, the same rules. There is no special back door for the built-in assistant and no weaker path for anyone else.

Connecting a client

Connections use the standard Model Context Protocol, so any MCP-capable client works without bespoke integration.

Obtain access through JetSetGo. Access is provisioned per operator account with your existing permission model; there is no open self-service endpoint. Ask JetSetGo to enable MCP access for your tenant and designated users.
Point your client at your provisioned server endpoint. Production callers connect over HTTP and present the operator's identity token on each request. Local evaluation builds can run the same server locally over stdio.
Discover before acting. Call jsg_list_apps to see the capability roster, then jsg_app_context for any domain the task touches. Both are readable without a token, so orientation costs nothing.
Work preview-first. Reads return live data within the operator's permissions. Writes return previews carrying a token; apply them only after the responsible person approves.

Because authorization rides on the operator's own account, there is nothing to rotate separately and nothing extra to leak: revoke or change an operator's access and their agent's effective powers change identically.

What it doesn't try to be

Honesty about scope is part of the design.

It is not autonomous background automation. Nothing runs unattended on a schedule; the agent acts within a session, at a human's direction, and consequential changes wait for a human decision. That constraint is what makes broad delegation safe enough to actually use.
It does not replace the apps. Tools cover what the child apps own, mirroring their rules and validations. Where an action is better done in a visual editor — designing a seat map canvas, reviewing a complex wizard — the guidance says so plainly.
It is not a public API. There is no unauthenticated surface. Data access requires a provisioned, permitted operator identity on every request; only capability descriptions are openly discoverable.
It does not invent cross-app shortcuts. A module exposes its own app's capabilities and respects ownership boundaries, so an agent cannot reach around one app's rules by knocking on another's door.

For operators, the summary is simple: the assistant can do your work, only as you, only where you allow, and nothing lands until you have seen it.

Per-module reference

Every module in the tables above links to its full reference page — tool catalogue, key concepts, composition, and constraints, maintained alongside the server code. Start anywhere: routes, pricing, or resources.