Connect Lattice SCIM to Claude: Provision and Update User Records

If your team needs to connect Lattice SCIM to Claude to automate user provisioning, synchronize organizational charts, or orchestrate employee onboarding workflows, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's tool calls and the Lattice 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 connecting Lattice SCIM to ChatGPT or explore our broader architectural overview on connecting Lattice SCIM to AI Agents.

Giving a Large Language Model (LLM) read and write access to your primary performance management and HR directory is a high-stakes engineering challenge. You must handle complex identity payloads, map massive System for Cross-domain Identity Management (SCIM) schemas to MCP tool definitions, and deal with Lattice's specific domain constraints. Every time a new custom attribute is added or an endpoint behavior changes, 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 Lattice SCIM, connect it natively to Claude, and execute complex identity management workflows using natural language.

The Engineering Reality of the Lattice 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 over JSON-RPC, the reality of implementing it against specialized enterprise APIs is painful. Lattice SCIM is built to align with RFC 7643 and RFC 7644 - the core SCIM 2.0 specifications. Its API reflects the strictness and complexity of that standard.

If you decide to build a custom Lattice SCIM MCP server, here are the specific integration challenges you will face:

The SCIM Filtering Syntax

Lattice SCIM does not use standard REST query parameters like ?email=test@test.com. Instead, it uses the SCIM filter syntax, which requires exact string matching and logical operators, such as ?filter=userName eq "test@test.com". When LLMs are left to their own devices, they frequently hallucinate OData syntax, SQL-like syntax, or plain REST parameters. A robust MCP server must expose a query schema that strictly instructs the LLM on how to format SCIM filters, preventing malformed requests from throwing 400 Bad Request errors.

Complex Nested Extension Attributes

SCIM user resources are heavily nested. A user does not just have a department field; they often have a core schema and an extension schema, such as urn:ietf:params:scim:schemas:extension:enterprise:2.0:User, which houses fields like employeeNumber, costCenter, and manager. For an LLM to successfully update a user's manager, it must understand this exact nesting structure. Hand-coding these massive schemas into an MCP tool definition is tedious and prone to drift. Truto derives these tool definitions dynamically from documentation records, ensuring the LLM always sees the accurate, nested schema required by Lattice.

The SCIM PATCH Complexity

Updating a user in SCIM is notoriously difficult. The standard SCIM PATCH operation does not accept a simple flat JSON object of the fields you want to change. Instead, it requires an array of operations specifying the path, the operation type (replace, add, remove), and the value. For example, [{ "op": "replace", "path": "active", "value": false }]. LLMs struggle immensely to generate these operation arrays correctly from scratch. Truto's integration abstracts this complexity via tools like lattice_scim_users_partial_update, providing a flatter schema that the proxy API then translates into the correct SCIM format.

Generating the Lattice SCIM MCP Server

Truto's MCP servers feature turns any connected integration into an MCP-compatible tool server dynamically. Rather than hand-coding tool definitions, Truto generates them from the integration's underlying resources and documentation schemas. Each server is scoped to a single connected tenant account and secured with a cryptographic token.

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

Method 1: Via the Truto UI

For ad-hoc agent workflows or local Claude Desktop usage, generating the server through the dashboard is the fastest path.

1. Navigate to the Integrated Accounts page in your Truto dashboard.
2. Select your connected Lattice SCIM account.
3. Click the MCP Servers tab.
4. Click Create MCP Server.
5. Select your desired configuration (e.g., naming the server, filtering for specific tags or read-only methods).
6. Copy the generated MCP server URL. It will look like https://api.truto.one/mcp/a1b2c3d4...

Method 2: Via the Truto API

For production multi-agent architectures, you will want to generate MCP servers programmatically on behalf of your users.

To create an MCP server, make a POST request to the /integrated-account/:id/mcp endpoint.

