Access Control

How access control works in MCP Manager: roles grant capabilities (what you can do), teams grant gateways (which you can reach), and a user’s access is the intersection of the two — why each user has exactly one role but can belong to many teams, plus the per-server identity and feature-provisioning layers that scope it further.

In MCP Manager, access control decides two things for every person in your workspace: what they are allowed to do, and which gateways they can reach. Those two questions are answered by two independent building blocks — roles and teams — and a user’s effective access is the intersection of the two. Two finer, per-server layers narrow it further. This section is the reference for all of them.

Access control is administered under People at People, and almost all of it — creating roles, editing capabilities, and managing teams — is gated by the Manage people capability. If the People link is missing from your left-hand navigation, your role doesn’t have that capability. Access is governed by capabilities, not by any fixed role name.

Roles and teams are the two halves of access

MCP Manager keeps what you can do and which gateways you can reach as two separate concepts and combines them with an AND:

• A role is a named bundle of capabilities — granular permissions such as “Basic gateway management” or “View and export logs.” Every user holds exactly one role — which keeps the answer to “what actions is this person allowed to take?” unambiguous, with no overlapping roles to reconcile.
• A team grants access to specific gateways. A user can belong to zero, one, or many teams, and it answers “which gateways can this person reach?”

A user can act on a gateway only when both halves agree: their role grants the capability for the action, and one of their teams provisions the gateway. Holding a capability does not widen which gateways it applies to, and joining a team does not, by itself, grant any administrative action. A small family of “view all” capabilities — View and use all gateways, View all servers, View all identities, and See all alerts — deliberately overrides team scoping for administrators who need a workspace-wide view.

The finer, per-server layers

Roles and teams set the broad boundaries; two further controls scope access within a gateway, one server at a time:

• Identity scheme — whether each server is reached with the user’s own identity or a shared service account. See Identity Controls.
• Feature provisioning — which tools, resources, and prompts each server exposes on a gateway. See Feature Provisioning.

There is no per-person or per-resource access list, so you express fine-grained access by separating servers onto different gateways and provisioning each gateway to the right team. See Gateway Deployment Strategies.

The pieces of access control

Roles

The capabilities a user holds — what they’re allowed to do. Every user has exactly one role.

Teams

The gateways a user can reach. A user can belong to zero, one, or many teams.

Capabilities

The complete reference of every permission a role can grant, grouped as they appear in the product.

Further reading

Roles

Start here — the three built-in roles, custom roles, and how a role is assigned.

Identity Controls

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

Feature Provisioning

Per-server tool, resource, and prompt exposure — the finest layer of access.

Gateway Deployment Strategies

How to package gateways so each team gets exactly the access it should.