Organisations
Roles, org-owned resources, and when to reach for SSO or SCIM.
Roles
An organisation has exactly three roles:
- Member - read access: org details, member list, listings, bundles, domains, org vault entries, LLM bindings.
- Admin - everything a member can do, plus inviting and removing members (at or below their own role), updating org name/description, managing domain claims, managing SCIM status/sync, and creating, editing, or deleting org vault entries and org LLM bindings.
- Owner - everything an admin can do, plus deleting the org, changing member roles or transferring ownership, configuring or removing SSO, updating the provisioning policy, and managing SCIM tokens and the role-mapping table.
Org-owned resources
Both bundles and MCP listings can belong to an organisation instead of an
individual user. An org-owned listing (visibility: "org") requires org
membership to see and skips the public review queue entirely - it
publishes immediately rather than going through
the draft-to-published workflow
that public listings go through.
SSO
Single sign-on lets an organisation's members authenticate through the org's own identity provider instead of local credentials, once the org has verified ownership of its email domain. It can be made mandatory org-wide, which is only allowed once an active SSO configuration exists - so members can't be locked out mid-setup.
SCIM
SCIM lets an external identity provider (Okta, Entra ID, etc.) push user provisioning and group-to-role mapping into the organisation automatically, instead of admins inviting and managing members by hand. Useful once membership is large enough, or changes often enough, that manual invites become the bottleneck.
Where to go next
Full endpoint list: Organisations and SCIM in the API reference.