Access control administration module — JetSetGo MCP reference

The tenantpermissions module administers who holds an account in a tenant and what those accounts are allowed to do: users, named user-groups, and role assignments (user-to-role and group-to-role). Role definitions themselves are provisioned by the platform and are strictly read-only here — the module assigns roles but never defines them. Because its changes alter real authorization rather than descriptive data, it is the most safety-guarded module in the JetSetGo MCP surface.

What the operator uses it for

Day-to-day administration of the tenant's people. An operator can approve new sign-ups that are waiting in the pending state, correct a user's name or email, create user-groups as scalable bundles of access, add members to groups, grant or revoke roles directly on a user, and grant or revoke roles on whole groups. Before and after such changes, the operator can ask for any user's effective permission set to verify what they can actually read and write.

The critical operational fact is blast radius. A role granted to a group is inherited by every current and future member at once, so one assignment can change access for dozens of people in a single confirmed action. The module makes this explicit rather than hiding it: previews for group-role writes quantify exactly who is affected before anything executes.

Where it sits

This module is authorization administration itself, not a consumer of it. Its grants flow outward into two consumers: app gating across the platform (which surfaces and actions each user sees in child apps) and backend request authorization (which API calls succeed). Every other MCP module's usefulness to a given person is downstream of what this module grants. Upstream, user accounts originate from sign-in identity; approval merely admits an existing account holder to the tenant.

Key concepts

User — a person with an account: name, email, an approved flag (pending until admitted), and optional group memberships and direct roles.
Approval — moves a pending user to approved. It grants tenant access only, never administrative rights.
Role — a named bundle of permissions. Roles are provisioned by platform configuration; this module lists them and assigns them.
User-group — a named bundle of roles. Every member inherits everything the group carries; this is the scalable path for granting access.
Direct vs inherited roles — a user holds direct assignments of their own plus every role inherited through their groups. Revoking membership removes inherited roles but never direct ones.
Effective permissions — the resolved result of all grants for one user, tagged by source (administrative override, group, or direct) with separate read and write flags. Read-only.
Guarded write — every mutation here runs preview-then-confirm: the tool returns a preview of exactly what will change, then requires explicit confirmation to execute.

Tools

Tool	Class	Purpose
`tenantpermissions_users_list`	Read	List users with group memberships and directly-assigned roles.
`tenantpermissions_groups_list`	Read	List user-groups with their members and assigned roles.
`tenantpermissions_roles_list`	Read	List the read-only role definitions available for assignment.
`tenantpermissions_user_permissions_get`	Read	Fetch one user's effective permissions with source attribution.
`tenantpermissions_user_update`	Guarded write	Edit a user's name and/or email only.
`tenantpermissions_user_approve`	Guarded write	Approve a pending user via the admin-checked endpoint.
`tenantpermissions_role_assign_user`	Guarded write	Grant a role directly to a user.
`tenantpermissions_role_remove_user`	Guarded write	Revoke a directly-assigned role from a user.
`tenantpermissions_role_assign_group`	Guarded write	Grant a role to a group; preview states member impact.
`tenantpermissions_role_remove_group`	Guarded write	Revoke a group role; preview states member impact.
`tenantpermissions_group_member_add`	Guarded write	Add a user to a group; preview lists inherited roles.
`tenantpermissions_group_member_remove`	Guarded write	Remove a user from a group; preview lists lost roles.
`tenantpermissions_group_create`	Guarded write	Create an empty user-group.
`tenantpermissions_group_update`	Guarded write	Rename a group and/or change its description.

Rules worth knowing

Administrative and approval flags are excluded at the schema level: no tool accepts fields that could mint an administrator, toggle elevated status, or un-approve a user. Those changes happen in the operator app, not through AI.
Every user-targeting write refuses to act on the calling operator's own account. Self-approval and self-modification fail at preview even when the backend would allow them.
Group-role previews state the affected member count and name up to five members; membership-change previews list precisely which roles a user gains or loses.
Membership writes fingerprint the affected user's or group's current assignment set. A concurrent edit between preview and confirm trips a re-preview error instead of applying stale intent.
Previews and change records carry names only — never email addresses.
Approval requires the user to have signed in at least once; an account with no linked identity cannot be approved yet.
Several destructive operations are deliberately not exposed as tools: inviting or deleting users, rejecting sign-ups, deleting groups (which cascades), and creating/editing/deleting roles. For these, the assistant directs the operator to the corresponding app surface instead of performing the action.
On tenants where cross-entity relationships are not tracked, list reads degrade gracefully to ids-only output rather than failing.

Settings — tenant-level business configuration adjacent to account administration.
Knowledge — operator-curated content whose curation rights ultimately depend on the grants administered here.