Pricing module — JetSetGo MCP reference

The pricing module manages JetSetGo's base-fare catalogue: the price lists a customer is quoted before any conditional adjustments are applied. It exposes four layers — price lists (one fare container per resource), date-bounded versions of those lists, individual price rows inside a version, and price types (Peak/Off-Peak-style labels). Discounts, surcharges, and booking-curve adjustments live elsewhere; this module holds the base numbers only.

What the operator uses it for

Operators build and maintain dated fares for each sellable resource. A price list belongs to exactly one resource and carries one price-type label. A version is a date-bounded slice of that list (start/end dates) and can optionally be scoped to a single product variation — the fare-class lane. Several versions may cover the year side by side; the booking engine picks whichever version's window contains the travel date.

Inside a version there is one price row per bookable fare category (the atomic passenger or vehicle types defined elsewhere). A row is either flat, track-tiered (a base price plus from/to/increment ranges keyed to an inventory track), or journey-attribute based (priced per section or per night). Price types are reusable labels such as peak and off-peak periods, each carrying a numeric level used for ordering.

Where it sits

Upstream, the catalogue tables supply identifiers: resources own the price lists; fare item types and their categories (maintained via consumption rule sets in the behaviours module) determine which rows a version needs. Downstream, the quoting pipeline resolves resource → active version for the booking date → the price row for the fare category, then hands the base fare onward — conditional pricing rules (business_rules) stack discounts and surcharges on top, the schedule performs active-version lookups by date, and revenue management compares realised results against expectation. Writes go through REST endpoints; cache-invalidation triggers mean an edited price reaches live quotes within seconds, so price writes are never cosmetic.

Key concepts

Price list — the fare container for one resource; requires a name, the resource id, and a price type.
Version — a date-bounded slice of a price list, optionally pinned to one product-variation lane.
Variation lane — the product-variation scope of a version; overlap rules are evaluated per lane.
Price row — one fare category's price within a version; flat, track-tiered, or journey-attribute.
Consumption-based price — a tiered price keyed on an inventory track or a journey attribute rather than a flat amount.
Track tiers — start_range / end_range / increment bands applied against units consumed from an inventory track.
Price type — a Peak/Off-Peak/Holiday-style label with a numeric level (minimum 1); retired, never deleted.

Tools

Write tools follow the guarded preview→confirm pattern and require an explicit tenant.

Tool	Class	Purpose
`pricing_list_price_lists`	Read	List price lists; filter by resource id or name contains.
`pricing_list_price_list_versions`	Read	List a price list's versions with dates and variation lane.
`pricing_list_prices`	Read	List a version's price rows (per fare category, incl. tier fields).
`pricing_list_price_types`	Read	List price types; optional status filter.
`pricing_get_bookable_pats`	Read	Which fare categories may be priced for a price list (derived from its resource's consumption rule set); empty if the product is unconfigured.
`pricing_save_price_list`	Guarded write	Create or update a price list (name + resource + price type required).
`pricing_save_price_list_version`	Guarded write	Create or update a version; enforces start ≤ end and same-lane overlap checks.
`pricing_save_prices`	Guarded write	Batch upsert price rows in a version, with optional deletes in the same call.
`pricing_save_price_type`	Guarded write	Create or update a price type (name, display name, description required; level ≥ 1).
`pricing_delete_price_list`	Guarded write (destructive)	Hard-delete a price list.
`pricing_delete_price_list_version`	Guarded write (destructive)	Hard-delete a version.
`pricing_delete_prices`	Guarded write (destructive)	Hard-delete multiple price rows by id.

Rules worth knowing

Overlap is judged per variation lane. Two versions of the same list may share dates if they sit in different lanes or carry different price types; within the same lane, overlapping windows are rejected outright.
Hard deletes for lists, versions, and prices. There is no soft-state retirement for these three — deletion removes the rows. Price types are the exception: no delete exists, retire them with status inactive.
A price row is consumption-based if it names a track or a journey attribute. The two are mutually exclusive on one row. When consumption fields are absent, range and increment fields must be null; when present, start_range/end_range/increment are all-or-nothing with start < end and increment > 0.
The version link is mirrored. Every price row written through pricing_save_prices stamps both the version-id columns from the call's target version, regardless of what a caller supplies.
Batch saves can mix upserts and deletes. pricing_save_prices accepts existing row ids to update, new rows to create, and a delete list — executed as one guarded operation fingerprinted against the version's current row set.
Bookable fare categories come from the resource's configuration. pricing_get_bookable_pats returns null or empty when the resource has no consumption rule set configured — a signal the product itself is not set up, not that prices are missing.
Drift detection uses full-row fingerprints. Updates and deletes re-read the target rows at confirm time; a concurrent edit fails the confirm with a re-preview request.
Every write changes live quotes. Because cache invalidation propagates within seconds, agents should treat price writes as customer-visible immediately, not as staging edits.

Business rules — conditional discount/surcharge rules evaluated on top of these base fares.
Passenger & vehicle types — defines the fare item types and categories each price row targets.
Resources — owns the resources each price list attaches to.
Schedule — departures resolve the active version by date at quoting time.
Revenue management — assigns price types to services and monitors outcomes against them.