User Management in MCP Manager

Overview

MCP Manager's user management system controls who can access your organization's AI integrations and what they're allowed to do. It's built around three core concepts: Users, Teams, and Roles. Together, these determine which gateways — and by extension, which MCP servers and tools — each person in your organization can reach, as well as what administrative actions they can perform inside MCP Manager itself.

All user management is handled from the People section in the left navigation panel.

Users

What is a User?

A user in MCP Manager represents a person in your organization who needs access to your AI integrations. When you add someone as a user, MCP Manager can authorize their access to gateways — and through those gateways, the MCP servers and tools behind them.

Users don't interact with MCP servers directly. Instead, they connect through gateways using an AI client (like Claude or Cursor), and MCP Manager verifies that they have the right team membership and permissions before allowing the connection.

Inviting Users

Users are added to MCP Manager through an email invitation. To invite someone:

Navigate to the People section and click Invite Users.
Enter the email addresses of the people you want to invite. You can invite multiple users at once by entering comma-separated email addresses — useful when onboarding an entire team at once.
Assign the user to at least one team. This determines which gateways they'll be able to access.
Assign the user a role. This determines what actions they can take inside MCP Manager.

Both a team and a role are required when inviting a new user. Once you send the invitation, the user receives an email with a link to set up their account and join your organization's workspace.

Disabling Users

If someone leaves your organization or should no longer have access to your AI integrations, you can disable their user account. Disabling a user immediately prevents them from accessing MCP Manager and any gateways they were previously connected to. Their account isn't deleted — it can be reactivated later if needed.

This is a safer alternative to deleting a user outright, since it preserves their activity history and logs for audit purposes while revoking all access.

Teams

What is a Team?

Teams are the core building block of MCP Manager's access control system. They form the link between users and gateways — a user can only access a gateway if they belong to a team that gateway is assigned to.

Think of teams as access groups. You might create a team for "Engineering," another for "Marketing," and another for "Data Science." Each team gets access to the gateways (and therefore the tools and servers) that are relevant to their work.

How Teams Work

Users can belong to one or more teams. A developer who works across multiple projects might be a member of both the "Frontend Engineering" team and the "Platform" team, giving them access to gateways assigned to either group.
Gateways are assigned to teams. Only members of a given team can see, access, and use the gateways assigned to that team. If you're not on the team, the gateway won't appear as an option when you try to connect.
Some users can access all gateways. Users with a role that includes a capability granting access to all gateways can bypass team-based restrictions. This is typically reserved for administrators who need visibility across the entire organization.

Managing Team–Gateway Assignments

You can assign gateways to teams from two places in MCP Manager:

From the Gateway page — Open a specific gateway, navigate to its settings, and assign it to one or more teams.
From the Teams table — Open a specific team in the People section and manage which gateways are assigned to it.

Both approaches produce the same result — use whichever is more convenient for your workflow.

Why Teams Matter

Teams give you the flexibility to distribute access to tools from the same MCP servers to different groups of users in your company. For example, you might have a single Atlassian/Jira MCP server, but expose it through two different gateways with different tool sets and policies — one for engineering and one for project management. By assigning each gateway to the appropriate team, each group only sees the tools relevant to them. This becomes critical when trying to distribute access appropriately to servers that have sensitive data and tools that have write, delete, or other destructive functionality. You might want to create a team (e.g. "High-risk DB access") that has the ability to call those high risk tools via a gateway (e.g. "High risk DB Gateway"), and disable those tools in the broader gateway that is accessible by a larger group of users.

Roles

What is a Role?

A role describes the actions a user can take inside MCP Manager. While teams control which gateways a user can access, roles control what they can do within the product itself — from routine tasks like viewing logs to administrative actions like adding servers, creating gateways, managing policies, or inviting new users.

How Roles Work

Every user must have exactly one role. When you invite a new user, you assign them a role as part of the invitation. This role stays with them until an administrator explicitly changes it.
Users can be migrated between roles. If someone's responsibilities change — for example, a team member becomes a team lead who needs to manage gateway configurations — an administrator can reassign them to a different role without removing and re-inviting them.

Role Capabilities

Each role is defined by a set of capabilities (also called grants) that determine what actions are permitted. These capabilities span the full range of MCP Manager functionality, including:

Adding and configuring MCP servers
Creating and managing gateways
Assigning servers to gateways
Managing tool provisioning and policies
Inviting and managing users
Creating and editing teams
Creating new custom roles
Viewing logs and reports
Deleting gateways or servers

Administrators can create custom roles tailored to their organization's needs. For example, you might create a "Gateway Manager" role that allows a user to manage gateway configurations and tool provisioning but doesn't permit them to invite users or modify security policies. This lets you follow the principle of least privilege — giving each person only the access they need to do their job.