Skip to main content
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. 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, authenticating every request with a bearer token issued specifically for your workspace. We provide both the endpoint and the token during onboarding. 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.

​
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 user record so your audit history stays intact: every logged action keeps pointing at the real person who performed it, even after they leave. Re-activating the user in your IdP restores the account 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.

​
Connect your IdP

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

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

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 — with your SCIM application already created, you can paste it in as soon as it arrives.
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.
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. While you are on the API integration settings, uncheck Import Groups (Okta enables it by default) — provisioning flows one direction, from your IdP into MCP Manager, and importing would pull MCP Manager’s groups back into your IdP as app groups. Then run your IdP’s Test Connector Configuration. A successful test confirms your IdP can reach MCP Manager and authenticate.
Some IdPs (for example, JumpCloud) create a temporary test user — and sometimes a test group — during activation to verify the integration. When asked for a test user email, use a placeholder address such as scim-test@yourcompany.com, never a real employee’s. After activation, a deactivated test user may remain visible in MCP Manager; it is safe to ignore or remove.
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 map groups to teams

Once the connector is live, you choose who gets provisioned and which groups become teams. Assigning and pushing happen in your IdP; mapping happens in MCP Manager.
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. 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.
3

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 — pushing a group makes it visible, but it does not yet grant access.
4

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.

​
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 user record is retained so audit history referencing that person stays intact (and a future re-hire restores cleanly). SCIM also only deprovisions users it manages — accounts on other domains or created manually must be removed by an administrator.

​
Frequently asked questions

No — 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. 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 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.
Your role does not have the Manage SSO/SCIM mapping capability, which controls visibility and access to the SSO / SCIM settings page — including the mapping table and the Create matching teams in MCP Manager action. Ask a workspace administrator to grant the capability to your role from People. Capabilities are assigned per role and are fully configurable, including on custom roles, so access depends on the capability rather than on any fixed role name.

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