Allocation categories (inventory citizens) module — JetSetGo MCP reference

The inventorycitizens module manages allocation categories (internally inventory_citizens): the classifications that determine which kinds of sales channel or client segment can draw on inventory — for example travel agents, corporate clients, OTA partners, or walk-up trade. Each category is a small master-data record with a name, an importance value used as a conflict-resolution priority, and an active flag.

What the operator uses it for

When several allocation pathways can qualify for the same capacity, JetSetGo needs to know which pathway outranks which. Allocation categories provide that ranking: each carries an importance, and where multiple pathways qualify simultaneously, higher importance wins the conflict. Categories also act as the classification layer between client types and inventory — client types link to a category, so every client inherits an allocation identity, and resources reference categories when defining how their capacity is offered.

Typical maintenance is low-frequency: create a category per channel arrangement (agent, corporate, OTA partner), set its relative importance, and deactivate it when a channel arrangement ends. Unlike most JetSetGo master data, records here support hard deletion.

Where it sits

This is top-level reference data with no upstream dependencies. Downstream, client_types rows carry an inventory_citizen_id back-link, tying each client type to one allocation category; resources and the booking pipeline consult those links when deciding whether and how a booking pathway may consume capacity from structures built by layout templates.

Key concepts

Allocation category (inventory_citizens) — a named classification of who can access inventory.
Importance — integer priority; higher values win conflicts when multiple pathways qualify.
Active flag (is_active) — controls whether the category participates in new allocations without deleting it.
Client-type link — client_types.inventory_citizen_id points here; this is how individual clients inherit an allocation class.
Hard delete — unlike most master data in the platform, these records can be permanently deleted rather than only deactivated.

Tools

Tool	Class	Purpose
`inventorycitizens_list`	Read	List all allocation categories, ordered by importance descending then name.
`inventorycitizens_get`	Read	Fetch one category by id.
`inventorycitizens_save`	Guarded write	Create a category or update any subset of name, description, active flag, importance.
`inventorycitizens_delete`	Guarded write (destructive)	Permanently hard-delete a category; irreversible.

Rules worth knowing

Name is mandatory and trimmed. Create requires a non-empty name; updates reject whitespace-only names after trimming, on both paths.
Create-time defaults. is_active defaults to true, importance defaults to 0, and description defaults to null when omitted.
Update is subset-based. Any combination of the four editable fields may be sent; an update with no fields is rejected.
Deletion is real deletion. The delete tool removes the row outright via a primary-key delete — there is no soft-delete recovery, which is why it runs behind the destructive guarded-write gate.
Two-phase writes everywhere. All mutations preview first and require an explicit confirm token derived from a fingerprint of the current row; concurrent edits force re-review.
Explicit tenant required for writes. Reads fall back to the server default tenant; writes do not.
Ordering is significance-first. Lists are returned importance-descending then by name, mirroring how conflicts resolve.

Layout templates — build the capacity structures that allocation pathways draw on.
Capacity unit types — the consumable units those structures expose to allocation.
Rooms — accommodation units allocated through the same pathway logic.