Connect Indeed SCIM to Claude: Manage Accounts and Employer Org Data

If you need to connect Indeed SCIM to Claude to automate user provisioning, employer organization mapping, or identity audits, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's tool calls and Indeed's REST APIs. 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 connecting Indeed SCIM to ChatGPT or explore our broader architectural overview on connecting Indeed SCIM to AI Agents.

Giving a Large Language Model (LLM) read and write access to a core identity management system like Indeed SCIM is an engineering challenge. You have to map the strict System for Cross-domain Identity Management (SCIM) specifications to MCP tool definitions, handle complex nested schema URNs, and deal with Indeed-specific API behaviors. Every time an LLM hallucinates a field in a user update request, you risk corrupting an employer account.

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

The Engineering Reality of the Indeed 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 Indeed's SCIM API is painful. You are not just dealing with a standard REST API; you are dealing with a strict identity protocol bolted onto a massive job board ecosystem.

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

Full Overwrite Updates (The PUT Trap) The SCIM standard typically supports PATCH for partial updates. However, the Indeed SCIM update_a_indeed_scim_user_by_id endpoint is a full overwrite. Every value on the account is replaced. If an attribute is empty or omitted in the payload, it is wiped from the user record. If you simply expose this endpoint to Claude and ask it to "update the user's name," the model might send a payload containing only the name, permanently deleting their email and employer mappings. Truto's dynamically generated tool schemas explicitly define these as required fields, forcing the LLM to fetch the user first and pass the complete object back.

Complex URN Schemas SCIM relies on highly nested JSON structures and specific URNs. Indeed uses a custom extension: urn:ietf:params:scim:schemas:extension:indeed:2.0:EmployerOrg. LLMs are notoriously bad at consistently generating long, arbitrary strings like this from scratch. A managed MCP server derives the tool's body_schema directly from the integration's documentation records, feeding the exact required JSON Schema to Claude so it knows precisely how to format the extension payload.

Asynchronous Deletions When you delete a user via the Indeed SCIM API, the system automatically removes them from any employer organizations and returns a 204 No Content success response. However, the actual deletion process can take up to 30 minutes to complete. If you ask Claude to delete a user and immediately ask it to verify the deletion by fetching the ID, the API might still return the user. Your agent logic needs to understand this temporal delay.

Rate Limits and 429 Passthrough Indeed enforces strict rate limits to protect its identity infrastructure. It is critical to note: Truto does not retry, throttle, or apply backoff on rate limit errors. When Indeed returns an HTTP 429, Truto passes that error directly to the caller. Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. The caller—in this case, your AI agent or Claude—is entirely responsible for reading the reset window and executing retries with backoff.

How to Generate an Indeed SCIM MCP Server with Truto

Truto dynamically generates MCP tools based on the Indeed SCIM integration's underlying resource definitions and documentation records. No documentation means no tool. This acts as a strict quality gate, ensuring only well-defined identity operations are exposed to the LLM.

Each MCP server is backed by a cryptographic token stored in a distributed key-value store. This token encodes the specific integrated account, the environment, and the tool filters. The resulting URL is fully self-contained.

You can generate this server URL in two ways: via the Truto UI or programmatically via the API.

Method 1: Via the Truto UI

For ad-hoc agent usage or internal IT administration, the UI is the fastest route.

1. Log into Truto and navigate to the integrated account page for your connected Indeed SCIM instance.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration (e.g., limit the server to read methods only, or apply specific tool tags).
5. Copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4e5f6...).

Method 2: Via the API

For production multi-agent systems, you should generate MCP servers programmatically. Make a POST request to /integrated-account/:id/mcp.

// POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp
// Authorization: Bearer {TRUTO_API_KEY}
 
{
  "name": "Claude Indeed SCIM Provisioning",
  "config": {
    "methods": ["read", "write"],
    "require_api_token_auth": false
  },
  "expires_at": "2026-12-31T23:59:59Z"
}

The Truto API will validate that tools exist, hash the token securely, and return the database record along with the ready-to-use URL.

Connecting the MCP Server to Claude

Once you have your Truto MCP URL, you need to connect it to Claude. Because Truto handles the translation from JSON-RPC to Indeed's REST API natively over HTTP, integration is trivial. You can connect it via the Claude Desktop UI or via manual configuration files.

Method A: Via the Claude UI

If you are using Claude Desktop (or configuring Custom Connectors in ChatGPT):

1. Open Claude Desktop.
2. Navigate to Settings → Integrations → Add MCP Server (in ChatGPT, this is under Settings → Apps → Advanced settings → Developer mode).
3. Name the server (e.g., "Indeed Identity").
4. Paste the Truto MCP URL into the connection field.
5. Click Add.

Claude will immediately call the /mcp/:token endpoint with the initialize and tools/list JSON-RPC commands, populating its context window with the available Indeed SCIM tools.

Method B: Via Manual Config File

If you are deploying Claude Desktop across an IT team or using custom agent frameworks, you can configure the MCP server manually using the official Server-Sent Events (SSE) transport wrapper.

Edit your claude_desktop_config.json file:

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

Restart Claude Desktop. The model now has full, authenticated access to your Indeed SCIM tenant.

Indeed SCIM Hero Tools for Claude

Truto automatically maps the Indeed SCIM documentation into descriptive, snake_case tool names. Below are the primary hero tools your agents will use to manage identities.

list_all_indeed_scim_users

Use this tool to search for specific users based on their externalId or email. Because of SCIM's exact match filtering rules, this tool returns a maximum of one user. If multiple users match the filter, the API returns an error.

"Claude, check if there is an active Indeed SCIM user associated with the email 'jdoe@acmecorp.com'. If they exist, return their externalId."

get_single_indeed_scim_user_by_id

