OmceanBooking

ADMIN-ONLY add ONE named entry to the customer-chatbot Knowledge LIST. This is background reference, distinct from authoritative Q&A. The name/text are screened server-side for attempts to reprogram the assistant. Calling this tool shows the exact entry for approval.

create_ai_chatbot_knowledge

ADMIN-ONLY add one authoritative customer-chatbot Q&A training pair. The question and answer are screened server-side for attempts to reprogram the assistant. Calling this tool shows the exact new pair for approval; do not pre-ask in chat.

create_ai_chatbot_qa

Create a new class type. Requires an existing location_id (list_locations first). reservation_type decides how customers pay: "pass" (pass only), "one-off" (drop-in price), or "both". Link passes either here via accepted_pass_ids or later from the pass side via create_pass accepted_class_ids — once, not both.

create_class

Create a class CATEGORY (name + optional calendar colour "#RRGGBB"), optionally putting classes into it right away (class_ids). Categories help customers filter classes and colour-code the schedule.

create_class_category

Create a class ROOM (a physical space, e.g. "Studio A"): name, location (list_locations), capacity, optional description. After creating, assign it as a class's default room (update_class class_room_id) or to individual sessions (set_session_room).

create_class_room

Create a COURSE: a named, fixed-length program customers book as ONE purchase, e.g. "Beginner Pottery — 6 weeks". Use when the user says course, program, term, block or "X weeks". NOT an ongoing weekly class (create_recurring_class) and NOT a single date (create_schedule_session). A course IS its dated sessions — session_dates + start_time are REQUIRED and every calendar session is created in this ONE call (never loop create_schedule_session for a new course). COLLECT WITH THE CANONICAL FORM: when anything is unstated, call ask_form with template:"course" (never compose the questions yourself) — its builder collects the session DATES one at a time (all sharing the start_time), passing `prefills` for values you already know (the stated course name; record NUMBERS from your reads; "HH:MM" for start_time). The form result returns `bound_args` — call THIS tool with bound_args.args EXACTLY (you may add optional fields like size or name_cn); never retype or reshape those values, especially the session_dates array. NEVER build option strings from list_classes/list_instructors: a typed list sends back a display label you then have to guess an id from, and it breaks outright when only one record exists.

create_course

