Connect ServiceNow SCIM to Claude: Sync Departments and Locations

If your team needs to connect ServiceNow SCIM to Claude to automate user provisioning, audit access controls, or sync physical locations with identity records, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's function-calling capabilities and ServiceNow's specialized identity management APIs. You can either construct and maintain this infrastructure in-house, 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-servicenow-scim-to-chatgpt-manage-identity-and-group-sync/ or explore our broader architectural overview on /connect-servicenow-scim-to-ai-agents-automate-identity-lifecycle/.

Giving a Large Language Model (LLM) read and write access to an enterprise IT Service Management (ITSM) platform like ServiceNow is an engineering challenge. Identity data is highly sensitive. You must handle complex OAuth 2.0 flows, map deeply nested SCIM (System for Cross-domain Identity Management) schemas to MCP tool definitions, and deal with ServiceNow's strict rate limits. Every time a new custom attribute is added to your ServiceNow instance, 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 ServiceNow SCIM, connect it natively to Claude Desktop or custom agents, and execute complex identity and organizational workflows using natural language.

The Engineering Reality of the ServiceNow 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 2.0, the reality of implementing it against a massive enterprise system like ServiceNow is painful. ServiceNow SCIM is designed to adhere to the RFC 7644 and RFC 7643 specifications, but enterprise realities introduce heavy customization.

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

Strict RFC 7644 PATCH Operations Unlike typical REST APIs where you might send a simple JSON object to update a record ({ "title": "Senior Engineer" }), the SCIM specification requires strict PATCH syntax for partial updates. You must construct an array of Operations with specific op (add, remove, replace), path, and value parameters. An LLM natively struggles with this strict formatting unless the tool schemas are perfectly defined to constrain its output. An auto-generated MCP server exposes tools like service_now_scim_users_partial_update with precise JSON Schema definitions that explicitly instruct the LLM on how to construct these complex payloads.

Schema Extensions and Custom Attributes Enterprise ServiceNow environments rarely rely solely on the core SCIM user schema. They use extension schemas (e.g., urn:ietf:params:scim:schemas:custom:servicenow:2.0:User) to store department codes, cost center IDs, and proprietary HR identifiers. Hardcoding these into a custom MCP server means your agent will break the moment the IT department adds a new required attribute. A managed MCP server dynamically reads the instance's capabilities and schemas, ensuring the LLM is always aware of the exact data shape required for that specific environment.

Transparent Rate Limiting and Backoff ServiceNow enforces strict concurrency and API rate limits to protect instance performance. When building AI agents, a common architectural mistake is attempting to hide these limits inside the integration layer. Truto takes a transparent approach: Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream ServiceNow API returns an HTTP 429 Too Many Requests, Truto passes that error directly to the caller.

However, Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. The caller - whether that is your LangGraph orchestrator or Claude's internal loop - is responsible for reading these headers and executing the retry or backoff logic. Do not expect your integration layer to absorb rate limits; the agent must be intelligent enough to pause execution.

Generating the Managed MCP Server

To bridge Claude and ServiceNow SCIM without writing your own authentication and JSON-RPC translation layers, you can generate a managed MCP server using Truto. This server is scoped to a single integrated account, meaning the connection is completely isolated and secure.

You can create this server through the visual interface or programmatically via the API.

Method 1: Via the Truto UI

For internal tooling and rapid prototyping, the Truto dashboard provides a point-and-click interface to spin up an MCP server.

