Connect Docker Hub SCIM to Claude: Manage Member Identity & Access

If you need to connect Docker Hub SCIM to Claude to automate user provisioning, audit member access, or execute zero-touch offboarding, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's LLM function calls and Docker Hub's SCIM REST 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-docker-hub-scim-to-chatgpt-automate-user-provisioning/ or explore our broader architectural overview on /connect-docker-hub-scim-to-ai-agents-sync-and-audit-user-metadata/.

Giving a Large Language Model (LLM) read and write access to a core infrastructure identity provider like Docker Hub is an engineering challenge. You have to handle API token lifecycles, map SCIM's notoriously nested JSON schemas to flat MCP tool definitions, and deal with strict API quotas. Every time your identity requirements change, 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 Docker Hub SCIM, connect it natively to Claude Desktop, and execute complex identity management workflows using natural language.

The Engineering Reality of the Docker Hub SCIM 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 Docker Hub SCIM API is painful. SCIM (System for Cross-domain Identity Management) is a heavily standardized specification, and Docker Hub's implementation brings its own specific constraints.

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

Deeply Nested SCIM 2.0 Payloads SCIM 2.0 (RFC 7643/7644) relies on strict, heavily nested JSON schemas. An LLM cannot just send a flat { "email": "user@example.com" } payload. It must construct complex objects like urn:ietf:params:scim:schemas:core:2.0:User with arrays for emails, tracking the primary boolean flag, and separating name.givenName from userName. When an MCP client calls a tool, the arguments arrive as a single flat object. Your MCP router must map this flat LLM output into the deeply nested hierarchy Docker Hub expects. A managed MCP server handles this by dynamically generating JSON schemas from documentation records, allowing query and body parameters to share a flat input namespace while automatically reassembling the nested payload before hitting the proxy API.

Non-Standard Pagination Mechanics Docker Hub SCIM does not use cursor-based pagination or simple page numbers. It enforces the SCIM standard startIndex (1-indexed) and count parameters. LLMs are notoriously bad at basic arithmetic, making it highly likely that the model will hallucinate startIndex values or lose track of its position during bulk audits. You must build an abstraction layer that intercepts these requests, manages the 1-indexed offset math, and explicitly instructs the LLM via tool descriptions on how to pass the next iteration index unchanged.

Rate Limits and 429 Errors Identity operations are often performed in bulk (e.g., auditing 5,000 Docker Hub seats). You will inevitably hit Docker Hub's API rate limits. It is critical to note that Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Docker Hub API returns an HTTP 429, Truto passes that error directly back to the caller. Truto normalizes the upstream rate limit info into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. The MCP client or agent framework is entirely responsible for detecting the error and executing its own retry or backoff logic based on those headers. Do not expect the integration layer to absorb these faults automatically.

How to Generate the Docker Hub SCIM MCP Server

Truto's MCP servers feature turns any connected Docker Hub SCIM integration into a ready-to-use JSON-RPC 2.0 endpoint. Tool generation is dynamic and documentation-driven. Rather than hand-coding tool definitions, Truto derives them from the integration's resource definitions and human-readable schemas.

You can generate the MCP server URL using either the Truto dashboard or the REST API.

Method 1: Via the Truto UI

This is the fastest approach for one-off admin tasks or local testing with Claude Desktop.

