Gift vouchers module — JetSetGo MCP reference
The giftvouchers module manages vouchers after they exist: looking them up, reporting on the population, adjusting balances, and voiding. Vouchers themselves are issued by the booking/payment flow — this module deliberately has no create capability.
What the operator uses it for
Looking up a specific voucher to check its code, balance, status, recipient, or issuing booking; producing aggregate figures (issued, outstanding, redeemed, expired, voided, pending, soon-to-expire) over a date range; correcting a balance with a noted adjustment; and permanently cancelling a voucher, for example when one is lost or issued in error.
Where it sits
Downstream of the booking/payment flow, which issues vouchers as products are sold; recipients connect vouchers to customer records in the clients CRM. Redemption against future purchases also happens in the booking flow — this module observes and corrects but does not redeem. Voids are a status change rather than a deletion, so voided vouchers remain listed and auditable here.
Key concepts
- Voucher — a coded store-of-value with a balance, a status (active, redeemed, expired, voided, among others), a recipient, and an issuing booking reference.
- Issuance — happens only through the booking/payment flow; not exposed here.
- Adjustment — a signed delta applied to the balance with a mandatory reason note.
- Void — the terminal off-state: irreversible, remaining value forfeited.
- Report — aggregate counts and sums across the whole voucher population for a period.
Tools
| Tool | Class | Purpose |
|---|---|---|
giftvouchers_list |
Read | List vouchers paginated, filterable by status, text search, and date range. |
giftvouchers_get |
Read | One voucher by id: code, balance, status, recipient, source booking. |
giftvouchers_report |
Read | Aggregate report — counts and sums by state over an optional date window. |
giftvouchers_adjust |
Guarded write | Change a balance by a signed amount; reason notes required. |
giftvouchers_void |
Guarded write (destructive) | Void a voucher irreversibly; remaining balance is lost. |
Both writes require an explicit tenant and follow preview-then-confirm; the preview shows the current balance before the change.
Rules worth knowing
- No creation path exists here by design. Vouchers come into being through sales; an assistant asked to "make a voucher" should explain issuance happens at purchase time.
- Voiding cannot be undone and forfeits whatever value remains. The voucher stays visible in listings and lookups afterwards — voided is a status, not a deletion — so history remains auditable.
- Server-side status rules gate both writes: for example an already-voided or expired voucher cannot be voided again; the tool surfaces these as validation errors rather than attempting the call blindly.
- Adjustments require notes. The reason travels with the change, keeping the audit trail meaningful; positive amounts add, negative subtract.
- The approval card names the voucher. Previews display the human-readable code and recipient rather than a bare internal id, so confirmations are checked against the right voucher.