1. Navigate to the Integrated Accounts page in your Truto dashboard and select your connected ServiceNow SCIM account.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Define your configuration. You can filter the available tools by methods (e.g., only read operations for a read-only audit agent) or apply specific tags.
5. Click Create and copy the generated MCP server URL (e.g., https://api.truto.one/mcp/abc123xyz). Keep this URL secret; it acts as a cryptographic token that authenticates requests directly to that specific ServiceNow tenant.

Method 2: Via the Truto API

For production workflows where you are programmatically deploying AI agents for your end-users, you will generate the MCP server dynamically via a REST call.

Make a POST request to the /integrated-account/:id/mcp endpoint:

curl -X POST https://api.truto.one/integrated-account/<integrated_account_id>/mcp \
  -H "Authorization: Bearer <YOUR_TRUTO_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "ServiceNow Identity Agent",
    "config": {
      "methods": ["read", "write", "custom"]
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

The API will return a JSON object containing the secure url. Pass this URL to your LLM framework or desktop client.

Connecting the MCP Server to Claude

Once you have your Truto MCP server URL, you must register it with your AI client so the model can discover the ServiceNow SCIM tools via the tools/list initialization phase.

Method A: Via the Claude Desktop UI

If you are using Claude Desktop or an enterprise workspace that supports visual connector management:

1. Open your settings panel.
2. In Claude Desktop, go to Settings > Integrations > Add MCP Server (or in ChatGPT, Settings > Connectors > Add).
3. Name the connection "ServiceNow SCIM".
4. Paste the Truto MCP URL into the Server URL field.
5. Click Add.

The client will instantly send an initialize request to the URL, parse the returned JSON Schema tool definitions, and make them available for natural language prompting.

Method B: Via Manual Configuration File

If you are using Claude Desktop in a developer environment or configuring a custom headless agent, you can mount the server using standard configuration files. You will use the official @modelcontextprotocol/server-sse transport wrapper to handle the Server-Sent Events stream.

Locate your Claude Desktop configuration file (typically claude_desktop_config.json in your AppData or Application Support directory) and add the following JSON block:

{
  "mcpServers": {
    "servicenow_scim": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "--url",
        "https://api.truto.one/mcp/<YOUR_TRUTO_TOKEN>"
      ]
    }
  }
}

Restart Claude Desktop. The tools will now appear as an attached context source in your chat interface.

Hero Tools for Identity and Org Sync

Truto automatically generates highly descriptive tools derived directly from the underlying API schemas. Here are the highest-leverage tools available for ServiceNow SCIM.

list_all_service_now_scim_users

This tool queries the User [sys_user] table via the SCIM protocol. It supports advanced RFC 7644 filter expressions, sorting, and attribute exclusion. This is vital for auditing identity state across the organization.

"Audit the ServiceNow directory and find all active users in the Engineering department. Return a list of their display names and email addresses. Only fetch the id, userName, and emails attributes to save bandwidth."

get_single_service_now_scim_user_by_id

Fetches a comprehensive identity record for a single user by their sys_id. This returns the full SCIM user object including nested metadata, phone numbers, and any custom ServiceNow extension attributes configured in your instance.

"Retrieve the full identity profile for the ServiceNow user with ID '123e4567-e89b-12d3-a456-426614174000'. Check their custom extension attributes to see which cost center they are assigned to."

create_a_service_now_scim_user

Provisions a new user in the User [sys_user] table. The schema guides the LLM to format the payload correctly, distinguishing between core SCIM fields (like userName and name.familyName) and enterprise extension schema values.

"Provision a new ServiceNow SCIM user for 'Jane Doe'. Set her username to 'jane.doe', active status to true, and assign her the primary email 'jane.doe@company.com'."

service_now_scim_users_partial_update

Modifies specific fields of an existing user record using strict SCIM PatchOp payloads. Instead of overwriting the entire user object, this tool allows the agent to safely append data, remove obsolete roles, or replace a specific attribute.

"Update the ServiceNow user with ID '987fcdeb-51a2-43d7-9012-426614174000'. Use a partial update operation to replace their 'title' with 'Lead Architect' and add a new phone number to their profile."

list_all_service_now_scim_departments

Queries the Department [cmn_department] table. This is essential for mapping users to the correct organizational hierarchy during onboarding or reorganization workflows.

"List all available departments in ServiceNow SCIM. Find the exact department ID for 'Product Marketing' so we can assign it to a new hire."

list_all_service_now_scim_locations

Queries the Location [cmn_location] table. When tying physical asset management or hybrid work policies to identity, agents use this tool to validate physical location data.

"Fetch the list of all ServiceNow locations. Identify the location ID for the 'London HQ' building."

create_a_service_now_scim_group

Provisions a new group in the Group [sys_user_group] table. This is the foundation for automating Role-Based Access Control (RBAC) via natural language.

"Create a new ServiceNow SCIM group called 'Data Science - Production Access'. Add a description indicating this group grants read-only access to the production data warehouse."

For the complete inventory of ServiceNow SCIM tools - including cost center synchronization, schema discovery, and configuration operations - review the ServiceNow SCIM integration page.

Workflows in Action

MCP servers transform LLMs from read-only chatbots into active IT service agents. By chaining these tools together, Claude can execute multi-step identity operations that would normally require manual ITSM tickets.

Scenario 1: Autonomous Employee Onboarding