ADMIN-ONLY: add one dependent to an existing customer's account. OWNER/DEPENDENT PARSING: in a concise request `X 新增依屬 Y` (or `add Y as X's dependent`), X is the existing CUSTOMER ACCOUNT and Y is the exact dependent name. You MUST call find_customers for a named X before claiming the account is absent or asking for another identifier, even when X looks like a placeholder/reservation label. Never search for a person's name contained inside Y or reinterpret reserve/date wording inside Y as a booking, waiting-list request, or note. Unless the user explicitly labels separate notes, keep the entire quoted Y in customer_dependency_name and omit customer_dependency_notes. Supplied X and Y are complete input, so do not ask a form. MISSING INPUT: when either owner or dependent name is missing, FIRST call exactly ask_form({template:"customer_dependency_create", prefills:{...known values}}) and omit questions; do not call list_customer_dependencies before this form supplies customer_id. This server-owned form always keeps the customer_picker and required customer_dependency_name text field together; never split them across forms or ask for either in chat. The submitted bound_args are the exact complete user-supplied values. Then call list_customer_dependencies with that customer_id. If dependencies are enabled and the exact name is absent, immediately call create_customer_dependency with bound_args.args exactly. Reservation, placeholder, transfer, date, or time wording is valid inside customer_dependency_name: never question whether the owner really means that name and never ask for another conversational confirmation. The write's normal approval card is the only remaining confirmation. Do not create an exact duplicate. The server refuses the write when customer dependencies are disabled. If disabled, offer to enable customer_dependencies in Customer settings first. Profile pictures are not editable through this tool.

create_customer_dependency

Create an equipment item and optional physical units. An English or Chinese name is required. Defaults are capacity 1, exclusive assignment, standalone, hidden unit names, optional, zero price, and one active unit. Create grouped items with equipment_in_group=true, then add them to a group with create_equipment_group or update_equipment_group. Class assignment is a separate set_class_equipment step.

create_equipment

Create an equipment group, optionally with ordered grouped-equipment members. equipment_group_allocation=automatic allocates equipment for the customer; customer_choice lets them choose. equipment_group_allocation_mode=sequential fills in priority order, balanced spreads use, and optimized currently starts with sequential allocation and forces equipment_group_keep_together to preferred. Never promise a later automatic reassignment.

create_equipment_group

Create an intake form, cancellation form, survey, or post-class feedback form from existing item IDs, including INFO_BOX, PARAGRAPH and ADD_DEPENDENT. Optional intake_form_conditions sets per-item visibility/required rules. Choose a different simple question in this form as the source; no self references, cycles, dependent/content sources or compound AND/OR groups. SELECT conditions compare the numeric option_id, not its label. Content items allow visibility only. BEFORE creating any form or question for it, ALWAYS call list_intake_forms to verify the feature and rule out a duplicate, then list_intake_items to reuse equivalent questions. If either prerequisite read returns an error, STOP and ask the user to retry; never treat an unreadable library as empty, create replacement questions from scratch, or try get_intake_form as a workaround. If the requested outcome does not make the type clear, ask whether this is an intake form (during class booking/pass purchase), cancellation form (before cancelling a class reservation), feedback form (after an attended class), or survey (sent to a customer audience) before writing. Intake, cancellation and feedback forms become active when created; surveys remain drafts until publish_survey. Intake forms must target a class or pass; cancellation forms may target selected classes or all classes when class_ids is empty and never target passes; feedback forms target classes only; surveys target customers/roles/tags only. A required cancellation form blocks cancellation until submitted, while an optional form may be skipped. This never submits answers for a customer.

create_intake_form

Create one reusable question or content/dependent item for an intake form, survey or feedback form. INFO_BOX is a callout with optional emoji (default none); PARAGRAPH is plain text. Both require message_en or message_cn using the canonical field names, allow both languages, and cannot be required or have default answers. ADD_DEPENDENT embeds the customer dependent form; this action creates only the reusable item, never a customer dependent. This backend action is page-independent: create it directly from Content or any other admin tab and never navigate to Form Items first. SELECT questions require choices. Question type is permanent after creation, so verify it carefully. Creating a question does not attach it to a form.

create_intake_item

Create a new location (studio/branch). Only `name` is required. Omit `business_hours` when the owner does not want to configure opening hours; the stored time defaults remain inactive until business hours are explicitly configured. During onboarding, call this ONLY when list_locations returned no location; if one already exists, update that exact location instead of creating a duplicate. Create/update the location before classes and passes because both reference location_id.

create_location

Create a new pass. type "classes" needs number_of_visits (e.g. 10-class pack), "membership" is unlimited visits within duration_days, "points" uses a point balance. Defaults to sold in-person only — set purchase_online=true to let customers buy it themselves.

create_pass

ADMIN-ONLY create a discount, coupon, or referral campaign. The Discounts custom feature must already be enabled. Coupon codes are trimmed, uppercased, checked against existing coupon and generated referral codes, and then become immutable. Percentage values are 1–99. GIVEAWAY is coupon-only. For a named but unresolved audience such as “students”, first ask how they are identified (an existing role, tag, or specific customers); never silently turn that request into an all-customer promotion and never guess IDs. For restricted eligibility, pass explicit customer/role/tag ids. Like every write, calling this tool shows the exact proposal for approval.

create_promotion

Create a REPEATING class: the same class every week (or fortnight) at fixed weekly time slots, running open-endedly from start_date. Use for "Yoga every Tuesday at 9" or "Mon 09:00 and Wed 18:00" — ONE call carries ALL the weekly slots via time_slots (never split into multiple calls). NOT a single date (create_schedule_session) and NOT a fixed-length program customers buy as one thing (create_course). Sessions are generated automatically. COLLECT WITH THE CANONICAL FORM — for ONE class or SEVERAL: always call ask_form with template:"repeating_class" (never compose the questions yourself); its slot builder captures a class + instructor PER SLOT, so a single form covers multiple classes' weekly schedules in one round. Pass `prefills` for values you already know (record NUMBERS from your reads; "YYYY-MM-DD" for start_date) so the obvious case is one tap. The form result returns `bound_args` — call THIS tool ONCE PER ENTRY in bound_args.calls, passing each entry EXACTLY (you may add optional fields like size); never retype, reshape, or merge them. Slots for different classes/instructors arrive as separate entries — one create call each. NEVER build option strings from list_classes/list_instructors: a typed list sends back a display label you then have to guess an id from, and it breaks outright when only one record exists.

create_recurring_class

Add ONE class session to the calendar on a specific date — a single occurrence, NOT a weekly repeat (use create_recurring_class) and NOT a multi-week program (use create_course). Use for "add a class on Friday" / "put on an extra session". Needs class_id and time "YYYY-MM-DD HH:MM" in the business timezone; end time derives from the class duration. Optional instructor_id, size, course_id (attach this session to an existing course). COLLECT WITH THE CANONICAL FORM — for ONE session or SEVERAL: call ask_form with template:"one_off_session" (never compose the questions yourself); its session builder captures a class + instructor per (date, time) entry, so one form can add several one-off sessions across classes. Pass `prefills` for values you already know (record NUMBERS from your reads). The form result returns `bound_args` — call THIS tool ONCE PER ENTRY in bound_args.calls, passing each entry EXACTLY (you may add optional fields like size or course_id); never retype, reshape, or merge them. NEVER build option strings from list_classes/list_instructors: a typed list sends back a display label you then have to guess an id from, and it breaks outright when only one record exists.

create_schedule_session

ADMIN-ONLY create one Shop category beneath an exact active shop_category_parent_category_id. Use a supplied exact ID, or resolve the parent with list_shop_categories when the user gives a name. PHP independently verifies that the parent exists and is active. This is a discrete insert and does not replace or reorder the category tree. Provide at least one localized name.

create_shop_category

ADMIN-ONLY create a simple Shop product with one non-variant purchasable item. The Shop feature must already be enabled. After creation, use set_shop_product_variant_matrix for variants and set_shop_product_addons for class/pass add-on links. Media remains page-led.

create_shop_product

Create a tag with English/Chinese name and public visibility. Relationship assignment is separate so creating a tag cannot replace existing links.

create_tag

Soft-delete one exact class-schedule announcement. PHP verifies both custom_feature_blog_id and class_schedule_id plus selected-location scope. Existing delivered notifications are not recalled.

delete_class_schedule_announcement

Soft-delete one ordinary Blog, News, or global Announcement after resolving and showing its exact custom_feature_blog_id. This removes it from the normal content surface. Schedule-bound announcements use delete_class_schedule_announcement.

delete_content_post

ADMIN-ONLY: soft-delete one dependent from a customer's account. Call list_customer_dependencies first and use its exact customer_dependency_id. This hides the dependent and can affect future booking choices, so confirm the exact name and account owner. Existing bookings, waitlists and their dependent links remain intact. Do not detach bookings before deletion. For multiple deletions or a selection request, use delete_customer_dependencies and its multi-select template instead. If the owner explicitly asks to cancel the dependent's active bookings too, use list_customer_dependency_bookings and cancel every selected active booking first with set_session_attendance action=remove; call this delete only after those cancellations succeed. Never claim booking cancellation is unavailable when set_session_attendance is present. The server refuses the write when dependencies are disabled.

delete_customer_dependency

ADMIN-ONLY APPOINTMENT DEBUGGER and settings audit for questions like “break down this service's times/settings”, “why isn't 18:10 showing on Monday?”, or “why can't this service be booked?”. Requires the service class_id and exact date; pass time for one missing chip/slot and instructor_id when the question names a practitioner. Reads duration, start-time interval, before/after buffers, weekly/special service hours, closures, connected practitioner hours, stored generated start-time chips, independently recalculated expected chips, actual available slots, and relevant recent service changes (only when this role may view the activity log). Duration is the customer's service length. Interval controls which displayed start chips are generated and can be shorter than duration. Buffers reserve practitioner/resource time before and after each booking; they do not change its displayed start or service duration. Each available slot includes its exact service_start_at/service_end_at and the larger reserved_from/reserved_until window; use those values to explain buffer impact without guessing. If generated_times_match_settings=false, report the stale-chip issue and do not describe the stored chips as correctly generated from the current settings. Otherwise, clearly separate generated_start_times (configured candidates) from available_slots (candidates with an eligible practitioner). Use issues[] as the factual explanation. A start time appears only when it is generated inside service hours AND at least one eligible connected practitioner remains after the booking engine applies practitioner hours, closures, buffers, existing bookings, room/capacity rules, and limits. Do not blame a setting merely because it exists; connect it to requested_time and issues. If recent_changes_visible=false, say you could verify current state but not inspect change history. PRESENTATION: those snake_case names are internal tool keys, never owner-facing labels. Follow reply_instruction and translate every setting/key to plain app language; do not echo a snake_case identifier unless the owner explicitly asks for raw technical fields.

diagnose_appointment_availability

ADMIN-ONLY evidence diagnostic for why one customer is or is not being asked for the business waiver. Checks feature enabled, live/content state, latest version, and that customer’s current acceptance pointer. Lead with the first issue. Does not expose signatures or alter/revoke acceptance.

diagnose_business_waiver

Diagnose the effective future sessions and sold-out risks for one class-package pass. When the user supplies an exact pass_id, call this tool immediately with it; do not list packages, passes, classes, custom features, or settings first. The response performs its own feature/pass validation. Creation/edit/archive stays page-led because production uses a full pass save with three replace-all relationship sets plus cart/sold-out recalculation; the agent will not risk clobbering unrelated pass state.

diagnose_class_package

ADMIN-ONLY, READ-ONLY coupon/referral-code debugger. Use for “why did this code fail?”. It checks feature state, normalized code lookup, deleted/archived/date/usage-limit state, and—when customer_id is supplied—customer scope, new-customer/one-use/active-pass rules and self-referral. Pass one pass_id or shop_item_group_id to also verify item applicability. eligible=null means required customer or item context was omitted; state exactly what was not checked. This never changes a cart.

diagnose_coupon

READ-ONLY Gate debugger for why one customer is currently allowed or denied at a location. Evaluates business hours, explicit deny/allow, allow-all, reservation and active-pass rules using the same access engine as the gate. This evaluates now; use access history for a past event.

diagnose_gate_access

ADMIN-ONLY, READ-ONLY evidence diagnostic for “why did/didn’t this customer see an intake, cancellation, survey, or feedback request?”. Checks feature/form state, assignments, targeting, response state, expiry, feedback attendance/timing facts, and cancellation reservation/class eligibility. Cancellation forms appear inline before the reservation is cancelled and never create pending to-dos. The FIRST sentence after this tool returns MUST state issues[0] verbatim when issues is non-empty; do not summarize form/customer metadata before the blocker. Then add only useful facts. Never invent a motive or claim a notification was sent.

diagnose_intake_delivery

ADMIN-ONLY read-only debugger for why a pass purchase, shop purchase, or class attendance did or did not earn loyalty rewards. Checks the feature, live setting, effective default/override, attendance/payment-linked reward state, and computes the expected amount when price is supplied for percentage purchase rewards.

diagnose_loyalty_reward

ADMIN-ONLY read-only pass rollover debugger. Given the newly purchased destination pass and optionally an expected source pass, evaluates the same major gates as automatic rollover: feature/mode, customer and pass type/template, membership/subscription exclusion, destination verification, source activation/expiration threshold, payment verification, and remaining visits.

diagnose_pass_rollover

ADMIN-ONLY evidence diagnostic for why a pass template or purchased pass does/does not require a waiver. Checks feature/global live state, the one effective pass assignment, purchased-pass currentness/expiry/cancellation, and optionally customer ownership. Lead with the first issue; never alter or forge acceptance.

diagnose_pass_waiver

Diagnose one exact pause with affected passes, estimated original expiries, upcoming reservation counts, and exact global-booking consequences. When the message contains a pause_id, call this tool immediately with that ID—do not list pauses, read generic settings, custom features, or activity logs first. Call before reversing/ending a pause.

diagnose_pause_account

ADMIN-ONLY explain the effective commission mode/configuration and stored attribution for one sold pass or shop item. When the request already supplies an exact pass_purchased_id or shop_item_quantity_id, call this tool immediately with that ID; do not detour through salesperson settings, custom-feature lists, customer/staff search, or inventory lists.

diagnose_sales_commission

ADMIN-ONLY read-only Shop order debugger by payment ID or reference. Explains the exact payment status, deletion, inventory verification, and pickup state without exposing bank/payment secrets.

diagnose_shop_order

ADMIN-ONLY read-only recurring-payment debugger for the initial pass_purchased_id returned by list_customer_subscriptions (a renewal pass ID is also resolved safely). Checks subscription status/failure count and the exact payment/deletion state of the initial and every renewal payment. When the owner asks about charges or payment history, present EVERY returned payment with its amount and payment_status_enum; never collapse the rows to only a count or latest payment. It does not expose provider response payloads or secrets and cannot prove the bank/card decline reason when the provider did not store one.

diagnose_subscription

ADMIN-ONLY end one promotion immediately by setting its end date to yesterday in the business timezone. Read get_promotion first. This preserves history and rechecks active carts; use update_promotion instead to schedule a future end date.

end_promotion

Set the final active date of ONE repeating class. First call list_recurring_classes and use its exact class_recurring_id. Future generated sessions after end_date are removed by the normal calendar refresh; this keeps the repeating definition and its history.

end_recurring_class

End one live survey now. This expires its outstanding pending to-dos but keeps completed responses. Read it first and identify the survey.

end_survey

READ-ONLY customer search by name, email, or phone fragment. Returns id, name, email, phone. Use FIRST whenever the user mentions an existing person as the CUSTOMER, booking holder, pass owner, or profile target — even when their display name includes “teacher” or the same account also holds an admin/manager/instructor role. Roles and customer bookings are not mutually exclusive. Use find_staff instead only when the requested relationship is their staff role, team membership, permissions, or staff-owned configuration. Then use get_customer_overview when that overview is relevant. To add a genuinely new customer use create_customer; never use create_customer before searching for a possible duplicate.

find_customers

ADMIN-ONLY, READ-ONLY staff/team search — everyone in the signed-in business holding a role (Account admin, Manager, Instructor, custom roles). A role does not stop the same account from holding customer bookings or passes. Returns each staff member with their roles (incl. the role_id set_staff_role acts on) and last login, the total, and business-wide per-role headcounts. Answers "who is on my team", "find staff member X", "how many account admins / instructors do we have", "who has the Manager role". Omit `search` to list everyone. When the requested relationship is that person’s customer booking, pass, or customer profile, use find_customers instead even if they are also staff. To grant/remove a role use set_staff_role; to create/rename roles or edit per-role permissions direct the user to the Users page.

find_staff