Seat maps & cabin layouts (inventory maps) module — JetSetGo MCP reference

The inventorymaps module manages the data layer for visual seat maps and cabin layouts. Each inventory map (inventory_maps) holds the rendered layout of a resource as an SVG document plus a cabin-builder project file (project_data, structured JSON), along with display headings shown above the map (top, main, bottom) and an optional link to the resource it depicts. The interactive canvas editor itself is a browser application; the module exposes the underlying storage so agents can read and maintain layout data programmatically.

What the operator uses it for

Seat maps answer "where exactly is this unit?" — the geometric counterpart to capacity structures. An operator maintains one map per deck or area of a vessel or venue: the SVG provides the presentation rendering, while the project file preserves the editable source used by the cabin-builder canvas. Maps are attached to resources so scheduled services and boarding flows can render or resolve positions.

It is worth separating this module from layout templates: templates define bookable structure and quantities; maps define visual geometry and labels. A deployment can have precise capacity structures without any map, and maps without live capacity.

Where it sits

Upstream, a map may reference a resources row; the link is nullable, so untethered draft maps are valid. Downstream, scheduling and boarding consume maps when presenting or checking off specific seats and berths. The module deliberately splits its transport: GraphQL handles listing and small-field detail updates, while REST handles create, full update, and delete, because layout payloads can be very large.

Key concepts

Inventory map (inventory_maps) — one named layout document.
SVG data (svg_data) — the rendered layout as a large SVG string.
Project data (project_data) — the cabin-builder source file (JSON) from which the SVG is produced.
Resource link (resource_id) — optional foreign key to the vessel/venue the map depicts.
Display headings — top_heading, main_heading, bottom_heading rendered above the map.
Small-fields vs full-data paths — two distinct write routes matched to payload size.

Tools

Tool	Class	Purpose
`inventorymaps_list`	Read	List maps ordered by most recent update; returns summary fields only (no SVG/project payloads).
`inventorymaps_get`	Read	Fetch one map's complete row including svg_data and project_data.
`inventorymaps_save_details`	Guarded write	Update only name, resource link, and headings via GraphQL; never touches layout data.
`inventorymaps_save`	Guarded write	Create a map or fully update one, including svg_data and project_data.
`inventorymaps_delete`	Guarded write (destructive)	Delete a map permanently.

Rules worth knowing

List responses are intentionally shallow. The list tool omits svg_data and project_data so enumerating maps never drags megabyte-scale payloads through context; fetch individual maps for full data.
Two write paths with a division of labour. Metadata edits (rename, re-link, heading changes) should use the GraphQL details path; the REST save path exists for create and for replacing layout content.
Update is field-subset on both paths. Only supplied fields change; empty updates are rejected. Create versus update is determined by presence of id.
Deletion is immediate and permanent behind the destructive guarded-write gate, with a preview step showing the current row before confirmation.
Schema tolerance by probe. Read queries adapt at runtime to whether this tenant's schema exposes the resource relationship, caching the result per tenant — older schemas still list cleanly without the join.
Concurrent-edit protection. Both write paths fingerprint the existing row before preview and recompute before execution, so interleaved edits force re-review rather than silent overwrite.
Explicit tenant required for writes, as with all mutating modules in the server.

Layout templates — the bookable structure that complements a map's visual geometry.
Resources — the vessels/venues maps attach to.
Schedule — services render and allocate against mapped layouts.