> ## 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.
# Capabilities
> The complete reference of MCP Manager capabilities — every permission you can grant to a role, grouped by area (Identities, Servers, Gateways, Hosts, People, Workspace settings, Logging, Alerting, Reporting, Integrations) — and exactly what each one allows.
A **capability** in MCP Manager is a single, granular permission — the smallest unit of "what a user is allowed to do." Capabilities are never assigned to users directly; instead they are bundled into [roles](/deployment/rbac-and-roles/overview), and each user holds exactly one role. This page is the complete reference of every capability, grouped exactly as they appear in the product.
Granting and revoking capabilities — and editing a role at all — is itself governed by the **Manage roles** capability. You edit a role's capabilities under the **Capabilities** tab when managing a role in [People](https://app.mcpmanager.ai/settings/people). If you can't reach role management, your role doesn't have **Manage roles** — access is governed by capabilities, not by any fixed role name.
## How capabilities work
Capabilities are granted **per role**. Under [People](https://app.mcpmanager.ai/settings/people), open a role and use its **Capabilities** tab to toggle each permission on or off; every user assigned that role inherits the result. The built-in **Super admin** role always holds every capability and its toggles are locked on; the **Administrator** and **Member** roles, and any custom role, have fully editable capabilities. See [Roles](/deployment/rbac-and-roles/overview) for how roles are assigned and edited.
**Capabilities define *what* you can do; [teams](/deployment/teams) define *which* gateways you can do it to.** Most capabilities act only on the resources your team membership already grants you. A separate family of "view all" capabilities — **View and use all gateways**, **View all servers**, **View all identities**, **View all teams**, **See all alerts** — overrides that team scoping for its resource type. See [How team scoping interacts with capabilities](#how-team-scoping-interacts-with-capabilities).
## Identities
Identity capabilities govern the credentials users connect to downstream MCP servers. Personal identity management — managing your *own* identities — is always available to every user and is not gated by a capability.
| Capability | What it allows |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Identity management** | This includes updating identity availability, disabling and enabling identities, and deleting identities created by others. Personal identity management is always enabled. |
| **View all identities** | Access all identities in this workspace regardless of who created them. |
### View all identities is a governance-preview capability, not an impersonation grant
**View all identities** lets an administrator see every identity in the workspace, including the private identities created by other users, regardless of who created them. Critically, it does **not** let the holder *use* another person's private identity, nor view or edit its **header tokens** (its secret credentials). A private identity is never selectable for assignment by anyone other than its owner, even with this capability, and its header tokens can only be viewed or edited by its creator — an identity can only be used by others if its owner has made it **shared** (globally available) rather than personal.
What the capability provides is a **read-only preview**: an administrator can see which identities exist and preview what tools and access a given user's identity would expose. This is an instrumental tool for building governance policies — understanding what different users and their identities can reach — without granting the ability to act as those users. For the concepts behind identities and shared-versus-personal availability, see [Authentication & Identity](/security/authentication-and-identity).
## Servers
Server capabilities govern MCP servers and server instances — adding them, editing them, enabling or disabling them, deleting them, and creating managed and workstation server instances.
| Capability | What it allows |
| -------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Basic server management** | This includes adding remote servers, editing remote server names, and creating remote server identities via authentication. |
| **Disable and enable servers** | Disable and enable servers in this workspace. |
| **Delete servers** | Delete servers from this workspace. |
| **Manage feature provisioning settings** | Manage the provisioning settings for features on servers in this workspace. |
| **View all servers** | View all servers and server instances in this workspace regardless of access. |
| **Create managed server instances** | This includes deploying new server instances, and editing server instance names. |
| **Create and configure managed and workstation servers** | This includes creating new managed and workstation servers, editing their names, editing default template configurations, updating server instance permissions, and setting and updating tunnel schemes. |
| **Create workstation instances** | This includes deploying new workstation instances, and editing workstation instance names. This includes deploying new workstation instances, and editing workstation instance names. |
Like gateways, servers are scoped by access: **View all servers** overrides that scoping so the holder sees every server and server instance in the workspace regardless of access. **Create workstation instances** is reserved for an upcoming feature and is not yet active.
## Gateways
Gateway capabilities govern creating and configuring [gateways](/mcp-gateway-concepts/mcp-gateways), provisioning them to teams, and archiving them.
| Capability | What it allows |
| -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Basic gateway management** | This includes creating gateways, editing gateway names, disabling and enabling gateways, assigning servers to gateways, changing identity scheme ("shared" or "personal"), disabling and enabling assigned servers, and revoking assigned servers from gateways. |
| **View and use all gateways** | View and use all gateways on any team in this workspace. |
| **Manage team-gateway provisioning** | This includes creating and revoking team gateway provisions. |
| **Archive and view archived gateways** | Archive gateways to hide them from default views without deleting. This also controls the ability to unarchive them. Archived gateways are automatically disabled. |
### Basic gateway management acts only on gateways you can reach
**Basic gateway management** grants the *actions* — creating gateways, renaming them, enabling and disabling them, assigning and revoking servers. It does not, by itself, widen *which* gateways those actions apply to. A user with this capability can manage only the gateways their [team membership](/deployment/teams) provisions to them. To act on gateways across the whole workspace regardless of team, a role also needs **View and use all gateways** (below). **Manage team-gateway provisioning** is the separate capability for granting and revoking a team's access to a gateway.
## Hosts
Host capabilities govern the apps and agents that connect to your gateways — the API tokens and OAuth connections that link a host to a gateway, and enabling, disabling, or deleting hosts.
| Capability | What it allows |
| ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Create and manage API tokens (including copy & download)** | This includes generating/copying/downloading API access tokens, editing token-based host names, disabling and enabling hosts, and deleting hosts. |
| **Authenticate via OAuth** | Establish connections between hosts and gateways via OAuth. |
| **Disable and enable connections** | Disable and enable connections between hosts and gateways. |
| **Disable and enable hosts** | Disable and enable hosts in this workspace. |
| **Delete hosts** | Delete hosts from this workspace. |
## People
People capabilities govern user, role, and team administration and SSO/SCIM mapping.
| Capability | What it allows |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Invite users** | This includes inviting users to the role and any team that the inviter has access to. |
| **Manage roles** | Create and duplicate roles, edit role names and icons, edit role capabilities, and delete roles that have no assigned users. |
| **Manage teams** | Create teams, edit team names, enable and disable teams, and delete teams. |
| **Manage user role assignments** | Update and modify which role a user holds. |
| **Manage user team assignments** | Create and revoke users' team memberships. |
| **Remove users** | Deactivate users to remove their access to the workspace. |
| **View all teams** | See every team in the workspace, regardless of which teams you belong to. |
| **Manage SSO/SCIM mapping** | Configure how IDP groups (e.g. Okta) map to MCP Manager teams and edit workspace-level SSO settings, including the default team for SCIM-provisioned users. |
### People administration is split into fine-grained capabilities
User, role, and team administration is divided into **six independent capabilities**, so you can grant exactly the administrative scope a role needs rather than all of it at once:
* **Manage roles** — create and duplicate roles, edit role names, icons, and capabilities, and delete roles that have no assigned users.
* **Manage teams** — create teams, edit team names, enable and disable teams, and delete teams.
* **Manage user role assignments** — change which role a user holds.
* **Manage user team assignments** — add users to and remove them from teams.
* **Remove users** — deactivate a user to revoke their access to the workspace.
* **View all teams** — see every team in the workspace, not only the teams you belong to (the team-scoping override for People; see [How team scoping interacts with capabilities](#how-team-scoping-interacts-with-capabilities)).
Holding **any one** of these makes the **People** section visible; each capability then unlocks only its own actions. Grant them individually — for example, a help-desk role might get **Manage user team assignments** and **Remove users** without the ability to edit roles or their capabilities.
These six capabilities replace the earlier single **Manage people** capability, which bundled all of the above together. If you previously relied on **Manage people**, grant the specific capabilities a role now needs. The built-in **Super admin** role holds all of them automatically.
### Manage SSO/SCIM mapping also gates a page
**Manage SSO/SCIM mapping** controls more than buttons: the SSO/SCIM settings page itself is gated by this capability. A user whose role lacks it cannot open that page even by direct link — they are redirected away. See [SSO](/enterprise/sso) and [SCIM](/enterprise/scim).
## Workspace settings
| Capability | What it allows |
| ----------------------------- | ----------------------------------------------------------------------------------------------------- |
| **Manage workspace settings** | Manage basic workspace settings like workspace name and date/time formats throughout the application. |
| **Manage plans** | Manage billing plans and subscriptions for the workspace. |
## Logging
Logging capabilities govern viewing and exporting [logs](/features/viewing-logs) and configuring the OpenTelemetry collector that forwards them.
| Capability | What it allows |
| ---------------------------------- | ------------------------------------------------------------------------------ |
| **View and export logs** | View and export logs for hosts, gateways, and servers that you have access to. |
| **Manage OpenTelemetry collector** | Configure, edit, and remove the OpenTelemetry collector used to forward logs. |
**View and export logs** is scoped to the resources you can already reach: it lets you view and export logs only for the hosts, gateways, and servers your team membership grants you access to — it is not a workspace-wide "view every log" grant. **Manage OpenTelemetry collector** governs the collector used to forward logs to an external destination; see [Export to SIEM](/enterprise/export-to-siem).
## Alerting
| Capability | What it allows |
| ------------------ | ---------------------------------- |
| **See all alerts** | View all alerts in your workspace. |
**See all alerts** overrides the default team-based scoping of [alerts](/features/alerts) so the holder sees every alert in the workspace rather than only those tied to resources they can reach.
## Reporting
| Capability | What it allows |
| ---------------- | ---------------------------------------------------- |
| **View reports** | View reports for hosts, gateways, servers, and more… |
**View reports** controls the [Reporting](/features/reporting) page end to end: with it, the **Reporting** link appears in the left-hand navigation and every chart is available; without it, the link is hidden and the page is unavailable.
## Integrations
| Capability | What it allows |
| ----------------------- | --------------------------------------------------------------------------------------------------------------- |
| **Manage integrations** | Configure, edit, and remove integrations such as rule engines, including custom providers and built-in engines. |
**Manage integrations** governs the [rule engines](/features/gateway-rules/custom-rules-engines) and other integrations attached to your gateways — configuring them, editing them, and removing them, for both built-in engines and custom providers.
## How team scoping interacts with capabilities
Most capabilities are bounded by [team membership](/deployment/teams): they let you act only on the gateways (and the servers, hosts, logs, and alerts behind them) that your teams provision to you. A handful of capabilities are deliberately designed to **override** that scoping for administrators who need a workspace-wide view:
* **View and use all gateways** — see and use every gateway on any team, bypassing team provisioning entirely.
* **View all servers** — see every server and server instance regardless of access.
* **View all identities** — see every identity regardless of creator (read-only preview; it does not let you *use* another user's private identity, or view or edit its header tokens).
* **View all teams** — see every team in the workspace, not only the teams you belong to.
* **See all alerts** — see every alert in the workspace.
If you grant one of these "view all" capabilities, remember that you are removing the team boundary for that resource type. For most users, leave them off and rely on team membership to scope access; reserve them for administrative roles. For how team access itself is granted, disabled, and resolved, see [Teams](/deployment/teams).
## Further reading
How capabilities are bundled into roles and assigned to users.
The team scoping that bounds most capabilities.