Connect Superblocks to Claude: Sync SCIM Users and Group Members

If you need to connect Superblocks to Claude to automate SCIM provisioning, manage identity groups, or handle bulk user workflows, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's tool calls and the Superblocks SCIM 2.0 API. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL. If your team uses ChatGPT, check out our guide on /connect-superblocks-to-chatgpt-manage-scim-users-and-group-access/ or explore our broader architectural overview on /connect-superblocks-to-ai-agents-automate-bulk-identity-workflows/.

Giving a Large Language Model (LLM) read and write access to an internal developer platform's identity layer is an engineering challenge. You have to handle access tokens, map massive SCIM schema definitions to MCP tool formats, and deal with strict rate limits. Every time an endpoint changes or you need to support a new SCIM extension, you have to update your server code, redeploy, and test the integration.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Superblocks, connect it natively to Claude, and execute complex identity workflows using natural language.

The Engineering Reality of the Superblocks API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against the Superblocks API - specifically its SCIM 2.0 implementation - is painful. You are not just integrating a standard REST API; you are integrating an identity management protocol that has highly specific design patterns.

If you decide to build a custom MCP server for Superblocks, you own the entire API lifecycle. Here are the specific challenges you will face:

Complex SCIM 2.0 Payload Structures SCIM (System for Cross-domain Identity Management) does not use simple flat JSON objects. User resources require specific schema definitions, such as urn:ietf:params:scim:schemas:core:2.0:User and urn:ietf:params:scim:schemas:extension:enterprise:2.0:User. Fields like emails and names are nested arrays of objects. If you expose raw SCIM endpoints to Claude without a highly structured JSON Schema mapping, the model will frequently hallucinate payload structures, leading to 400 Bad Request errors. A managed MCP server handles this translation, providing Claude with strict, predefined schemas for every operation.

Partial Updates via JSON Patch Superblocks relies on the SCIM PATCH specification for partial updates. To deactivate a user, you cannot simply send a DELETE request or a flat JSON object with active: false. Instead, you must send a structured Operations array, for example: [{"op": "replace", "path": "active", "value": false}]. Teaching an LLM to reliably generate these JSON Patch documents from scratch is notoriously difficult. A managed MCP server exposes these operations as explicitly defined tools (like superblocks_scim_users_partial_update), abstracting the underlying JSON Patch complexity.

Strict Rate Limits and Header Normalization Superblocks enforces rate limits to protect infrastructure. When building a custom MCP server, you must decide how to handle HTTP 429 Too Many Requests responses. Truto's architectural approach is transparent: Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Superblocks API returns an HTTP 429, Truto passes that error directly to the caller. However, Truto normalizes upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. This allows the Claude client or your orchestrator to implement precise, deterministic retry and backoff logic rather than relying on black-box middleware.

Generating a Superblocks MCP Server

To connect Claude to Superblocks, you first need an MCP server endpoint. Truto generates this dynamically based on your connected Superblocks account and the available API documentation records.

You can create this server in two ways: via the Truto UI for manual setup, or via the Truto API for programmatic deployment.

Method 1: Via the Truto UI

For administrators setting up an integration manually, the UI provides a quick way to generate a server URL.

1. Navigate to the Integrated Accounts page in your Truto dashboard.
2. Select your active Superblocks connection.
3. Click the MCP Servers tab.
4. Click Create MCP Server.
5. Select your desired configuration (name, allowed methods, tags, and optional expiry).
6. Copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4e5f6...).

Method 2: Via the Truto API

For platform engineers who want to provision MCP servers dynamically, you can use the Truto API. This is ideal for generating short-lived servers or scoping access programmatically.

Make a POST request to /integrated-account/:id/mcp with your desired configuration:

curl -X POST https://api.truto.one/integrated-account/<SUPERBLOCKS_ACCOUNT_ID>/mcp \
  -H "Authorization: Bearer <TRUTO_API_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Superblocks SCIM Admin",
    "config": {
      "methods": ["read", "write", "custom"],
      "tags": ["scim", "identity"]
    }
  }'