When a new hire joins, IT normally receives a ticket, looks up the correct department and location IDs, creates the user, and assigns them to a baseline access group. Claude can automate this entire sequence.

"We just hired Alex Chen as a Senior Data Engineer based in the London office. Please provision their ServiceNow SCIM account, ensure they are assigned to the correct location and department, and add them to the 'Engineering Baseline' group."

Execution Steps:

1. Claude calls list_all_service_now_scim_departments to search for "Data Engineering" or "Engineering" and retrieves the department ID.
2. Claude calls list_all_service_now_scim_locations to find the exact ID for "London".
3. Claude calls create_a_service_now_scim_user, passing Alex's details along with the mapped department and location IDs.
4. Claude calls list_all_service_now_scim_groups to find the ID for "Engineering Baseline".
5. Claude calls service_now_scim_groups_patch to append Alex's new user ID to the group's members array.

sequenceDiagram
    participant User
    participant Claude as Claude Desktop
    participant Truto as Truto MCP Server
    participant SNOW as ServiceNow SCIM API

    User->>Claude: "Provision Alex Chen in London Engineering..."
    Claude->>Truto: Call list_all_service_now_scim_locations
    Truto->>SNOW: GET /Locations?filter=name eq "London"
    SNOW-->>Truto: Return Location ID
    Truto-->>Claude: Location ID: loc-789
    Claude->>Truto: Call create_a_service_now_scim_user
    Truto->>SNOW: POST /Users (Payload with loc-789)
    SNOW-->>Truto: Return User ID
    Truto-->>Claude: User ID: usr-123
    Claude->>Truto: Call service_now_scim_groups_patch
    Truto->>SNOW: PATCH /Groups/grp-456 (Add Member usr-123)
    SNOW-->>Truto: 200 OK
    Truto-->>Claude: Group updated
    Claude-->>User: "Alex Chen provisioned successfully."

Scenario 2: Reorganization and Title Audits

During a reorg, HR might hand IT a spreadsheet of title changes. Instead of manually clicking through the ServiceNow interface, an IT admin can paste the text to Claude and let the agent handle the SCIM patching.

"Here is a list of title changes for the Q3 reorg: Sarah Jenkins is now 'Director of Sales', Marcus Cole is 'VP of RevOps'. Please update their ServiceNow records. Use partial updates so we don't accidentally overwrite their existing group memberships or extension attributes."

Execution Steps:

1. Claude iterates through the names, calling list_all_service_now_scim_users with a SCIM filter (e.g., filter=userName eq "sjenkins") to retrieve their exact sys_id values.
2. Claude constructs a precise RFC 7644 payload for Sarah.
3. Claude calls service_now_scim_users_partial_update with an Operations array containing {"op": "replace", "path": "title", "value": "Director of Sales"}.
4. Claude repeats the lookup and patch process for Marcus.
5. The agent reports the successful updates back to the user, verifying the exact HTTP 200 responses.

Security and Access Control

Exposing an enterprise identity provider to an AI agent demands strict security constraints. Truto's MCP architecture provides native guardrails so you can safely deploy these tools without risking unauthorized modifications.

• Method Filtering: When generating the MCP server, you can restrict it to specific operations. For a strict auditing agent, set methods: ["read"]. The server will only expose list and get tools, physically preventing the LLM from executing create, update, or delete actions, regardless of the prompt.
• Tag Filtering: Limit the surface area of the API by specifying tags. You could configure the server to only expose resources tagged with locations or departments, hiding sensitive users or groups endpoints entirely.
• Extra Authentication Layers: Enable require_api_token_auth on the server configuration. This forces the client to pass a valid API token in the Authorization header alongside the secure URL, ensuring that possession of the MCP URL alone is not enough to execute tools.
• Automatic Expiration: For temporary contractor access or time-bound automation scripts, set an expires_at timestamp. The distributed key-value store automatically invalidates the token at the exact minute, immediately revoking the LLM's access to the ServiceNow instance.

Rethinking Identity Automation

Connecting ServiceNow SCIM to Claude shifts identity management from a task-based ticketing system to an autonomous, conversation-driven workflow. By leveraging MCP, you eliminate the need to write custom REST wrappers, manage complex OAuth state, or manually format RFC 7644 PATCH operations.

The integration layer is no longer a bottleneck. With your MCP server running securely through Truto, your engineering team can focus on designing better agentic workflows, confident that rate limits, token refreshes, and schema introspection are handled invisibly in the background. Stop fighting API boilerplate and start automating the enterprise.