Connecting Claude, ChatGPT and Cursor to a gym's schedule over MCP

I build Sessy, member management software for gyms, CrossFit boxes, yoga studios, personal trainers and similar businesses. Most of the people who use it are not developers. They're owners and coaches who plan the timetable on Sunday evening.

In version 11 we fully opened up our MCP server, so owners can connect the AI tool they already use (Claude, ChatGPT, Cursor, Gemini, Grok and others) to their gym. Here's how it works, and how we decided how much an AI should be allowed to change.

MCP in two paragraphs

The Model Context Protocol is an open standard for connecting AI applications to outside systems. A server exposes tools (functions the model can call, like "list sessions" or "book member") and resources (documents the model can read). A client (Claude, ChatGPT, Cursor and so on) connects to the server, finds out what's there and lets the model use it during a conversation.

For a SaaS product, that means one server instead of a plugin per AI vendor. Ours runs at https://mcp.sessy.app over Streamable HTTP (JSON-RPC over POST) and uses a bearer token for authentication.

Getting connected

An admin creates the token inside Sessy under Configuration → Sessy AI → External access (MCP). You name it, pick the employee it belongs to and choose two access levels (more on those below). The token is shown once and can be revoked from the same screen.

In Cursor, the config looks roughly like this:

{
  "mcpServers": {
    "sessy": {
      "url": "https://mcp.sessy.app",
      "headers": {
        "Authorization": "Bearer YOUR_SESSY_TOKEN"
      }
    }
  }
}

In Claude or ChatGPT you add a custom connector with the same URL and token. For non-technical staff, the docs also include a ready-made prompt with the URL, transport and auth method. You paste it into your assistant and it walks you through the setup. To check it worked, ask "What Sessy tools do you have?" in a new chat.

Scoping: two dials per token

Every token is tied to one employee and has two settings.

Token access: Admin or Employee. An Employee token can't change gym-wide configuration. An Admin token can also manage locations, session types, subscriptions, shop items and tag definitions. A token can never have more rights than the person it belongs to.

Data access: Full or Limited (no member data). This one is about privacy. When you connect an external model, whatever Sessy returns goes to that AI vendor. With Limited turned on, the server blocks every tool that would expose member names, emails, booking lists, attendance history, staff notes, tags, targeted push audiences or revenue. It also strips member identifiers from schedule reads, so the assistant sees that a class has 11 bookings but not who they are.

A Limited token can still plan and edit the calendar, fill a week from templates, assign coaches, link workouts, post a gym-wide banner, draft newsletters and (for admins) change the gym setup.

Teaching the model the rules

Giving a model a list of tools isn't enough. It needs to know how the business works. Sessy has a few rules that a general-purpose model would never guess:

• The recurring schedule (your standard weekly pattern) is separate from the session calendar (the classes members can actually book). To plan next week you apply the template. You don't copy last week class by class.
• Members can only log results against programming if the session is linked to a real workoutId from the workout library. A text description like "Fran" isn't enough.
• Newsletter drafts need HTML, or they show up in the editor as one unformatted block.

So the server also provides built-in guides as resources: an overview, the data model, a tools reference, limits and safety, and workflow guides for scheduling a week, managing sessions, booking, programming, notifications, newsletters, notes and tags, reports, and (for admins) configuration. The first one a client should read is the access profile (sessy://skills/access-profile). It lists exactly which tools this token can use. Limited tokens don't even receive the guides for workflows they can't run.

The goal is for the model to learn the rules before its first write, not by hitting errors.

What people ask it

From our docs:

• "Fill next week's timetable at [location] from the recurring schedule."
• "Move tomorrow's 6pm class to 7pm." / "Program Fran on it so members can log results."
• "Book [member] into tomorrow's 7am class." / "What was last month's revenue?" (Full data only)
• "Add a session type called Hyrox." / "Create a 10-visit pass." (Admin only)

A realistic flow

Say a box owner is in Claude with an Admin token with full data access and types:

Plan next week at the main location from the recurring schedule, put Kees on the Monday and Wednesday 18:00 classes, program Fran on Friday's 07:00, then draft a short newsletter about the new Saturday open gym.

A well-behaved client does roughly this:

1. Reads the access profile and the schedule-week guide.
2. Applies the recurring template for that location and week. This is one write, not twenty.
3. Reads the resulting sessions and assigns the coach to the two matching slots.
4. Searches the benchmark library for Fran, gets its workoutId and links it to Friday's session.
5. Creates a newsletter draft in HTML and doesn't publish it.
6. Reports back what it changed.

Every one of these calls goes through the same validation as the app. If the session type doesn't exist, the class is full, the subscription doesn't match or the date is outside the scheduling window, the request is rejected just as it would be in the app.

Where the confirm step lives

Sessy has two AI paths. The in-app assistant never saves anything on its own. It shows a preview, and a staff member taps Confirm. That's the right default for a tool the whole front desk uses.

The MCP path is different. When a connected agent makes a valid call, the change is applied right away, and Sessy shows no preview. We chose this on purpose. People connect external agents for batch work and long multi-step sessions, and a confirmation for every call would make that impossible. The confirmation step then belongs to the client. Most MCP clients ask you before they run a tool, and you should leave that on for write actions.

Because we can't control the client, the server has hard limits of its own:

• Tokens are scoped to one gym, one employee and one role, as described above.
• Writes are rate-limited to 30 per minute and 500 per day per token. Applying a recurring week counts as one write, which is another reason the guides push the model toward templates.
• Tokens cannot delete the gym, assign Admin roles or change platform billing.
• The guides mark mass messages and newsletter publishing as sensitive actions.

My advice to owners: start with a Limited token, keep tool approval switched on in your client, and only move to Full once you trust how it behaves.

The privacy part, plainly

With MCP, data leaves Sessy and goes to the AI vendor you chose. That vendor becomes the gym's processor, not ours, and its retention and training terms apply. If you want processing to stay inside Sessy's own EU-hosted setup, use the in-app assistant. If you use MCP, the Limited preset is how you keep member data away from the vendor.

Wrapping up

Most of the work in building this wasn't the protocol. It was deciding what the model is allowed to see, what it must know before acting, and what the server refuses no matter what the prompt says. If you're adding MCP to your own product, I'd spend most of your effort there.

The full setup guide, including the per-client steps and the complete Limited/Full matrix, is here: https://sessy.app/en/docs/settings-config/agent-mcp/

Questions and criticism welcome in the comments.