Fetches a complete user object by their encrypted account ID. This is a critical prerequisite step before performing an update, as it retrieves the current baseline of the user's attributes and Employer Organization mappings.

"Retrieve the full SCIM profile for the Indeed user with ID 'enc-8f7d6c5b'. I need to see which employer organizations they belong to."

create_a_indeed_scim_user

Creates a new Indeed SCIM identity. This requires a highly structured payload, including the base SCIM schemas array, the externalId, a primary email, name fields, and optionally the Indeed EmployerOrg extension.

"Provision a new Indeed user for Sarah Connor. Her email is sconnor@acme.com, externalId is 'emp-9921', and she needs to be mapped to the EmployerOrg with ID 'org-1234'. Format the SCIM payload correctly."

update_a_indeed_scim_user_by_id

Updates a user record. Warning: This is a full overwrite operation. Every attribute you want to preserve must be included in the request body. If the LLM omits the emails array, the user's email will be wiped. Always instruct Claude to read the user first.

"I need to update John Doe's Indeed SCIM account (ID 'enc-1122') to inactive. First, fetch his complete current profile. Then, run the update tool passing his exact current profile back, but change the 'active' boolean to false."

delete_a_indeed_scim_user_by_id

Initiates the asynchronous deletion of an Indeed SCIM user. The user is stripped of their employer organization mappings and queued for deletion.

"Offboard the user with ID 'enc-5544'. Delete their Indeed SCIM account. Acknowledge that the deletion will return a success response immediately, but may take up to 30 minutes to finalize on Indeed's servers."

For the complete inventory of available endpoints and their exact JSON schemas, refer to the Indeed SCIM integration page.

Workflows in Action

When Claude is equipped with Truto's Indeed SCIM MCP server, it can orchestrate complex, multi-step identity workflows that typically require manual IT intervention or brittle Python scripts.

Scenario 1: The New Hire Provisioning Sequence

An IT administrator asks Claude to onboard a new batch of recruiters and assign them to the correct employer organization within Indeed.

"We just hired two new recruiters: Alice (alice@corp.com, emp-001) and Bob (bob@corp.com, emp-002). Provision Indeed SCIM accounts for both of them and assign them to our primary EmployerOrg 'org-7788'."

Step-by-step execution:

1. Claude calls list_all_indeed_scim_users for Alice's email to ensure the account doesn't already exist.
2. Claude calls create_a_indeed_scim_user, structuring the base SCIM payload and injecting the urn:ietf:params:scim:schemas:extension:indeed:2.0:EmployerOrg extension for 'org-7788'.
3. Claude repeats the validation and creation process for Bob.
4. Claude returns a summarized confirmation with the encrypted account IDs for both new users.

sequenceDiagram
    participant Admin as IT Admin
    participant Claude as Claude Desktop
    participant MCP as Truto MCP Server
    participant Upstream as Indeed SCIM API

    Admin->>Claude: Provision new recruiters
    Claude->>MCP: Call list_all_indeed_scim_users (Alice)
    MCP->>Upstream: GET /Users?filter=...
    Upstream-->>MCP: 200 OK (0 results)
    MCP-->>Claude: Empty result
    Claude->>MCP: Call create_a_indeed_scim_user (Alice + URN)
    MCP->>Upstream: POST /Users
    Upstream-->>MCP: 201 Created (ID: enc-123)
    MCP-->>Claude: User profile
    Claude->>Admin: Provisioning complete.

Scenario 2: Safe User Offboarding

An HR automated agent needs to offboard an employee but must adhere to strict data-integrity rules regarding full overwrites and async deletions.

"Employee 'emp-555' is leaving the company. Mark their Indeed SCIM account as inactive to immediately revoke access, then issue a deletion command to clear their data."

Step-by-step execution:

1. Claude calls list_all_indeed_scim_users filtering by externalId=emp-555 to retrieve the encrypted account ID.
2. Claude calls get_single_indeed_scim_user_by_id to pull the complete, exact JSON payload of the user.
3. Claude modifies only the active: false property in memory.
4. Claude calls update_a_indeed_scim_user_by_id, passing the entire preserved payload back to execute a safe full-overwrite.
5. Claude then calls delete_a_indeed_scim_user_by_id to queue the account for permanent removal.
6. Claude informs the user that the account is secured and the deletion will finalize within 30 minutes.

Security and Access Control

Giving an LLM write access to your company's identity provider is high-stakes. The Truto MCP architecture includes several layers of defense to ensure models only do exactly what they are authorized to do.

• Method Filtering (config.methods): You can restrict an MCP server to specific operation types. Setting methods: ["read"] ensures the LLM can only execute get and list operations, physically preventing it from creating, updating, or deleting identities.
• Tag Filtering (config.tags): If the integration supports multiple resources, you can slice the available tools by tag, ensuring the server only exposes specific domains.
• Expiration (expires_at): You can generate ephemeral MCP servers. Set a TTL, and the underlying edge key-value store will automatically expire the token, severing the LLM's access at the designated time.
• Double Authentication (require_api_token_auth): By default, the cryptographically secure MCP URL is the only auth needed. By setting require_api_token_auth: true, you force the client to also provide a valid Truto API token in the Authorization header. This means possession of the URL alone isn't sufficient.

Stop Hardcoding SCIM Schemas

Building an integration with Indeed SCIM is notoriously difficult because of the rigid, nested URN structures required by the SCIM standard. When you add LLMs into the mix, hallucinated JSON keys become a massive liability.

Truto's documentation-driven MCP generation solves this. By deriving the tool definitions directly from the integration's schemas, Truto effectively teaches Claude the exact API contract at runtime. You get normalized pagination, raw 429 rate limit passthrough, and a fully authenticated JSON-RPC interface without writing a single line of boilerplate integration code.