On-site printing module — JetSetGo MCP reference

The printers module manages on-premise printing for an operator's physical locations. A lightweight print-server agent runs at each site — behind the counter, at the wharf, on a vessel — and drives one or more locally-attached printer devices such as thermal receipt printers and ticket/label printers. Operators design ESC/POS templates (receipts, tickets, boarding passes, labels); the platform queues print jobs to a server, which the local agent polls and prints. Through JetSetGo MCP tools an operator can inspect servers, devices, templates, and the job queue, manage template content, cancel or retry jobs, and fire test prints.

What the operator uses it for

Keeping physical output working. The typical cycle: confirm which servers are online and when each was last seen; check what printer devices each server reports; author or duplicate a receipt, ticket, boarding-pass, or label template and set the per-type default; test-print to a real device to verify alignment; then monitor the job queue during service — cancelling a stuck pending job or re-printing a failed one without leaving the conversation.

Where it sits

Upstream, point-of-sale and booking flows are the real producers of print jobs — raw job creation is owned by those flows and deliberately not exposed as a tool here. Business identity and rendered data come from settings and resources (a resource is a bookable product). Downstream is the physical world: paper comes out of a device. There is no in-platform consumer of print data; a print job is a real-world side effect, which shapes the module's safety posture.

Key concepts

Print server — one installed site agent per location: name, location, connection status driven by device heartbeat, last-seen time, and active flag.
Printer device — a locally-attached printer synced up from its server agent. Devices are reported by hardware, not created by operators.
Template — an ESC/POS document definition with a type (receipt, ticket, boarding_pass, label), a paper width of 58 or 80 mm, nested sections, and optional per-type default status.
Print job — a queued unit of work with lifecycle pending → sent → printing → completed/failed, or cancelled, plus priority, timestamps, error message, and retry count.
Priority — stored as a low integer but surfaced through human labels low, normal, high, urgent; either form is accepted on input.
Soft delete — servers and templates are deactivated rather than erased, so history is retained.

Tools

Tool	Class	Purpose
`printers_servers_list`	Read	List print servers with status filters and pagination.
`printers_server_get`	Read	Fetch one server including its synced printer devices.
`printers_templates_list`	Read	List templates with type/active filters (summaries only).
`printers_template_get`	Read	Fetch one template including its full section definition.
`printers_health`	Read	Pending-job count and online/total server ratio.
`printers_jobs_list`	Read	List queued jobs with joined server/template names.
`printers_job_get`	Read	Fetch one job with the same enrichment.
`printers_server_update`	Guarded write	Rename a server and/or change its location.
`printers_server_delete`	Guarded write	Deactivate (soft-delete) a server.
`printers_template_create`	Guarded write	Create a new template.
`printers_template_update`	Guarded write	Edit a template; deactivating counts as soft-delete.
`printers_template_delete`	Guarded write	Soft-delete a template.
`printers_template_duplicate`	Guarded write	Copy an existing template as a starting point.
`printers_job_cancel`	Guarded write	Cancel a pending job.
`printers_job_retry`	Guarded write	Re-print a failed job by minting a new one.
`printers_template_test_print`	Guarded write	Print a real test output for a template.

Rules worth knowing

Retry and test prints create genuine jobs immediately — paper prints and cannot be undone. Their previews state this consequence explicitly before confirmation.
Cancellation only works while a job is still pending; once sent or beyond, the backend refuses it and that refusal is surfaced verbatim rather than silently swallowed.
Retrying does not reuse the failed job — it creates a new one, preserving the original's failure history.
Server and template deletes are soft: rows are hidden from default listings while history remains. Setting a template inactive via update is treated as a deactivate.
Printer devices appear automatically when their agent syncs; there is no tool to create or edit them directly, only to read them within a server's detail.
Template definitions are large nested documents; write previews summarize them (name, section count, paper width) instead of dumping content — fetch the full definition through the dedicated get tool.
Credential-bearing operations — issuing server enrollment codes and rotating server keys — are never exposed as AI tools so live credentials never enter model context; the operator performs registration in the app itself. Read results likewise carry only a safe display prefix of any credential.
Job reads join server and template names where the tenant's metadata allows; on untracked tenants they degrade to bare ids rather than failing.

Tickets — booking flows that enqueue boarding passes and receipts into this queue.
Settings — business identity rendered onto printed output.
Assets — vessels and vehicles where on-board print agents operate.