The API returns a secure, authenticated URL that you will provide to Claude:

{
  "id": "mcp-789",
  "name": "Superblocks SCIM Admin",
  "config": { "methods": ["read", "write", "custom"], "tags": ["scim", "identity"] },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}

Connecting the MCP Server to Claude

Once you have your Truto MCP server URL, you need to register it with Claude. You can do this through the Claude user interface or by modifying the local configuration file for Claude Desktop.

Method 1: Via the Claude UI (or ChatGPT)

If you are using an AI client that supports UI-based MCP configuration (like ChatGPT Developer Mode or Claude web integrations), the process is straightforward:

1. Open your client settings (e.g., Settings -> Integrations -> Add MCP Server).
2. Enter a recognizable name, such as "Superblocks Identity".
3. Paste the Truto MCP URL into the Server URL field.
4. Click Add or Save.

The client will immediately ping the endpoint, perform the JSON-RPC handshake, and discover the available Superblocks tools.

Method 2: Via the Claude Desktop Config File

For engineers using Claude Desktop, you must modify the claude_desktop_config.json file. Because Truto provides a remote SSE (Server-Sent Events) endpoint, you will use the official @modelcontextprotocol/server-sse package to proxy the connection.

Locate your configuration file:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

Add the Superblocks server configuration:

{
  "mcpServers": {
    "superblocks": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/a1b2c3d4e5f6..."
      ]
    }
  }
}

Save the file and restart Claude Desktop. The model now has real-time access to your Superblocks identity architecture.

Superblocks Hero Tools

Truto automatically derives tool definitions from the Superblocks API documentation. Query and body parameters share a flat input namespace, which Truto maps to the correct HTTP locations securely. Here are the highest-leverage tools available for Superblocks SCIM automation.

list_all_superblocks_scim_users

Fetches a paginated list of SCIM users in your Superblocks organization. This tool automatically handles the limit and next_cursor logic, returning the user ID, schemas, display name, emails, active status, groups, and role.

"Fetch the first 50 active SCIM users in our Superblocks organization and list their email addresses and assigned groups."

create_a_superblocks_scim_user

Provisions a new user in Superblocks via SCIM. The tool expects standard SCIM attributes, including an array of emails and a formatted name object. It returns the newly created user ID and access details.

"Create a new Superblocks user for jane.doe@example.com with the display name 'Jane Doe'. Ensure she is set to active."

superblocks_scim_users_partial_update

Executes a JSON Patch operation on a specific user by ID. This is the primary method for deactivating users, reactivating them, or pushing specific profile attribute changes without overwriting the entire user record.

"Deactivate the Superblocks user with ID 'usr_12345' by setting their active status to false via a partial update."

list_all_superblocks_scim_groups

Retrieves the identity groups configured in your Superblocks environment. Groups control resource access and permissions. This tool returns the group ID, display name, members array, and metadata.

"List all SCIM groups in Superblocks and tell me how many members are currently assigned to the 'Engineering' group."

superblocks_scim_groups_partial_update

Modifies group memberships by applying PATCH operations. This allows Claude to assign or unassign specific users from a group by passing the user's value (ID) and the desired operation (e.g., add, remove).

"Remove the user with ID 'usr_9876' from the 'Contractors' SCIM group in Superblocks."

create_a_superblocks_scim_bulk

Submits a bulk SCIM request to perform multiple operations (POST, PUT, PATCH, DELETE) in a single API call. This is incredibly powerful for LLMs managing mass migrations or organizational restructuring, saving dozens of API round trips.

"Execute a bulk SCIM operation to deactivate users 'usr_111', 'usr_222', and 'usr_333' in a single request."

To view the complete inventory of available tools and their underlying JSON schemas, visit the Superblocks integration page.

Workflows in Action

