gymflexa.com

# Safe gym operations with GymFlexa This skill drives the GymFlexa MCP connector. The user must connect GymFlexa and authorize an account with live access to the intended organization. If authorization fails, ask the user to connect GymFlexa. Never request, embed, or repeat an API key, password, OAuth token, payment credential, or webhook secret. ## Read-only administrative boundary Every available tool is read-only, idempotent, tenant-scoped, bounded, and closed-world. The connector cannot create, edit, book, reschedule, cancel, delete, message, charge, refund, retry, settle, transfer, or move funds. It cannot provide workout, nutrition, medical, insurance, employment, credit, eligibility, or another individualized or high-impact recommendation. Do not imply that a read changed GymFlexa. For a requested change, offer a relevant safe inspection and direct the authorized operator to first-party controls. ## Resource identifiers and tenant checks `gymId` is the only exposed record identifier. It must be an exact lowercase 24-character hex id returned by `list_gyms`. It selects one gym owned by the signed-in user's organization and scopes every follow-up read. Never guess an id, treat an opaque id as authority, or reuse one from another organization. Malformed and cross-tenant ids fail closed. The availability API is also used by GymFlexa's public booking page. The connector must finish its tenant-owned gym lookup before calling that route. If ownership cannot be proved, stop; never use public availability as a cross-tenant fallback. ## Available tools | Tool | Use it when someone asks… | | -------------------------- | ---------------------------------------------------------------------------------------- | | `list_gyms` | which gyms they run; also resolves the gym id every other tool needs | | `get_gym` | for a gym's opening hours, timezone, currency or session length | | `get_gym_availability` | when there are free session slots, or which coming days are fully booked (up to 14 days) | | `get_gym_schedule_summary` | how busy each UTC day is, past or upcoming (booking counts, at most 31 days) | | `get_gym_payment_summary` | how much was taken in, by status and currency (at most 31 days) | | `list_services` | what a class, personal training session or other service costs | | `show_gym_overview` | for a one-card overview of one gym | `list_gyms` and `list_services` use opaque cursors and accept a maximum page of 100. Report `hasMore` and reuse `nextCursor`; never claim completeness when more pages exist. A cursor is query-bound and must not be reused for another gym. Both summary tools inspect at most 101 source records, return at most 100, and mark `recordCountIsLowerBound` when more exist. Their default range starts now and runs seven days forward, and their maximum is 31 days; pass explicit past dates for past payments or past workload. The overview counts at most 100 scheduled records, previews 12 services, and examines at most 14 availability days. A displayed `+` count is a lower bound, not an estimate of the total. ## Privacy boundary Safe results may include owned gym ids and display metadata; safe locale, currency, timezone and opening hours; public bookable-capacity summaries; service-catalog names/prices; UTC-day aggregate schedule counts; aggregate recorded payment statuses/totals; and no member-derived metric. The connector intentionally cannot expose: - member names, ids, email, phone, address, language, profile, arbitrary fields, attendance, workout, service or payment history; - links among members, appointments, services or payments; - individual appointment ids, exact booked times, statuses, services or notes; - trainer/staff identity, contact, schedule, commission or performance data; - individual payment ids or amounts, services, discounts, notes, decline reasons, processor/customer ids, cardholder data, credentials or errors; - gym contact/address, organization internals, billing/trial state, integrations, reminders, webhooks or arbitrary upstream documents; or - raw upstream errors, secrets, logs, files or conversation history. Do not infer, reconstruct, request, or ask the user to paste excluded fields. Offer safe configuration, capacity, catalog, aggregate schedule/payment, or first-party-dashboard alternatives. The overview never queries member records. Schedule and payment tools request only minimum fields for immediate aggregation and expose no person-linked record, identifier, exact booked time, or individual payment. ## Configuration and capacity audit 1. Use `list_gyms` unless the exact owned gym id is already available. 2. Call `get_gym` for timezone, opening hours and configured duration. 3. Call `get_gym_availability`. It follows the gym's own online-booking window (by default from two hours ahead to six months ahead) and returns the first 14 days that have openings. 4. Compare configured hours with daily slot counts and first/last bookable times. Do not extrapolate beyond the days it returns or infer why time is unavailable. Bookable availability times are administrative capacity, not an individual's booked appointment. The schedule summary deliberately does not return exact booked times. ## Schedule audit Use `get_gym_schedule_summary` with an explicit bounded range when the user's dates matter. It groups source `startTime` values by UTC calendar day, then discards each value. State that the day basis is UTC, that canceled bookings are counted, and that the count may be a lower bound. Never infer member identity, attendance, trainer assignment, service, status, or workload cause from a count. `show_gym_overview` uses a fixed seven-day schedule range and renders safe aggregate metrics without querying members. Avoid restating every number if a concise operational observation or next safe check answers the user. ## Catalog and recorded-payment audit Use `list_services` for catalog names and prices. A catalog price is configuration, not proof of a final charge or member purchase. Use `get_gym_payment_summary` only for aggregate administrative status. It returns status counts and amount totals by currency, never an individual row. The currency totals add every status, FAILED and CANCELED included, so they are not the amount actually collected; say so, and use the status counts to show how many payments succeeded. When `totalsArePartial` is true, say that totals cover only the bounded source records and must not be treated as the gym's full total. Recorded status is not independent proof of bank settlement. The connector cannot charge, refund, retry, settle, transfer, or otherwise move funds.