curl -X POST https://api.truto.one/admin/integrated-accounts/{integrated_account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Lattice SCIM Provisioning Server",
    "config": {
      "methods": ["read", "write"],
      "require_api_token_auth": false
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

The API validates that the Lattice SCIM integration has documented tools available, generates a secure hashed token stored in edge infrastructure, and returns a ready-to-use URL.

{
  "id": "mcp_srv_8f92j",
  "name": "Lattice SCIM Provisioning Server",
  "config": {
    "methods": ["read", "write"],
    "require_api_token_auth": false
  },
  "expires_at": "2026-12-31T23:59:59Z",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890"
}

Connecting the MCP Server to Claude

Once you have the Truto MCP URL, connecting it to Claude requires zero additional infrastructure. You can connect it via the Claude UI or via a local configuration file for the Claude Desktop application.

Method A: Via the Claude UI (Enterprise / Web)

1. Open your Claude workspace settings.
2. Navigate to Integrations or Connectors.
3. Click Add MCP Server.
4. Paste the Truto MCP URL (https://api.truto.one/mcp/...) and save.

Claude will immediately perform a JSON-RPC handshake (initialize), discover the generated Lattice tools, and make them available in your chat interface.

Method B: Via the Claude Desktop Config File

For local development using Claude Desktop, you must update your claude_desktop_config.json file. Because Truto provides a remote SSE/HTTP endpoint, you use the official MCP server-sse wrapper to bridge the local standard output to Truto's remote URL.

Add the following to your configuration file (located at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

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

Restart Claude Desktop. The Lattice SCIM tools are now directly accessible via the paperclip icon in your chat window.

Security and Access Control

Exposing an HR directory to an AI agent requires strict guardrails. Truto provides four critical security controls for MCP servers:

• Method Filtering: You can restrict an MCP server to read-only operations. By setting config.methods: ["read"], Truto will only generate tools for get and list operations, ensuring the LLM cannot accidentally delete or modify user records.
• Tag Filtering: You can group tools by tags. If you only want the agent to access core schema definitions but not actual user data, you can filter by specific integration resource tags during server creation.
• Additional Authentication (require_api_token_auth): By default, possessing the MCP URL grants access. By enabling this flag, the calling client must also pass a valid Truto API token in the Authorization header, adding a second layer of defense against leaked URLs.
• Automatic Expiration (expires_at): You can assign a strict time-to-live (TTL) to an MCP server. Once the timestamp passes, background cleanup systems automatically purge the token from edge storage, instantly revoking the AI agent's access.

Hero Tools for Lattice SCIM Automation

Truto dynamically generates specific, granular tools based on the Lattice SCIM integration schema. Here are the highest-leverage tools available for your agent.

list_all_lattice_scim_users

Retrieves a list of Lattice SCIM users, optionally accepting standard SCIM filter expressions. This is the primary tool an agent uses to find a user's specific SCIM ID based on their email or name before executing updates.

"Search the Lattice directory for the user with the email 'sarah.connor@cyberdyne.com' and tell me their current department and active status."

create_a_lattice_scim_user

Provisions a new user in the Lattice platform. The LLM must provide the userName (which typically acts as the work email) and can populate core identity attributes like name, title, and timezone.

"Provision a new Lattice SCIM account for John Smith. His username is jsmith@company.com, his title is 'Senior Engineer', and his timezone is America/Los_Angeles."

get_single_lattice_scim_user_by_id

Fetches the complete, fully expanded user resource for a specific ID. This returns the core SCIM schema as well as any enterprise or Lattice-specific extension attributes, which is critical for deep audits.

"Fetch the complete Lattice SCIM profile for user ID 8f92j-1928k. I need to see their enterprise extension data, specifically who their listed manager is."

update_a_lattice_scim_user_by_id

Performs a full replacement of a user record via a standard HTTP PUT. The agent must provide the entire user object payload, as any omitted fields may be overwritten or cleared by the upstream provider.

"Update the SCIM record for user ID 12345. Keep all existing information the same, but change their title to 'Director of Operations' and update their department to 'Management'."

lattice_scim_users_partial_update

Performs a partial update without requiring the LLM to write complex SCIM PATCH operation arrays. It exposes flat fields like active, name, title, and department. This is the safest and most reliable tool for deactivating a departing employee.

"Deactivate the Lattice user account for ID 98765 immediately. Set their active status to false and clear their manager field."

list_all_lattice_scim_schemas

Retrieves the SCIM schema definitions available in the connected tenant. Agents use this tool to introspect the API - learning exactly which custom attributes exist before attempting to write data to them.

"List all the available SCIM schemas in our Lattice environment. Tell me what custom attributes exist in the enterprise extension schema."

To view the complete inventory of available tools, query parameters, and JSON schemas, visit the Lattice SCIM integration page.

Workflows in Action

Let us look at how Claude uses these tools to execute real-world HR and IT operations workflows.

Scenario 1: Orchestrating an Employee Offboarding

When an employee leaves, IT and HR need to ensure access to performance management systems is revoked immediately to maintain compliance. An IT administrator can ask Claude to handle the entire deprovisioning process.

"We need to offboard Marcus Johnson (mjohnson@company.com). Please find his Lattice account and deactivate it immediately."

Step-by-step Execution:

1. Claude calls list_all_lattice_scim_users passing filter="userName eq 'mjohnson@company.com'" to resolve Marcus's internal SCIM ID.
2. Truto's MCP router parses the request, executes the proxy API call to Lattice, and returns the user object containing id: "user_88392".
3. Claude reads the ID and calls lattice_scim_users_partial_update, passing id="user_88392" and active=false.
4. Claude confirms to the user: "I have successfully located Marcus Johnson's Lattice account and deactivated it."

sequenceDiagram
    participant Admin as IT Admin
    participant Claude as Claude
    participant Truto as Truto MCP Server
    participant Lattice as Lattice SCIM

    Admin->>Claude: "Deactivate mjohnson@company.com"
    Claude->>Truto: call list_all_lattice_scim_users (filter: userName eq ...)
    Truto->>Lattice: GET /Users?filter=...
    Lattice-->>Truto: Return User ID: user_88392
    Truto-->>Claude: Tool Result (JSON)
    Claude->>Truto: call lattice_scim_users_partial_update (id: user_88392, active: false)
    Truto->>Lattice: PATCH /Users/user_88392
    Lattice-->>Truto: 200 OK
    Truto-->>Claude: Tool Result (Success)
    Claude-->>Admin: "Account successfully deactivated."

Scenario 2: Synchronizing Role and Department Changes

When a team reorganizes, HR operations staff often have to update dozens of records. Claude can automate this by looking up current state data and applying specific structural updates.

"Sarah Lee (slee@company.com) has been promoted. Update her Lattice profile title to 'VP of Engineering' and change her department to 'Executive Leadership'. Before you update it, check her current manager's ID."

Step-by-step Execution:

1. Claude calls list_all_lattice_scim_users with the email filter to find Sarah's SCIM ID and current record.
2. Claude extracts her current manager ID from the returned enterprise extension schema.
3. Claude calls lattice_scim_users_partial_update, passing her ID, title="VP of Engineering", and department="Executive Leadership".
4. Claude informs the user of the successful promotion update and reports who her current manager is listed as in the system.

Rate Limits and Error Handling

When an AI agent is iterating through employee directories, it can quickly generate significant API volume. It is critical to understand how the integration layer handles downstream rate limits.

Truto does not automatically retry, throttle, or apply backoff logic when an upstream API returns a rate limit error. If the Lattice SCIM API rejects a request with an HTTP 429 Too Many Requests status, Truto passes that 429 error directly back to the calling client (the MCP client).

To aid the caller in handling these limits, Truto normalizes the upstream rate limit information into standardized HTTP headers following the IETF draft specification: ratelimit-limit, ratelimit-remaining, and ratelimit-reset. It is the responsibility of the calling application or the AI agent framework to read these headers, pause execution, and implement appropriate retry and backoff mechanisms before invoking the tool again.

Strategic Wrap-Up

Connecting Lattice SCIM to Claude transforms identity and access management from a series of manual clicks into a conversational, automated workflow. By utilizing a managed MCP server via Truto, engineering teams bypass the grueling work of mapping SCIM schemas, wrestling with PATCH payload arrays, and maintaining OAuth or API key lifecycles. Instead, your AI agents get immediate, secure, and schema-accurate access to read and write directory data exactly when they need it.