Once Claude is connected to Superblocks via the MCP server, you can orchestrate complex, multi-step identity workflows using natural language. Here is how Claude translates human intent into sequential API executions.

sequenceDiagram
    participant Claude as Claude Desktop
    participant MCP as Truto MCP Server
    participant Superblocks as Superblocks API

    Claude->>MCP: Call create_a_superblocks_scim_user
    MCP->>Superblocks: POST /scim/v2/Users
    Superblocks-->>MCP: 201 Created (usr_888)
    MCP-->>Claude: Result: usr_888
    
    Claude->>MCP: Call superblocks_scim_groups_partial_update
    MCP->>Superblocks: PATCH /scim/v2/Groups/grp_devs
    Superblocks-->>MCP: 200 OK
    MCP-->>Claude: Result: Success

Workflow 1: Onboarding a New Developer

When a new engineer joins the team, IT admins need to provision their identity and assign them to the correct permission groups.

"We have a new hire starting today. Create a Superblocks SCIM user for alex.smith@example.com with the display name 'Alex Smith'. Once created, find the group ID for 'Backend Developers' and add Alex to that group."

Execution Steps:

1. Claude calls create_a_superblocks_scim_user, passing the email and display name in the required SCIM format.
2. Claude extracts the new user ID (e.g., usr_999) from the response.
3. Claude calls list_all_superblocks_scim_groups to retrieve the directory of groups and locates the ID for "Backend Developers".
4. Claude calls superblocks_scim_groups_partial_update, formatting a JSON Patch operation to add usr_999 to the backend group.

Result: The user is fully provisioned and properly assigned to their functional group without manual UI clicks.

Workflow 2: Offboarding and Access Revocation

When a contractor finishes their project, security policies dictate immediate revocation of access.

"Contractor John Doe (j.doe@example.com) has finished his contract. Find his Superblocks user ID, deactivate his account, and ensure he is removed from the 'External Vendors' group."

Execution Steps:

1. Claude calls list_all_superblocks_scim_users (potentially filtering or searching the returned array) to find the ID associated with j.doe@example.com.
2. Claude calls superblocks_scim_users_partial_update, sending a PATCH operation ({"op": "replace", "path": "active", "value": false}) to deactivate the user.
3. Claude calls list_all_superblocks_scim_groups to find the 'External Vendors' group ID.
4. Claude calls superblocks_scim_groups_partial_update with a remove operation targeting John's user ID.

Result: The contractor is systematically stripped of access and group memberships, maintaining strict identity compliance.

Security and Access Control

Giving AI models write access to your SCIM identity layer requires strict governance. Truto MCP servers provide multiple layers of access control, enforced at the edge before any request reaches Superblocks.

• Method Filtering: Restrict an MCP server strictly to safe operations. By configuring methods: ["read", "list"] during creation, you prevent the LLM from executing any POST, PATCH, or DELETE operations, effectively making the server read-only.
• Tag Filtering: Group tools logically. You can apply tags like ["scim_read"] to specific endpoints, ensuring the MCP server only exposes a curated subset of identity tools rather than the entire Superblocks API surface.
• Token Expiration: For temporary access (e.g., an auditor reviewing user lists), set an expires_at timestamp. The underlying infrastructure will automatically drop the token from edge storage and clean up the database record once the time expires, requiring no manual cleanup.
• Extra Authentication: By enabling require_api_token_auth: true, possession of the MCP URL is no longer sufficient. The connecting client must also supply a valid Truto API token in the Authorization header, adding a required secondary authentication layer.

Build Resilient Identity Automations

Connecting Superblocks to Claude using a managed MCP server removes the friction of SCIM 2.0 implementation. Instead of spending weeks wrestling with JSON Patch arrays, URN schemas, and pagination cursors, you can rely on Truto to handle the translation layer securely.

Whether you are building custom AI agents to automate onboarding, empowering IT admins with natural language provisioning, or syncing bulk identity data, dynamic tool generation ensures your models always have access to the right Superblocks resources.