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 — 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 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 people capability. If you can’t open role management under 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.

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 — the kinds of actions a user may perform (create gateways, delete servers, export logs, manage people, and so on).
• A team grants access to specific gateways — the which. See 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 a user holds, workspace-wide.
• Team membership — which gateways the user can reach. See 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.
• Per-server feature provisioning — which tools, resources, and prompts each server exposes on a gateway. See 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 and the 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, 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, is assigned the Member role unless a different role is chosen for them. See 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.

How a role is assigned

A user receives their role in one of two ways.

At invite time

When you invite users from 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, 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 and SCIM.

Editing a role

With the Manage people capability you can edit roles from 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

All role administration — creating, duplicating, renaming, re-iconing, editing capabilities, deleting unused roles, and changing which role a user holds — is governed by the single Manage people capability. The same capability also governs team administration and lets the holder see all teams in the workspace.

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 people. For the complete list of what every capability unlocks, see the Capabilities reference.

Further reading

Teams

The other half of access — which gateways a user can reach.

Capabilities

The complete reference of every capability a role can grant.

Identity Controls

Per-server identity schemes that further scope what a user reaches.

Feature Provisioning

Per-server tool exposure, the finest layer of access control.