Skip to main content

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.

SCIM provisioning lets your identity provider (IdP) — Okta, Microsoft Entra ID, or another SCIM 2.0-capable IdP (see Supported identity providers) — automatically create, update, and deactivate users in MCP Manager, and keep IdP group membership in sync with MCP Manager teams. With SCIM configured, your directory is the source of truth: when someone joins, changes teams, or leaves in your IdP, MCP Manager reflects it without anyone editing users by hand.
SCIM provisioning is enabled as part of guided onboarding — you do not turn it on from a settings screen. The MCP Manager team enables it for your workspace and gives you the connection details to paste into your IdP. The in-app SSO / SCIM settings page, where you map IdP groups to teams, is visible only to roles with the Manage SSO/SCIM mapping capability (see Who can configure SCIM mapping). To request SCIM, use the Contact us prompt on the SSO / SCIM settings page or talk to your MCP Manager contact.

​
How provisioning works in MCP Manager

MCP Manager is the SCIM service provider (the target): your IdP pushes changes to a SCIM endpoint that MCP Manager hosts for your workspace. Your IdP authenticates to that endpoint with a bearer token issued specifically for your workspace. There are two values your IdP needs, and we provide both during onboarding:
  • A SCIM base URL — the per-workspace endpoint your IdP pushes to. We give you the exact value during onboarding.
  • A bearer token — the secret your IdP presents on every SCIM request. We generate it and hand it over through a secure, time-limited link; copy it into your IdP promptly, because the link expires.
SCIM provisioning is independent of, but complementary to, single sign-on. SSO controls how people sign in; SCIM controls how their accounts and team membership are created and kept current. Most enterprise customers enable both: SCIM provisions users and their teams ahead of time, and SSO signs them in. They are configured as two separate applications in your IdP — the OIDC application for sign-in and the SCIM application for provisioning — each with its own assignment list.

​
What you provide, and what we configure

Enabling SCIM is an assisted step. We turn it on for your workspace and issue the credentials; you connect your IdP.
1

We enable SCIM and issue your credentials

The MCP Manager team enables SCIM for your workspace and provides your SCIM base URL and a bearer token. The token is delivered through a secure link that expires after a short window, so copy it into your IdP as soon as you receive it.
The bearer token grants full provisioning access to your workspace’s users and groups. Treat it like a password: paste it directly into your IdP’s provisioning settings, never store it in plaintext, and ask us to rotate it if it is ever exposed.
2

Add a SCIM application in your IdP

In your IdP, add a SCIM 2.0 application that authenticates with an OAuth bearer token. In Okta, the App Catalog entry SCIM 2.0 Test App (OAuth Bearer Token) works well; name it something recognizable such as MCP Manager SCIM. You can leave the sign-in defaults as they are — this application is used only for provisioning, not for login.
3

Enter the base URL and token, then test

In the application’s Provisioning settings, configure the API integration with the SCIM base URL and bearer token we provided, then run your IdP’s Test Connector Configuration. A successful test confirms your IdP can reach MCP Manager and authenticate.
4

Enable the provisioning actions

Under the provisioning To App settings, enable Create Users, Update User Attributes, and Deactivate Users. These are the lifecycle actions MCP Manager honors. Save.
With the connection tested and these actions enabled, your IdP can now create, update, and deactivate MCP Manager users.
5

Hide the SCIM application from users

Set the SCIM application not to display to users (in Okta, Do not display application icon to users). It is a provisioning connector, not a sign-in tile — your users launch MCP Manager through the OIDC application or the login page, as described in SSO.

​
Assign users and push groups

Once the connector is live, you choose who gets provisioned and which groups become teams. These are two distinct steps in your IdP.
1

Assign users to the SCIM application

On the SCIM application’s Assignments tab, assign the people who should exist in MCP Manager — usually by assigning whole groups rather than individuals. Each assigned user is created as an MCP Manager user.
2

Push the groups you want to become teams

On the Push Groups tab, push the IdP groups you want represented in MCP Manager. Pushing a group sends its definition and membership to MCP Manager, where you then map it to a team (next section). Pushing groups is separate from importing groups — MCP Manager receives groups from your IdP; you do not import MCP Manager groups back into the IdP.

​
Map IdP groups to teams in MCP Manager

Pushing a group makes it visible in MCP Manager, but it does not yet grant access. You decide which MCP Manager team each IdP group corresponds to. This deliberate mapping step lets you point an IdP group at a brand-new team or consolidate several IdP groups onto one existing team.
1

Open the SSO / SCIM settings page

Go to the SSO / SCIM settings page. Groups your IdP has pushed appear in the mapping table. A notice highlights any groups that are not yet mapped to a team.
2

Create matching teams, or map to existing ones

Select Create matching teams in MCP Manager to create one team per unmapped group automatically, matching on the group’s name. Alternatively, map a group to a team that already exists to consolidate membership onto it. After mapping, members of that IdP group are placed on the corresponding team.
Mapping is a manual step you repeat when you add new groups you want represented as teams — newly pushed groups are not turned into teams automatically. Provisioned users still arrive automatically; it is the group-to-team mapping that you confirm here.

​
How users and teams stay in sync

