When you connect a third-party app to MoveMentors via OAuth (the most common case: an AI assistant via MCP), you grant specific permission scopes. This article lists every scope and what it does.
The scope model
MoveMentors OAuth follows the standard OAuth 2.1 model with PKCE. You authorise a client (e.g. Claude), which receives a token tied to specific scopes. Each request the client makes is validated against those scopes.
If you grant only read:bookings, the client can only read bookings; attempts to use other tools return 403 Forbidden.
You can grant individual scopes during the OAuth consent flow. You can revoke at any time.
Read scopes
read:profile
Read your own user profile (name, email, account type, settings).
Required by almost every client. Granting this lets the AI know who you are; without it the assistant cannot personalise.
read:mentor
Read your mentor profile (bio, photos, locations, certifications).
For mentor accounts.
read:studio
Read your studio profile.
For studio accounts.
read:classes
Read the classes you host (title, schedule, capacity, price, etc).
read:bookings
Read your bookings (both as host and as student).
read:clients
Read your client CRM (clients who booked, their history, your notes).
read:financials
Read your earnings and expenses dashboard. Pro+ feature.
read:reviews
Read reviews on your profile and reviews you have left.
read:messages
Read your inbox (inquiries, mentor messages).
read:public
Search the public directory (mentors, studios, classes). Anyone can use this without authentication, but as an authenticated scope it returns slightly enriched data (e.g. distance from your saved home location).
Write scopes
write:profile
Update your user profile (name, settings).
write:mentor / write:studio
Update your mentor or studio profile.
write:classes
Create, update, delete your classes. Modify schedules, capacity, pricing.
Pro+ feature; free tier accounts that grant this scope still cannot make changes (the tool returns "upgrade required").
write:bookings
Create new bookings (booking on behalf of a student), cancel bookings, mark paid.
Note: bookings have constraints. You cannot create a booking on a sold-out class via the API any more than you can via the UI.
write:clients
Update client notes and tags.
write:financials
Create, update, delete expenses. Modify earnings categorisation. Pro+ feature.
write:reviews
Respond to reviews on your profile.
write:messages
Send messages (inquiries, replies, mentor outreach).
Special scopes
mcp:tools
Allow the client to call MCP tools. Required for MCP servers; without it the MCP endpoint refuses requests.
offline_access
Allow the client to refresh its access token without you re-authorising. Standard OAuth scope; if not granted, the client has to re-auth every time the token expires (~1 hour).
Most clients ask for this so the user does not have to re-auth constantly.
Common scope bundles
Most clients ask for a sensible bundle rather than every scope. Typical bundles:
- Read-only:
read:profile,read:bookings,read:classes,read:clients. Useful for "show me my schedule" use cases. - Personal assistant: read-only plus
write:bookings,write:classes,write:messages. The assistant can manage your operations. - Full control: everything except
write:financials. For power users.
You can deny specific scopes during the consent screen; the client adapts (some tools will be unavailable, but the rest work).
What I can do during consent
The OAuth consent screen shows:
- The client name (e.g. "Claude Desktop").
- The client's website (if provided).
- Every scope the client is requesting.
- A checkbox per scope (some are pre-checked as required).
You can:
- Approve all (the easy default).
- Deselect specific scopes and approve the subset.
- Deny entirely.
Revoking access
/settings/connected-apps shows every OAuth client connected to your account. For each one, you see:
- The client name.
- When it was authorised.
- What scopes it has.
- Last used timestamp.
- A "Revoke" button.
Click revoke and the token is invalidated. The client immediately loses access. If you re-authorise the same client later, you start fresh; no "remembered" scopes.
Audit logging
Every OAuth request is logged in your audit log at /settings/audit-log. Visible:
- Which client made the request.
- What tool was called.
- The arguments (with sensitive values redacted).
- The response status.
Useful when you want to know what an AI assistant has been doing on your behalf.
What scopes do not cover
A few things scopes specifically do NOT permit, regardless of grant:
- Reading other users' private data. Even with full scopes, a client can only access YOUR data and public data of others.
- Triggering payouts or modifying Stripe-side settings. Those are at Stripe, not at us.
- Modifying account settings that require email confirmation (changing your email, etc).
These are intentional. Some actions are too high-stakes for delegation.
Common questions
Can a client request a scope I have not granted? The client will get a 403 on any tool requiring an unsranted scope. They cannot escalate.
Can I see what an old client was doing if I have revoked it? Yes. The audit log preserves past requests even from clients that have been revoked.
Can multiple clients connect with overlapping scopes? Yes. Each connected client has its own token. You can have Claude with full access AND ChatGPT with read-only.
Is there a way to scope by class or by client (more granular than scopes)? Not currently. Scopes are the boundary; we do not support "read bookings for class X only" or similar fine-grained ACLs. We may add this if there is demand.
Why is there no delete:account scope?
Account deletion requires email confirmation. It cannot be done via OAuth, even with full scopes.
Next steps
- MCP server: the main consumer of OAuth.
- Connected apps: manage your authorisations.