Teams

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.

In MCP Manager, a team is how access to gateways is distributed to users. Adding a user to a team grants them the gateways that team is provisioned, and a gateway reaches its users by being provisioned to one or more teams. Teams answer the question “which gateways can this person reach?”; roles answer the separate question “what is this person allowed to do?”. Together they form MCP Manager’s access model.

​

Teams and roles are the two halves of access

A user’s effective access is the intersection of their role and their teams:

• A team grants access to specific gateways — the which.
• A role grants capabilities — the what, the kinds of action a user may take.

A user can only act on a gateway that one of their teams provisions (unless their role holds the View and use all gateways capability, which overrides team scoping — see below). And being on a team that provisions a gateway does not, by itself, grant administrative actions on it — those come from the user’s role capabilities. See Roles.

​

Team membership: zero, one, or many

A user can belong to zero, one, or many teams at the same time — there is no minimum. A user with no team memberships simply has no gateway access through teams (and reaches gateways only if their role holds View and use all gateways). This is deliberately different from roles, where every user holds exactly one role.

​

Provisioning a gateway to a team

A gateway becomes available to users by being provisioned to teams. You can do this at two points. Managing which teams a gateway is provisioned to is governed by the Manage team-gateway provisioning capability.

​

Access resolves as the union of your teams

A user’s gateway access is the union across all the teams they belong to: if any of their teams provisions a gateway, they can reach it. The same gateway can be provisioned to several teams at once with no conflict — a user who reaches a gateway through more than one team simply has access, and losing it from one team does not remove it as long as another team still grants it.

​

Disabling a team

A team can be disabled rather than deleted. Disabling a team renders the gateway access it provides inactive: the access is enforced at the MCP proxy at connection time, so a user who reaches a gateway only through a disabled team can no longer communicate with that gateway through MCP Manager. When such a user next connects, MCP Manager surfaces a message telling them the team has been disabled. Because access is the union of a user’s teams, disabling a team only cuts off the access that team was the sole provider of. If a user reaches the same gateway through another team that is still active, they keep that access — only the access that depended on the disabled team goes inactive. Re-enabling the team restores the access it provided. Disabling and enabling teams is governed by the Manage people capability.

​

Deleting a team

Any team can be deleted, with one guardrail: a workspace must always have at least one team, so you cannot delete the last remaining team. Deleting a team is permanent and removes the gateway access it provided; reassign or re-provision affected gateways to other teams first if users still need them. Deleting teams is governed by the Manage people capability.

​

The View and use all gateways override

The View and use all gateways capability overrides team-based scoping entirely. A user whose role holds it can see and use every gateway in the workspace regardless of team membership — both in the dashboard listing and at the MCP proxy when connecting. This is the capability that lets administrators work across all gateways without being added to every team. For everyone else, team membership remains the boundary on which gateways they can reach. See the Capabilities reference.

​

Creating teams

You can create as many teams as you want — team creation is never limited by your plan. (Custom roles, by contrast, are plan-gated.) Create teams to model how gateway access should be grouped in your organization — by department, by project, by environment, or however your governance requires.

​

Who can manage teams

All team administration — creating teams, editing team names, enabling and disabling teams, deleting teams, and adding or removing users — is governed by the single Manage people capability, which also lets the holder see every team in the workspace. The same capability governs role administration. Because access is governed by capabilities rather than by role name, whether a given person can manage teams depends on the capabilities granted to their role — which is fully configurable, including on any custom role you create. For the full list of what every capability unlocks, see the Capabilities reference.

​

Further reading