Package builder module — JetSetGo MCP reference

The packages module builds packages: single products a customer buys once that are really several separately-bookable products underneath — a transfer out, a crossing, a guided activity, accommodation nights, the return leg — quoted as one price, booked as one reservation. The module exposes the recipe behind each package: its sections (each one customer question), the choices within them, the bookable products attached to those choices, timing rules, pathways, versions, and publishing.

What the operator uses it for

Operators author recipes an itinerary sells from. Each step of the journey is a section — exactly one question the customer is asked ("getting there", "where are you staying?"). The answers are choices, and each choice carries the component products that actually book. One section is the anchor: the customer picks its date, and every other section derives its date from it.

Assistant work spans building out sections/choices/products, pinning fare classes, writing auto-pick rules and timing constraints, configuring pathways, checking for blocking problems (packages_validate writes nothing and can run freely after every change), then publishing or unpublishing. Every write is preview-then-confirm.

Where it sits

Packaging sits at the top of the catalogue and composes what other modules own — no pricing, availability, or capacity logic of its own. Upstream it points at resources (including the package-flagged product it is sold as), behaviours, fare items and their sub-types, stops/routes, custom fields, cancellation policies. Downstream, search pivots on the anchor's date; availability resolves each section's choices; pricing either sums the chosen parts (emergent) or uses the package product's own price with derived shares (target); bookings become a reservation tree pinned by the exact version sold. The selling product is an ordinary resource flagged as a package, created in Resources, never here; one live package per such product.

Key concepts

• Section (tool arguments say node) — one step = one question the customer answers.
• Choice (option) — one answer to a section's question; has no product of its own.
• Component product (option resource) — what actually books when a choice is picked; first attached books, later ones are fallbacks.
• Display product (face) — picture/copy on a section's card; books nothing except on the anchor, which books off its own product directly.
• Anchor — the timing root; exactly one per package; never another package or an accommodation product.
• Decline card (skip option) — an ordinary choice flagged as the section's "no thanks"; books nothing.
• Pathway — a pre-baked personality through the package, offered in selected sales channels; can pin answers or mute questions.
• Version — snapshot appended on every save/publish/unpublish; latest number is the write concurrency token.

Tools

All tools take an explicit tenant. Writes are two-phase: call without confirm to preview, then re-call with confirm: true plus the returned previewToken.

Reading and validating

Template basics and day editorial

Sections

Choices and their bookable products

Defaults and timing

Pathways

Going live

Rules worth knowing

• Face versus booking. A section's display product supplies picture and copy only — no service, capacity, price, or reservation. What books is the products on the section's choices; every read states this per section as books_from: anchor_face, options, or nothing.
• Anchor rules. Exactly one; never a package product or an accommodation product (decided by behaviour, not naming); books off its own product directly. A sub-package — a choice pointing at another package — resolves its own anchor first within its own scope.
• Fixed sections don't book today. A bookable product attached directly to a non-anchor fixed section renders but books nothing; the sanctioned shape is a choice-section carrying one non-decline choice.
• Saves rewrite child ids. Every write loads the tree, changes one thing, saves it whole; section/choice ids churn each save — re-read, never cache across writes. A stale version token means someone else changed the package; nothing was written. Pathways version independently.
• Removal cascades quietly elsewhere. Removing a section also destroys every pathway's tuned override for it — the preview counts and names affected pathways (warning, not refusal). Removing a choice leaves overrides aimed at it alive but targetless.
• Degradation is labelled, never guessed. Untracked joins fall back rather than fail: accommodation returns null (unknown), never false; unreadable pick-up/capacity columns return unknown: true. Never report "no party-size limit" unless capacity is known rather than placeholder.
• Import is deliberately not exposed — it would pass large snapshot JSON through the model verbatim under whole-tree save semantics, the likeliest silent-corruption path; point operators at the builder's own Import. Duplication IS exposed: no snapshot crosses the model.
• Publish/unpublish/delete are distinct. Unpublish is reversible; delete releases the backing product and needs an administrator to reverse. Both publish and unpublish write a version.

Related modules

• Resources — owns the package-flagged selling product and every component product; this module never mints either.
• Channels — the sales-channel contexts deciding which pathways customers see.
• Bookings — consumes published packages as reservation trees pinned to the exact version sold.