Tickets & boarding module — JetSetGo MCP reference

The tickets module manages configuration templates for the fare-item lifecycle. It covers two independent workflows: boarding sequences (ordered per-passenger state templates that scheduled services follow, e.g. Expected → Checked In → Boarded) and ticket conditions (usage rules for multi-use passes), organised into ticket groups. The module is configuration-only: it defines the rules but never executes them — runtime state changes, pass scans, and service progression live elsewhere.

What the operator uses it for

Operators define boarding sequences as templates consumed by the check-in app at runtime: each sequence holds ordered states with a display verb, and check-in walks a passenger through those states on the day of travel.

Separately, operators define ticket conditions for multi-use passes: what the pass grants (usage entitlement), how many total and per-day uses it allows, how long after purchase it remains valid (expiry_days), an optional validity-duration window, and what activates it (purchase_date, first_use, or manual_activation). Conditions are grouped into ticket groups for organisation only. Assignment happens outside this module: consumption rule sets attach conditions to passenger-or-vehicle-type sub-types, and the booking pipeline enforces the rules when passes are used.

Where it sits

This module sits at the configuration layer. Upstream it has no hard dependencies; downstream, consumption rule sets (owned by the behaviours module) assign conditions to fare-item sub-types, and the check-in app consumes boarding sequences against scheduled services generated by the schedule module.

Key concepts

Boarding sequence — a named, ordered template of per-passenger states for scheduled services.
Boarding state — one state within a sequence: name, display verb, and an order value unique within its sequence.
Ticket condition — the full usage-rule set for a multi-use pass (entitlement, limits, expiry, activation).
Usage entitlement — what the pass grants the holder.
Validity duration — a short window measured in small time units used to prevent double scanning, or a longer window in hours used for free-transfer periods.
Activation trigger — when the pass's validity clock starts: purchase date, first use, or manual activation.
Ticket group — an organisational grouping of conditions with a sort key; carries no runtime behaviour.
Unlimited convention — a usage limit of 999 means unrestricted use.

Tools

Tool	Class	Purpose
`tickets_list_boarding_sequences`	Read	List sequences with state counts.
`tickets_get_boarding_sequence`	Read	Fetch one sequence with nested states.
`tickets_list_boarding_states`	Read	List one sequence's states in order.
`tickets_list_ticket_conditions`	Read	List conditions, with group names where tracked.
`tickets_get_ticket_condition`	Read	Fetch one condition, with group name where tracked.
`tickets_list_ticket_groups`	Read	List ticket groups.
`tickets_get_ticket_group`	Read	Fetch one ticket group.
`tickets_save_boarding_sequence`	Guarded write	Create or update a boarding sequence (upsert keyed on id).
`tickets_delete_boarding_sequence`	Guarded write (destructive)	Hard-delete a sequence; cascades to its states.
`tickets_save_boarding_state`	Guarded write	Create or update a state within a sequence.
`tickets_delete_boarding_state`	Guarded write (destructive)	Hard-delete a single state.
`tickets_save_ticket_condition`	Guarded write	Create or update a multi-use pass condition.
`tickets_delete_ticket_condition`	Guarded write (destructive)	Hard-delete a condition.
`tickets_save_ticket_group`	Guarded write	Create or update a ticket group.
`tickets_delete_ticket_group`	Guarded write (destructive)	Hard-delete a group; surviving conditions lose their group link.

Rules worth knowing

Configuration only. No tool here changes a real ticket's state, consumes a pass use, or advances service progression — those belong to runtime modules.
Save tools are upserts. Passing an id updates that row; omitting it creates. On create, every condition field except the optional group link is required.
Deletes are hard deletes, all classified destructive. Deleting a boarding sequence cascades to its states; deleting a ticket group merely nullifies the group link on surviving conditions rather than deleting them.
Non-negative integers throughout. All count/limit/order fields accept integers ≥ 0, and 999 is the documented convention for "unlimited" usage limits.
State order is unique within a sequence, giving check-in a deterministic walk from Expected toward Boarded.
Activation triggers are enumerated: purchase_date, first_use, or manual_activation; the validity window pairs a duration value with a unit, where short units serve anti-double-scan windows and hours serve free-transfer windows.
Identifier typing: entity ids are integer-typed across reads and writes even though the underlying keys are larger integer types.
Group enrichment is probe-gated. Condition reads include the joined group name only where the tenant tracks that relationship, degrading to flat columns otherwise.

Behaviours — consumption rule sets that attach these conditions to fare-item sub-types.
Schedule — the timetabled services whose passengers walk the boarding sequences.
Service progression — the adjacent day-of-service step lifecycle consumed by operations tooling.