Rooms & room types module — JetSetGo MCP reference

The rooms module manages accommodation inventory in two layers. Room types (room_types) are the catalog categories customers select — standard king, deluxe suite, twin cabin. Rooms (rooms) are the individual physical units behind those categories, each belonging to exactly one type. Customers book a type; the booking pipeline allocates a specific room of that type.

What the operator uses it for

An operator with cabins, hotel rooms, or any numbered-unit accommodation defines one room type per sellable category, including maximum occupancy and descriptive/marketing fields, then registers each concrete unit under its type. Individual rooms can override the type's fare item sub-type link, occupancy, description, and price description — so Room 101 can be priced or classified differently from its siblings while remaining bookable as the same category.

The bridge to the booking system is the fare item sub-type link (pst_id, pointing at pat_sub_types): it is how a room category becomes something a fare item can actually sell against. Setting this link on a room type is bidirectional by design — the sub-type record's back-reference to the room type is maintained automatically.

Where it sits

Upstream, room types reference fare item sub-types from pattypes. Downstream, resources attach rooms and types into capacity structures (a leaf capacity unit in a layout template may link directly to a specific room), and inventory, booking, and pricing consume the allocation. The module is GraphQL-only on both read and write paths.

Key concepts

Room type (room_types) — the catalog category: name, required max_pax, fare item sub-type link, description, price description, image, hover message.
Room (rooms) — a physical unit: display name plus optional per-room overrides of the type-level fields.
Fare item sub-type link (pst_id) — connects a room category to what fares can sell it.
Bidirectional sub-type binding — saving a type's pst_id also writes the sub-type's room_type_id back-link and cascades the change to child rooms.
Per-room override — a room may set its own pst_id, max_pax, description, or price_description instead of inheriting the type's.
Room display name (room_name) — defaults from name when blank.

Tools

Tool	Class	Purpose
`rooms_list_room_types`	Read	List all room types (name, max occupancy, sub-type link).
`rooms_get_room_type`	Read	Fetch one room type by id.
`rooms_list_rooms`	Read	List rooms under a given room type, with the parent type's name when available.
`rooms_get_room`	Read	Fetch one room by id, with parent type name when available.
`rooms_save_room_type`	Guarded write	Create a room type or update any subset of its fields.
`rooms_save_room`	Guarded write	Create a room under a type or update any subset of its fields.

Rules worth knowing

Create-time requirements. A room type requires name plus max_pax of at least 1; a room requires name plus its room_type_id. Both are enforced before preview.
Display-name fallback. If room_name is blank or omitted, it defaults to name; the column is non-nullable in storage.
Sub-type links cascade. Because the type↔sub-type binding is bidirectional, changing a room type's pst_id updates the fare item sub-type record itself and cascades down to child rooms — an update that looks local has wider effect.
Overrides are explicit nulls. Clearing a room-level override means writing null explicitly; otherwise the type value continues to apply conceptually even though the field lives on the room row.
No delete path. This module exposes no deletion tool; removal happens indirectly through association management elsewhere, consistent with the platform's retire-over-delete bias.
Schema-tolerant reads. Room queries probe whether the tenant schema tracks the room-to-type relationship name and adapt their field selections accordingly, caching the result per server lifetime.
Two-phase guarded writes with row fingerprints on every save, so concurrent edits force re-preview rather than overwriting.

Fare item types — owns the fare item sub-types that room categories bind to via pst_id.
Layout templates — capacity-unit trees whose leaves can link to individual rooms.
Resources — vessels and venues that host rooms and room-based capacity structures.