Members & groups

The members table

Admin → Members. Search matches email, name — or a group name, which lists that group’s members. Columns:

Column	What you control
Role	member / admin (the last admin cannot demote themselves).
Status	active, invited · Nd left, expired for invites.
Groups	the person’s groups as chips — click to edit in a popover, changes apply instantly.
Own MCP	whether this person may register personal MCP servers (admins and ‘everyone’-policy orgs are always allowed).
Token caps	daily / weekly token ceilings; empty = unlimited. Stricter of user/org caps wins.

Invites, step by step

1. Invite people → email + role → Send invite (link lands in your clipboard). Works for emails outside your domain — contractors join your org with the role you picked.
2. The invite shows in the table as a pending row. Links expire after 7 days — copy link to re-send, revoke to kill early; expired rows are marked and removable.
3. When the person opens the link and signs in, the row becomes a normal member with the pre-assigned role.

Per-person access (click any member row)

The row expands into three columns — the person’s complete effective access:

• Connectors (catalog) — every enabled service with its source: whole org or via . Catalog access is group-governed; manage it on the connector row or under Groups.
• Custom MCP servers — group-derived access plus a direct checkbox: tick to grant this one person a vaulted server on the spot.
• Skills — org/group shares plus a direct share checkbox.

Every item is badged with where the right comes from, so “why can Kwame reach NetSuite?” is answered in one glance.

Groups

Admin → Groups. A group is the unit of access: people on one side, three kinds of rights on the other. A person in several groups gets the union.

Create and staff a group

1. Name → Create group.
2. Members column: search (Find a person…, current members first), tick people. Changes are drafts until Save.
3. Or from Members: click a person’s Groups chips and tick there (instant).

What a group grants

• Company services (personal auth) — tick the catalog services this group should see. Members still connect with their own account (OAuth or personal token). A service with no group ticked anywhere is visible to the whole org; the moment one group is ticked on it, it becomes group-scoped.
• Custom MCP servers (vault) — tick the org-registered servers whose shared credential this group may use.
• Skills — skills shared to this group appear in every member’s set.

Groups from your IdP

With SSO group sync enabled, groups arriving in the Okta groups claim are created automatically (badged from IdP) and their membership follows the IdP on every login. Manually created groups are never touched by sync — hand-granted access survives. IdP-group membership is edited in Okta, so the checkboxes for those groups are locked here.

Practical patterns

• Least privilege for sensitive tools: put a commercial/personal-class connector behind a small group instead of the whole org.
• One-click wikis: enable a shared org token on the wiki connector, scope it to the org — everyone connects instantly.
• Contractor sandboxing: invite the contractor, put them in a dedicated group, tick only what they need, cap their tokens in the same table.