Skip to main content
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, gated by a set of fine-grained People capabilities — Manage roles, Manage teams, Manage user role assignments, Manage user team assignments, Remove users, and View all teams. Holding any one of them reveals the People section; each then unlocks its own actions. If the People link is missing from your left-hand navigation, your role has none of them. 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, View all teams, 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.

​
Who can read another person’s access

Reading someone else’s access is itself permissioned. The Gateways tab on a user’s detail page reports every gateway that person can reach, and names the teams granting each one — so opening it for another user requires both View all teams and View and use all gateways. Without both, the tab appears on your own profile only. It answers the same question there — which gateways you can reach, and through which teams — for the one person you are always entitled to ask about. This governs who may read the answer. It never changes what the subject can do.

​
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.