Zooza MCP Server

Only numbers and dates differ: this server embeds live figures in the definition, so the text moves without the contract changing.

 ⟨614 unchanged words⟩ to the user — diagnostic only.

[SURFACE_BUILD: 0.15.00.20.8]

Call any Zooza tool by name — Runs a Zooza tool by name. Use it for every Zooza tool that is NOT in your tool list — these exist and work; never send the user to another app because a Zooza tool isn't listed. Call get_tool_schema(name) first for the arguments. Write tools behave exactly as when called directly: the first call previews and returns a token, the second (token + confirmed:true) applies. Tools reachable this way: - bookings_add_lead: Add a lead (minimal registration on a lead-collection schedule) - classes_add_course: Create a new programme (course) - classes_add_share_link: Create a private registration link …

Get a Zooza tool's input schema — Returns the description and exact input schema of a Zooza tool, including tools not in your tool list (call_tool lists them). Call it once per tool before that tool's first call_tool.

Add a lead (minimal registration on a lead-collection schedule) — Create a LEAD — a lightweight registration on a lead-collection schedule — for a prospective customer, from their name and email. Use this to capture an inbound enquiry as a trackable Zooza record you can later label, message, and check for conversion. It does NOT enrol the person in a real class, take payment, or email the customer (the server authenticates with an App-type key, which sends no customer communication). It works ONLY against schedules whose type is `lead_collection`; for a genuine class booking, or anything that should charge or notify the customer, do NOT use this tool. Not i…