1. Navigate to the Integrated Accounts page in your Truto dashboard and select your connected Docker Hub SCIM account.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration (e.g., Name the server "Docker SCIM Admin", select allowed methods like read or write, and set an optional expiration date).
5. Copy the generated MCP server URL (it will look like https://api.truto.one/mcp/<secure-token>).

Method 2: Via the Truto API

For platform engineers building multi-tenant AI products, you can generate MCP servers programmatically. The API validates that tools exist, generates a secure token backed by distributed KV storage, and returns a ready-to-use URL.

Make an authenticated POST request to /integrated-account/:id/mcp:

curl -X POST https://api.truto.one/integrated-account/<docker-hub-account-id>/mcp \
  -H "Authorization: Bearer <YOUR_TRUTO_API_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Docker Hub SCIM Offboarding",
    "config": {
      "methods": ["read", "write"],
      "tags": ["identity"]
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

The API returns the token record and the endpoint URL:

{
  "id": "mcp_2a3b4c",
  "name": "Docker Hub SCIM Offboarding",
  "config": { "methods": ["read", "write"], "tags": ["identity"] },
  "expires_at": "2026-12-31T23:59:59.000Z",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890"
}

This URL contains a cryptographic token that securely maps to the specific Docker Hub SCIM tenant. It is fully self-contained.

Connecting the MCP Server to Claude

Once you have your Truto MCP URL, you can plug it into any compatible client. Because the URL is an HTTP endpoint, communication happens over HTTP POST with JSON-RPC 2.0 messages.

Method A: Via the Claude or ChatGPT UI

If you are using enterprise conversational interfaces, you can paste the URL directly into the settings.

For Claude Web/Desktop:

1. Go to Settings -> Integrations -> Add MCP Server.
2. Paste your Truto MCP URL into the connection field.
3. Click Add. Claude will immediately issue an initialize request and call tools/list to discover your Docker Hub capabilities.

For ChatGPT:

1. Go to Settings -> Apps -> Advanced settings.
2. Enable Developer mode.
3. Under MCP servers / Custom connectors, click add, name it "Docker SCIM", and paste the URL.

Method B: Via Manual Config File (Claude Desktop)

If you are running Claude Desktop locally and prefer file-based configuration, you can use the official @modelcontextprotocol/server-sse package to proxy the connection.

Edit your claude_desktop_config.json file (typically located at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "docker-hub-scim": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/<your-secure-token>"
      ]
    }
  }
}

Restart Claude Desktop. The application will launch the SSE proxy, establish the handshake, and the Docker Hub SCIM tools will appear in the UI.

Hero Tools for Docker Hub SCIM

When Claude calls tools/list, Truto dynamically generates tool definitions based on the integration's documented capabilities. Here are the highest-leverage tools available for Docker Hub SCIM.

list_all_docker_hub_scim_users

Fetches a paginated list of users mapped to the Docker Hub organization. This is the foundation for auditing licenses and identifying rogue accounts. It requires handling the startIndex and count parameters.

"Fetch the first 50 users from our Docker Hub organization to verify who currently has access."

get_single_docker_hub_scim_user_by_id

Retrieves a specific user's SCIM profile by their unique ID. Useful for deep-diving into a specific engineer's group memberships or status before taking action.

"Get the full Docker Hub SCIM profile for user ID 'usr_01H9X...' to check their active status."

create_a_docker_hub_scim_user

Provisions a new user in Docker Hub. If the user already exists by email, they are assigned to the organization on the 'company' team. Requires constructing the SCIM schemas array and passing the userName.

"Provision a new Docker Hub user for sarah.connor@example.com with the standard SCIM 2.0 schema."

update_a_docker_hub_scim_user_by_id

Modifies an existing user's attributes. This route is most commonly used for offboarding by flipping the active boolean to false, instantly revoking their Docker Hub access.

"Deactivate the Docker Hub SCIM user with ID 'usr_01H9X...' immediately as they have left the company."

list_all_docker_hub_scim_resource_types

Returns all resource types supported by the Docker Hub SCIM configuration. This helps the LLM understand what entities it can interact with if it needs to introspect the identity provider's capabilities.

"List the supported SCIM resource types for this Docker Hub instance to see if we can manage groups."

docker_hub_scim_service_provider_config_get_current

Fetches the service provider configuration. This tells the LLM which SCIM features (like PATCH support, bulk operations, or specific authentication schemes) Docker Hub actually supports, preventing the model from hallucinating invalid operations.

"Check the Docker Hub SCIM service provider config to see if bulk operations are supported."

For a complete list of available operations, schema properties, and required fields, view the full inventory on the Docker Hub SCIM integration page.

Workflows in Action

By chaining these tools together, Claude can execute multi-step identity workflows that typically require a DevOps engineer clicking through the Docker Hub admin console or writing custom bash scripts.

Scenario 1: Zero-Touch Offboarding

