Booking & payment channels module — JetSetGo MCP reference

The channels module manages JetSetGo's booking and payment channel configuration: a small, pre-seeded set of rows that identify the routes through which orders reach the business (online checkout, point of sale, agent portal) and optionally tie each booking channel to an allocation category — the capacity pool its sales draw from. Every booking carries a channel reference. The module is deliberately read-mostly: channels cannot be created or deleted through it, only relabelled and re-pointed.

What the operator uses it for

Typical work is configuration housekeeping and capacity plumbing:

Reviewing which channels exist and how each is described.
Pointing a booking channel at the correct allocation category when capacity accounting changes.
Clearing a stale allocation-category link from a channel.
Keeping descriptions accurate for staff who encounter channel names on bookings and reports.

Because the catalogue is fixed, an assistant asked to "add a channel" should explain that channels are pre-seeded and offer to update the closest existing one instead.

Where it sits

Downstream of allocation configuration: an allocation category must exist before a channel can link to it, though the link itself is optional. Upstream of bookings: each booking captures the channel it was made through, so a channel's name and description determine how historical and future bookings are labelled in attribution and reporting. Payment-type channels share exactly the same shape as booking-type channels; both carry a type value of booking or payment.

Key concepts

Channel — a named configuration row identifying one way orders arrive (for example online checkout, point of sale, agent portal).
Channel type — booking or payment; classifies what the channel is used for.
Allocation category — the capacity pool a booking channel draws stock from; stored as an internal link on the channel row, nullable.
Pre-seeded catalogue — channels ship with the platform; no create or delete operation exists anywhere in the module.
Description — free text carried on every channel; purely informational.
Content fingerprint — every guarded change snapshots the target row first and re-verifies it immediately before committing, so concurrent edits are detected rather than overwritten.

Tools

Tool	Class	Purpose
`channels_list`	Read	List all channels ordered by name, with allocation-category details joined when tracked for the tenant.
`channels_get`	Read	Fetch one channel by id, with the same join; errors clearly if the id does not exist.
`channels_save`	Guarded write	Update `inventory_citizen_id` and/or `description` on an existing channel — the only two writable fields.

Rules worth knowing

Only inventory_citizen_id and description are mutable. Name and type are fixed for the life of the platform; no tool path exists to change anything else.
channels_save runs the guarded-write sequence: it produces a preview of the change, requires explicit confirmation with a preview token, then re-computes the row fingerprint immediately before executing. If the row changed underneath (concurrent edit), the operation aborts instead of overwriting.
All writes require the tenant to be stated explicitly; there is no default-tenant fallback on any write path.
Passing null clears a field (for example, detaching the allocation-category link). An empty-string description normalises to null. A save that would change nothing is rejected with a validation error.
Reads resolve the allocation-category join only where the underlying relationship is tracked for the tenant; availability is probed once per server lifetime and cached, so list and get results stay consistent within a session.
Treat the catalogue as configuration: deletion is impossible by design, so mistakes are corrected by editing rows, never by recreating them.

Bookings — bookings record the channel they were made through; channel naming drives booking attribution.
Settings — other tenant-wide configuration rows that sit alongside channel setup.