After the initial setup, MCP Manager keeps users and team membership aligned with your IdP. The behaviors below define what happens through the user lifecycle.
  • Your IdP is the source of truth. Fields and team memberships that SCIM manages are owned by your IdP. In MCP Manager, those controls are locked, with the message: “This value is managed by an external identity provider (SCIM). To change it, update the user in your IdP — the change will sync back into MCP Manager on the next push.” To change a managed value, change it in your IdP.
  • SCIM takes precedence. An administrator can still add a user to a SCIM-managed team manually — useful for granting immediate access — but the next push from your IdP reconciles membership to what the IdP says. Manual additions that the IdP does not reflect are overwritten on sync; team memberships an administrator created outside of SCIM (on teams not driven by a mapped group) are left untouched.
  • Deactivation is a soft deactivation. When your IdP deactivates a user (or sends a delete), MCP Manager marks the account inactive and ends its workspace membership, but retains the record so a later reactivation or re-hire restores it cleanly. Re-activating the user in your IdP brings the account back and re-applies their group-derived team membership.
  • Deprovisioning is scoped to your managed domain. SCIM only manages the users your IdP provisions. Accounts that were added by other means — for example, a user on a different email domain, or a manually created account — are not deactivated by SCIM. Remove those manually if you no longer want them.
  • SSO without SCIM still grants entry, not access. A user on a registered SSO domain who signs in before SCIM provisions them is created just-in-time and can sign in, but receives no team-based access until SCIM (or an administrator) places them on a team. See First sign-in and access.

​
SCIM syncs teams, not roles

SCIM provisions users and keeps their team membership in sync with your IdP groups — but it does not assign or sync a user’s role. The two are deliberately separate:
  • Teams sync from your IdP. Mapping IdP groups to teams (above) is part of the standard SCIM implementation, so team membership stays current automatically.
  • Roles are managed manually in MCP Manager. A SCIM-provisioned user is created with your workspace’s default role; from there, roles are assigned and changed by hand inside MCP Manager. There is no mapping today from an IdP group or attribute to an MCP Manager role.
If you would like roles to be driven from your IdP as well, that is not available today, but we are open to it — talk to your MCP Manager contact about your requirements.

​
Who can configure SCIM mapping

The group-to-team mapping interface lives on the in-app SSO / SCIM settings page, and both its visibility and its actions are controlled by the Manage SSO/SCIM mapping capability. When a user’s role has this capability, the SSO / SCIM settings page — including the mapping table and the Create matching teams in MCP Manager action — is available to them; when it does not, the page is hidden. Capabilities are assigned per role and are fully configurable, including on any custom roles you create, so access depends on the capabilities granted to a person’s role rather than on any fixed role name.
If you cannot find the SSO / SCIM settings page, your role does not have the Manage SSO/SCIM mapping capability. Ask a workspace administrator to grant it to your role from People.

​
Supported SCIM operations

MCP Manager implements the SCIM 2.0 protocol for users and groups, with the standard discovery endpoints (ServiceProviderConfig, ResourceTypes, and Schemas) so your IdP can negotiate capabilities automatically. The behaviors and limits below define what your IdP can rely on.
  • Users. Create, fetch, list, update (PUT and PATCH), and deactivate. Deactivating a user (active: false or a delete) is a soft deactivation, as described in How users and teams stay in sync. Creating a user that already exists returns a conflict that points your IdP at the existing record, so retries are safe.
  • Groups. Create, fetch, list, update, and member add/remove. Group membership changes are translated into MCP Manager team membership through the mappings you configure.
  • Filtering and paging. List requests support a simple attribute eq "value" filter (for example, on userName). Results are paginated, and a single page returns at most 500 records; larger requests are clamped to that ceiling.
  • Not supported. Bulk operations, sorting, ETag concurrency control, password change, and complex filter expressions are not supported. Requests that depend on them are rejected.
  • Isolation and security. Each workspace’s SCIM endpoint is authenticated by its own bearer token, the token is stored encrypted, and every request is scoped to that workspace — one workspace’s token cannot read or change another workspace’s users or groups. SCIM activity is logged for auditing.

​
Troubleshooting

Confirm the SCIM base URL and bearer token were pasted exactly as provided, with no trailing spaces, and that the token has not expired before you copied it. Because the token is delivered through a time-limited link, an expired or partially copied token is the most common cause. If the token is no longer available, ask us to rotate and reissue it.
Provisioning creates users; teams grant access. Confirm you pushed the relevant groups and mapped them to teams on the SSO / SCIM settings page. Until a user’s group is mapped to a team, the user exists but has no gateway access.
Newly pushed groups are not converted to teams automatically. Open the SSO / SCIM settings page and select Create matching teams in MCP Manager, or map the group to an existing team. You repeat this when you push additional groups.
Fields owned by SCIM are intentionally read-only in MCP Manager. Change the value in your IdP; it syncs back on the next push. The locked control shows a tooltip explaining this.
Deactivation is a soft deactivation: the account is marked inactive and its workspace membership ends, but the record is retained so a future re-hire restores it. SCIM also only deprovisions users it manages — accounts on other domains or created manually must be removed by an administrator.

​
Further reading

Supported identity providers

The searchable list of IdPs MCP Manager works with for SSO and SCIM.

Single sign-on (SSO)

Sign your team in through your corporate identity provider.

Teams

How team membership grants users access to gateways.

Capabilities

The full reference of role capabilities, including SSO/SCIM mapping.

​
External sources

Okta provisioning setup

Okta’s guide to configuring SCIM provisioning for an app.