A security engineer needs to revoke a departing employee's access to Docker Hub.

"Find the user account for alex.smith@example.com in Docker Hub and deactivate it immediately to revoke access."

1. list_all_docker_hub_scim_users: Claude searches the directory by iterating through the pagination (or using SCIM filters if supported by the LLM prompt construction) to locate the id associated with alex.smith@example.com.
2. update_a_docker_hub_scim_user_by_id: Claude takes the retrieved id and executes an update payload setting the SCIM active attribute to false.

Result: The user is locked out of Docker Hub instantly, and Claude replies with a confirmation that the account ID has been disabled.

Scenario 2: Routine License Auditing

An IT admin needs a summary of active users to true-up their Docker Hub billing.

"Retrieve the list of all active users in our Docker Hub SCIM tenant and count how many seats we are currently utilizing."

1. list_all_docker_hub_scim_users: Claude calls this tool, passing startIndex=1 and count=100.
2. list_all_docker_hub_scim_users (Loop): If the response indicates more users exist, Claude increments startIndex and fetches subsequent pages.

Result: Claude aggregates the JSON arrays, filters out any records where active is false, and provides a final count and summary list to the IT admin.

Scenario 3: Just-in-Time Provisioning

An engineering manager requests access for a new hire.

"Check if j.doe@example.com has a Docker Hub account. If not, provision one for them under our company organization."

sequenceDiagram
    participant User as User Prompt
    participant Claude as Claude Desktop
    participant Truto as Truto MCP Server
    participant Docker as Docker Hub SCIM API

    User->>Claude: Check for j.doe, create if missing
    Claude->>Truto: Call list_all_docker_hub_scim_users (filter by email)
    Truto->>Docker: GET /Users?filter=userName eq j.doe
    Docker-->>Truto: 200 OK (0 resources)
    Truto-->>Claude: Empty result array
    Claude->>Truto: Call create_a_docker_hub_scim_user
    Truto->>Docker: POST /Users (JSON payload)
    Docker-->>Truto: 201 Created
    Truto-->>Claude: User object with ID
    Claude-->>User: Provisioned successfully with ID

1. list_all_docker_hub_scim_users: Claude queries the directory to ensure the user does not already exist, preventing a conflict error.
2. create_a_docker_hub_scim_user: Seeing an empty result, Claude constructs the SCIM 2.0 JSON payload and invokes the creation tool.

Result: The new engineer is provisioned and automatically added to the default team, and Claude returns the new user ID to the manager.

Security and Access Control

Exposing your core identity provider to an LLM requires strict boundary setting. Truto's MCP servers are designed to enforce least-privilege access at the infrastructure level, preventing the model from performing unauthorized actions even if prompted maliciously.

• Method Filtering (config.methods): Restrict the server to specific HTTP verbs. Creating a server with "methods": ["read"] ensures the LLM can only execute get and list tools. It physically cannot create or delete Docker Hub users, regardless of the prompt.
• Tag Filtering (config.tags): Scope the server to specific resource tags. If your integration defines custom tool_tags, you can limit the LLM to only interact with subset resources (e.g., only users but not groups).
• Time-to-Live (expires_at): Generate ephemeral MCP servers for temporary access. By setting an ISO datetime, the server token and distributed KV entries automatically expire and self-destruct. This is perfect for granting contractors a 24-hour auditing window.
• Double Authentication (require_api_token_auth): By default, the cryptographically secure URL acts as a bearer token. For higher security environments, setting this flag requires the MCP client to also pass a valid Truto API token in the Authorization header, validating both the URL and the caller's identity.

Wrap-Up

Automating Docker Hub SCIM identity lifecycles with Claude removes a massive operational burden from IT and DevOps teams. By wrapping the complex, heavily nested SCIM 2.0 protocol in a managed MCP server, you abstract away the API mechanics and let the LLM focus on the business logic of provisioning and auditing.

Stop writing custom scripts to handle SCIM pagination and JSON mapping. Use Truto to generate a secure, governed MCP endpoint, connect it to Claude, and start managing Docker Hub identity with natural language today.