Create a new programme (course) — Create a new programme (course) — the top-level container in Zooza that holds pricing, payment settings, and booking-form configuration. Classes and sessions are added inside it afterwards; a programme cannot accept bookings until it has at least one class. IMPORTANT routing rule: only create a programme for a genuinely NEW product or offering. If the user is re-running an existing programme — new term, new time slot, new venue, new instructor — do NOT create a programme; create a class inside the existing programme instead (classes_preview_schedule → classes_commit_class; the class inherits …

Commit a class (schedule + events) — Writes a class to api-v1 in one shot: creates the schedule, attaches any selected payment templates (bundled inline), and posts the assembled events array. Call this only after the user has confirmed the class shell (from `classes_preview_schedule`) and the full event list (accumulated from one or more `classes_preview_events` calls). For lead-collection classes, pass `events: []`. Returns the created schedule's id and url plus the list of created event ids. If api-v1 silently skips any events (a known quirk), the tool surfaces the mismatch as an error so the caller knows the partial state. …

List valid Zooza schedule patterns — Returns all valid field values for building class schedules and payment plans in Zooza. No Zooza API call — hardcoded from Events_Preview.php and Payment_Schedule.php. Call this BEFORE classes_preview_schedule or classes_commit_class to avoid validation errors. Critical: weekdays must be 3-letter lowercase (mon/tue/wed...), NOT 'monday' or '1'. Critical: until_date and count are mutually exclusive — sending both causes an API error. Examples: domain="event_generation" → cadences, weekdays, time format; domain="payment_schedule" → schedule types and billing frequencies; empty call → both secti…

Preview class session dates — Expands one or more recurrence patterns and/or ad-hoc dates into the concrete list of class sessions, honouring holiday-skip flags. Stateless — performs no writes. Call this once per pattern the user describes during class creation. Accumulate the returned sessions across multiple calls (Claude side) until the user says they're done, then pass the full list to `classes_commit_class`. Each block must carry EXACTLY ONE of `count` (stop after N sessions) or `until_date` (stop on a fixed date) — count mode is preferred when the user says "X sessions". A top-level `to_date` acts as a fallback `unt…

Preview a class schedule shell — Resolves a new class's *schedule shell* — the course, venue, trainer, capacity, prices, billing period, and default payment templates — and returns the result alongside any warnings. Performs no writes. Use this first in a class-creation flow to confirm the basic class settings with the user before collecting session dates via `classes_preview_events` and committing via `classes_commit_class`. Defaults are copied from the parent course where the caller hasn't specified them (capacity from `target_audience`, prices from the course's pricing fields). Always surface the `warnings[]` array to the…

Change programme settings (preview, then apply) — Change the settings of an existing programme (course) — pricing, online booking, make-up sessions, trial, auto-enrolment, attendance, feedback, basic info, or archiving. Works one section at a time, like the settings tiles in the Zooza app. TWO CALLS. First call WITHOUT `token`: returns a diff of current → proposed values, warnings, and a single-use token. Show that diff to the user and get their approval. Second call with `token` + `confirmed: true`: applies it. Send nothing else on the second call — the token already carries the change. The token expires in 15 minutes; if it is expired or …

Read inbound customer replies and set a reply's state — Read inbound replies a customer has sent back to Zooza emails, and optionally mark a reply handled. Use it to see whether a lead responded and what they said — filter by the lead's registration id, sender email, state (unread / todo / resolved), or date. To act on a reply, pass `mark_reply_id` + `mark_state` to flag it `todo` (needs a human) or `resolved` (handled), or `read`. Replies only appear here if the original email went out through Zooza tied to that registration. This does NOT send anything — use comms_send_message to reply. The idempotency pattern: read `unread` replies, act, then m…

List Zooza message merge variables — Returns all valid merge variables for Zooza message templates (email, SMS, WhatsApp). Format: *|VARIABLE_NAME|* (MailChimp-compatible). No Zooza API call — hardcoded from Merge_Vars::merge_vars() in api-v1. Use this BEFORE writing any message template to get correct variable names. Claude must not invent variable names — only variables listed here are valid. Examples: category="financial" → payment and balance vars; medium="sms" → SMS-safe vars with HTML warnings; empty call → full catalogue grouped by category.

List the company's automated email templates — Lists the automated email templates Zooza sends to this company's clients — registration confirmations, trial follow-ups, cancellation notices, session reminders, loyalty/discount emails, and custom templates. For each template returns its trigger `type`, subject line, and whether the company uses the stock Zooza default or has customized it. Use this to see which automated emails exist, check what has been customized, or look up a template's `type` before previewing or sending it (comms_send_message accepts that `type`). This tool only lists email templates — for the merge variables (*|FIRST…

Explain Zooza data model — Returns a structured description of Zooza's domain entities — hierarchy, roles, valid field values (enums), parent/child relationships, and disambiguation rules. No Zooza API call is made — purely hardcoded domain knowledge. Call this before any class-creation, booking, or attendance tool to avoid entity confusion. Examples: entity="programme" → registration_type enums; entity="booking" → status values; entity="credit" → make-up / replacement entitlements (the "unused/expired make-ups" and "credits" concept); empty call → full hierarchy with all entities.

Attach or detach a label on a course, schedule, or registration — Attach or detach a label (a named tag) on a Zooza course, schedule, or registration. Set `present: true` to attach (the label is created automatically if it doesn't exist yet — attach is idempotent), `present: false` to detach. Use it to tag records for grouping or pipeline state — e.g. mark a lead registration `converted`, or flag one `todo`. Works ONLY on courses, schedules, and registrations. NOTE: labels on a SCHEDULE can be customer-visible on the public booking widget (output flags this as `public_facing`); labels on courses and registrations are internal. Does not send anything.

Negotiate terminology — build a personalised vocabulary profile — Free tool — no Zooza API call, no company_id required. Two modes: "start" → returns the 8-question interview template for Claude to conduct conversationally. "build" → validates answers against the Zooza glossary, returns a TerminologyProfile JSON plus a /remember instruction so Claude saves the profile to memory. Run once per user. The saved profile is auto-loaded in every future Zooza session — no re-configuration needed. Call get_skill('negotiate-terminology') before starting the interview.

Apply a payment plan to a booking — Put a booking on a payment plan — the instalment calendar the client actually pays against. A plan attached to a programme or class is NOT inherited by bookings; each booking has to have it applied, and until then the client owes nothing and sees no payment schedule. TWO CALLS. First WITHOUT `token`: writes nothing and returns the TOTAL plus the instalment dates and how many sessions each one covers. Zooza's preview does not expose per-instalment amounts before the plan exists — divide the total by the instalment count when telling the user, and say it is the expected split. Show that to the…

Add a session summary — Write a post-session summary on one event. Two independent fields: - `public_summary` — visible to attendees / parents via their in-app Zooza feed. Use when the user says "write a summary for the parents," "send a recap," "note for the families," etc. After write, every attendee's Person_Feed gets a `SUMMARY_PUBLIC` entry — parents see it in their client portal. - `internal_summary` — admin / team only. Use when the user says "add a note for the team," "private note," "reminder for next week," etc. Not visible to parents. At least one of the two must be provided. Both can be written in one …

Create a payment plan template — Create a company-level payment plan template ("splátková šablóna") — the object that defines HOW a programme's price is collected: in how many instalments, how often, with what discount and rounding. A programme set to instalment collection produces NO instalment schedule until a template is attached, so this is the step that makes instalment billing actually happen. CRITICAL — the template does NOT carry the price. The amount always comes from the programme/class; the template only says how to split it. So "€200 in 4 × €50" is: programme price 200 (set via classes_add_course or classes_upda…

Set a programme's payment plan templates — Choose which payment plan templates a programme offers clients — attach new ones, and DETACH ones that should not be there. Detaching is the point: Zooza attaches templates by itself when a programme's price type or payment collection changes, and on a company with many templates that can silently put dozens of plans on a programme. This is how you clean that up. TWO CALLS. First WITHOUT `token`: writes nothing and returns what is attached now, what would be attached, and the exact attach/detach list. Show it to the operator. Then call again with `token` + `confirmed: true` to apply. `templ…

Submit feedback to engineering — Submit user feedback about the Zooza MCP integration to the engineering team. Two paths: - 'path: "github"' — returns a prefilled issue-creation URL on the **public** `zooza-dev/zooza-mcp-server` repo. The user opens it in their browser and files the issue themselves (no MCP-side auth). The body MUST be fully anonymized (no user_id, company_id, company name, user email/name, course/class/event names, customer/client identifiers). The server runs a safety-net regex and will reject the call if obvious identifiers (long numbers, emails) remain. - 'path: "internal"' — files an issue on the user'…

Create an operator to-do item — Create a to-do item for a Zooza operator — a task a human needs to action. Give it a `message` and the `to_user_id` of the person it's assigned to. Optionally link it to a record (`entity_type` + `entity_id`, e.g. a registration) so the operator can open the thing it's about, and set a `due_date`. Use this to escalate — e.g. a lead asked a question that needs a human reply. It creates an OPEN todo in Zooza's normal to-do list; it does not email anyone. There is no `inbound_reply` entity type — link a reply escalation to its registration instead.

Change the status of a to-do item — Change the status of a to-do item: `done` (completed), `cancelled` (won't do), or `open` (reopen). Only OPEN todos can be marked `done` or `cancelled`; a `done` or `cancelled` todo can only be reopened to `open`. Marking `done` stamps completion time automatically.

Add additional lecturers to classes and sessions — Register **additional lecturers** — a second instructor, assistant, or helper — on one or more classes, and control which of their sessions each one actually works. This is NOT how you set or change a class's main instructor (that is `classes_update`, or `sessions_update` for one-off substitutions); additional lecturers are extra people who work *alongside* the main instructor. By default a lecturer you add here works **every** session of the class — that is the normal arrangement. Restrict one to certain days by giving that assignment `weekdays` (1=Monday … 7=Sunday), or to hand-picked sessi…

Only numbers and dates differ: this server embeds live figures in the definition, so the text moves without the contract changing.

 ⟨614 unchanged words⟩ to the user — diagnostic only.

[SURFACE_BUILD: 0.14.30.15.0]