> ## Documentation Index > Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt > Use this file to discover all available pages before exploring further. # Roles > How roles and capabilities govern what users can do in MCP Manager: the three built-in roles, creating and duplicating custom roles, how a role is assigned at invite and through SSO, and how roles combine with teams to control access. In MCP Manager, a **role** decides *what a user can do*. A role is a named bundle of [capabilities](/deployment/rbac-and-roles/capabilities) — granular permissions such as "Basic gateway management" or "View and export logs" — and every user is assigned exactly one role. Roles answer the question "what actions is this person allowed to take?"; [teams](/deployment/teams) answer the separate question "which gateways can this person reach?". Together they form MCP Manager's access model. Creating and editing roles requires the **Manage roles** capability. If you can't open role management under [People](https://app.mcpmanager.ai/settings/people) — or the **People** link is missing from your left-hand navigation entirely — your role doesn't have that capability. Access is governed by capabilities, not by any fixed role name. See [Who can manage roles](#who-can-manage-roles). ## Roles and teams are the two halves of access MCP Manager separates access into two independent concepts, and a user's effective access is the **intersection** of the two: * A **role** grants [capabilities](/deployment/rbac-and-roles/capabilities) — the *kinds* of actions a user may perform (create gateways, delete servers, export logs, manage roles, and so on). * A **team** grants access to specific gateways — the *which*. See [Teams](/deployment/teams). For example, the **Basic gateway management** capability lets a user create gateways and edit gateway names, but only on the gateways they can actually reach through their team membership. Holding the capability does not, on its own, let a user manage a gateway that none of their teams provision — unless their role also has the **View and use all gateways** capability, which overrides team scoping. Capabilities define what you can do; teams define what you can do it to. ## How fine-grained can access get? MCP Manager has **no per-person or per-resource access list**. You cannot grant one named user access to one specific server (and nothing else) through an individual permission attached to that server. Capabilities are **workspace-wide**: a capability such as **View and export logs** applies across the whole workspace, not to a single server or gateway. Fine-grained access is instead built from four coarser controls that combine: * **Role** — the [capabilities](/deployment/rbac-and-roles/capabilities) a user holds, workspace-wide. * **Team membership** — which gateways the user can reach. See [Teams](/deployment/teams). * **Per-server identity scheme** — whether each server on a gateway is used with the user's own identity or a shared service account. See [Identity Controls](/features/identity-controls). * **Per-server feature provisioning** — which tools, resources, and prompts each server exposes on a gateway. See [Feature Provisioning](/features/feature-provisioning). To give different groups of people different access to different servers, you separate those servers onto different **gateways** and provision each gateway to the appropriate team. The gateway is the smallest unit at which you apply a distinct rule set, tool set, or identity scheme — so a different governance posture means a different gateway, not a per-server permission. See [Gateway Deployment Strategies](/deployment/gateway-deployment-strategies) and the [FAQ](/advanced/faq). ## Every user has exactly one role Each user in a workspace is assigned **exactly one role** — never more than one, and never none. To change what a user can do, you change their role assignment (or edit the capabilities of the role they hold). This is deliberately different from [team membership](/deployment/teams), where a user can belong to **zero, one, or many** teams at the same time. ## The three built-in roles Every MCP Manager workspace ships with three built-in (system) roles. They exist in every workspace, cannot be deleted, and serve as the starting points most teams build on. | Built-in role | Purpose | Capabilities | | ----------------- | -------------------------------------------- | ----------------------------------------------------------- | | **Super admin** | Unrestricted administration of the workspace | Holds **every** capability; the set cannot be reduced | | **Administrator** | Day-to-day administration | A broad, pre-selected set of capabilities that you can edit | | **Member** | The default role for everyday users | A minimal set of capabilities that you can edit | ### Super admin The **Super admin** role holds every capability MCP Manager offers, and that set **cannot be reduced** — its capabilities are locked on and the capability toggles are disabled when editing it. Super admin is **not** limited to a single person: you can assign it to as many users as you need. Because it grants unrestricted control of the workspace, assign it only to the people who genuinely need full administrative power. ### Administrator The **Administrator** role comes pre-selected with a broad set of capabilities suitable for day-to-day administration. Unlike Super admin, its capabilities are fully editable. We strongly recommend each workspace **review the Administrator role's capabilities carefully** so you know exactly what it grants in your environment before assigning it — and tailor it to your governance needs. ### Member The **Member** role is the workspace **default role**: it is the role new users receive automatically. It starts with a minimal set of capabilities and, like Administrator, is fully editable. Anyone invited to the workspace, and anyone provisioned through [SSO](/enterprise/sso), is assigned the Member role unless a different role is chosen for them. See [How a role is assigned](#how-a-role-is-assigned). The built-in roles are named starting points, but what a role actually permits is determined by the **capabilities** currently granted to it — and Administrator and Member are editable. When you need to know precisely what someone can do, look at their role's capabilities, not its name. See the full [Capabilities reference](/deployment/rbac-and-roles/capabilities). ## How a role is assigned A user receives their role in one of two ways. ### At invite time When you invite users from [People](https://app.mcpmanager.ai/settings/people) (**Add new users**), you select a single role that every user in that invitation will receive, along with any teams to add them to. Inviting users requires the **Invite users** capability, and you can only invite people to the role and teams you yourself have access to. ### Automatically through SSO In a workspace that uses [SSO](/enterprise/sso), anyone who signs in through the identity provider associated with your domain and gains access to the workspace is automatically assigned the workspace **default role** — the **Member** role. SSO and SCIM map your identity-provider groups to MCP Manager **teams, not to roles**. They determine which teams a provisioned user joins, but every provisioned user still receives the default role; there is no mapping from an IdP group or attribute to a role today. Roles are assigned and changed manually in MCP Manager. (If you would like roles to be driven from your IdP, it is not available today, but we are open to it — talk to your MCP Manager contact.) Mapping groups to teams, and choosing the default team for provisioned users, is controlled by the **Manage SSO/SCIM mapping** capability. See [SSO](/enterprise/sso) and [SCIM](/enterprise/scim#scim-syncs-teams-not-roles). ## Editing a role With the **Manage roles** capability you can edit roles from [People](https://app.mcpmanager.ai/settings/people): * **Rename a role** and **change its icon** — including for the built-in roles — so it's easy to recognize in your workspace. * **Manage its capabilities** — grant or revoke individual capabilities — for any role **except Super admin**, whose capabilities are locked on. System (built-in) roles **cannot be deleted**. A custom role can be deleted, but only once it has **no users assigned to it** — reassign its members to another role first. ## Custom roles Beyond the three built-in roles, you can create your own roles to match how your organization governs access. * **Create a custom role** and grant it exactly the capabilities you want. * **Duplicate an existing role** — including a built-in one — to start from its capability set and then add or remove capabilities. Duplicating is the fastest way to make a small variation on a role that already works. * **The number of custom roles you can create depends on your plan.** Creating teams is unlimited, but custom roles are a plan-gated resource — if you need more, upgrading your plan raises the limit. ## Who can manage roles Role administration is split across two capabilities. **Manage roles** governs the roles themselves — creating, duplicating, renaming, re-iconing, editing capabilities, and deleting unused roles. **Manage user role assignments** is the separate capability for changing which role a given user holds. Team administration is governed by its own People capabilities (**Manage teams**, **Manage user team assignments**, **View all teams**) — see [Teams](/deployment/teams) and the full [Capabilities reference](/deployment/rbac-and-roles/capabilities#people). Because access is governed by capabilities rather than by role name, whether a given person can manage roles depends on the capabilities granted to their role — which is fully configurable, including on any custom role you create. If the **People** section or its role controls are missing for someone, their role does not have **Manage roles** (nor any other People capability). For the complete list of what every capability unlocks, see the [Capabilities reference](/deployment/rbac-and-roles/capabilities). ## Further reading The other half of access — which gateways a user can reach. The complete reference of every capability a role can grant. Per-server identity schemes that further scope what a user reaches. Per-server tool exposure, the finest layer of access control.