Business rules module — JetSetGo MCP reference

The business_rules module manages JetSetGo's conditional pricing rules: decision models the pricing engine evaluates to discount, surcharge, fee, or re-price a quoted amount. Each rule pairs a logic document (rule_json, a node-and-edge decision model executed by JetSetGo's rules engine) with metadata — name, unique code, classification labels, targeting arrays, a validity window, evaluation priority, and lifecycle flags.

What the operator uses it for

Operators express time-boxed commercial mechanics as rules: for example, a child fare set below the adult base, an off-season surcharge on a specific route, or a fixed booking fee. A rule's conditions reference pricing variables — named fields from three context levels (the individual fare item being priced; the journey or leg; and the whole booking, such as party size or channel). The live variable vocabulary is tenant-specific and evolves, so agents must call business_rules_list_variables before authoring any rule_json rather than assuming field names.

The engine loads a tenant's active, in-window rules, evaluates each against a booking, and applies the effects the decision model emits. Effects are one of five keys emitted by rule_json: discount_percent, surcharge_percent, discount_amount, surcharge_amount, or target_price (an absolute price that overrides all other effects). Reusable parameterised rule shapes exist as templates; over MCP they are read-only.

Where it sits

Upstream: routes, resources, products, and fare item types supply both the identifiers a rule targets and the variable values its conditions test. Downstream: the pricing/quoting pipeline is the consumer — it runs every active, in-window rule per fare item and applies emitted effects to the customer-facing price drawn from the base-fare catalogue. Activating a rule is therefore not cosmetic: it changes prices customers are quoted immediately, whenever the wall clock falls inside the validity window.

Key concepts

Pricing rule — a decision model plus metadata; adjusts quoted/charged prices for matching bookings.
rule_json — the rule's logic document; structurally validated by the MCP, never semantically.
Effect keys — discount_percent, surcharge_percent, discount_amount, surcharge_amount, target_price; a positive target_price wins over everything.
Targeting arrays — resource_ids, route_ids, pat_type_ids (fare item types), product_type_ids: the primary scope gate.
Validity window — valid_from/valid_until, checked against the clock at pricing time.
Priority & stops_processing — ascending evaluation order (lower first); a matching rule with stops_processing suppresses lower-priority ones.
Draft / active lifecycle — new rules are drafts; activation is a separate, explicit step.
Templates — reusable parameterised rule shapes; readable but not authored via MCP.

Tools

Tool	Class	Purpose
`business_rules_list_rules`	Read	List rules (summaries only); filters incl. status `draft/expired/active/inactive`; paginated.
`business_rules_get_rule`	Read	Fetch one rule with full `rule_json` and targeting.
`business_rules_list_templates`	Read	List reusable rule templates; filters: category, system flag, search.
`business_rules_get_template`	Read	Fetch one template's shape and parameters.
`business_rules_list_variables`	Read	The legal condition vocabulary (always filtered to visible, active).
`business_rules_list_rule_versions`	Read	Append-only version history for a rule.
`business_rules_get_evaluations`	Read	Evaluation audit log; requires ≥1 id filter. Typically empty.
`business_rules_create_rule`	Guarded write	Create a rule; draft by default unless `is_active:true`.
`business_rules_update_rule`	Guarded write	Partial update of one rule by id.
`business_rules_set_rule_active`	Guarded write / Guarded write (destructive)	Activate (non-destructive) or deactivate (destructive-classed) a rule.
`business_rules_delete_rule`	Guarded write (destructive)	Soft-delete a rule (`deleted=true`).

Rules worth knowing

Omitted ≠ empty array. For each targeting array: omitted or null means ALL values on that dimension; [] means NONE — the rule becomes inert and never fires; a list means exactly those ids. The distinction is preserved end-to-end.
A rule with all four arrays omitted is tenant-wide. It prices every booking. Activation of such a rule is refused unless the caller passes acknowledge_tenant_wide:true; inert ([]) activations are warned about but not blocked.
Validity is wall-clock, not travel date. valid_from/valid_until compare to the time of pricing, not the departure being booked; null sides are open-ended.
Labels do not gate behaviour. rule_type (discount/surcharge/fee/validation) and applies_to classify only — the money effect is whatever rule_json emits, and is_stackable is advisory metadata not enforced by today's engine (all matched rules stack).
Status filtering mirrors the app exactly: expired ignores the active flag; active/inactive do not check valid_from.
The evaluation log is usually empty because per-evaluation logging is disabled platform-wide. An empty result does not mean a rule never fired; verify behaviour in the app's rule tester before activating high-stakes rules.
Codes are unique forever. Uniqueness includes soft-deleted rules; a deleted rule's code stays reserved and cannot be reused on this path.
Live edits bypass version snapshots, so a prior rule_json is generally not recoverable through version history after an update.

Pricing — supplies the base fares these rules adjust.
Passenger & vehicle types — source of fare item type ids and L1 condition context.
Resources — resource ids used in targeting arrays.
Revenue management — where operators observe demand and decide when rule changes are warranted.