Connect O'Reilly to ChatGPT: Automate SCIM User Lifecycle

If you need to connect O'Reilly to ChatGPT to automate user lifecycle management, provision SCIM accounts, or audit license assignments, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between ChatGPT's tool calls and O'Reilly's SCIM REST API. You can either build and maintain this custom infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL.

If your team uses Claude, check out our guide on connecting O'Reilly to Claude or explore our broader architectural overview on connecting O'Reilly to AI Agents.

Giving a Large Language Model (LLM) read and write access to a vendor's SCIM directory is a massive engineering challenge. You have to handle complex SCIM filtering syntaxes, strict schema validation, and intricate partial update operations. Every time you need to expose a new endpoint, your custom server code must be updated, redeployed, and tested.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for O'Reilly, connect it natively to ChatGPT, and execute complex IT provisioning workflows using natural language.

Stop writing boilerplate API integration code. Let Truto generate secure, managed MCP servers for your AI agents in seconds. :::

The Engineering Reality of the O'Reilly 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, implementing it against strict enterprise SCIM implementations like O'Reilly's is exceptionally painful.

If you decide to build a custom MCP server for O'Reilly, you own the entire API lifecycle. Here are the specific integration challenges that break standard REST assumptions when working with O'Reilly:

SCIM PATCH vs. PUT Complexities

O'Reilly enforces strict SCIM 2.0 compliance, which means updates are highly opinionated. If an LLM needs to update a user's department, a standard PUT request will overwrite the entire user object. If the LLM omits the user's name or external ID in the PUT payload, those fields are erased. To avoid catastrophic data loss, you must force the LLM to use SCIM PATCH operations. However, O'Reilly's implementation only supports add and replace operations for partial updates - it explicitly rejects remove operations. Your custom MCP server has to validate and translate the LLM's intent into this exact syntax.

Hard Deletes vs. Soft Deactivations

In O'Reilly, invoking a DELETE operation on a user is irreversible. The user and their historical data are permanently removed. In most enterprise environments, offboarding requires a soft delete - retaining the data but revoking access. To achieve this, the LLM must not call the delete endpoint. Instead, it must execute a partial update, setting the active attribute to false. Teaching an LLM this operational nuance requires carefully engineered tool descriptions and schema validation constraints.

Raw Rate Limit Propagation

O'Reilly applies strict rate limits to SCIM operations. When you hit these thresholds, O'Reilly returns an HTTP 429 Too Many Requests error. Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream O'Reilly API returns a 429, Truto passes that error directly back to the caller. Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification. This means your MCP client or the LLM agent itself is entirely responsible for detecting the 429, reading the reset headers, and applying its own retry or backoff logic.

The Managed MCP Architecture

Instead of forcing your engineering team to build JSON-RPC handlers and schema validation layers from scratch, Truto dynamically derives O'Reilly tools from existing configuration resources and documentation records.

Here is how the architecture handles O'Reilly SCIM requests:

sequenceDiagram
  participant ChatGPT as ChatGPT Client
  participant TrutoRouter as Truto MCP Router
  participant TrutoAPI as Truto Proxy API
  participant OReilly as "Upstream API (O'Reilly)"

  ChatGPT->>TrutoRouter: tools/call (update_a_o_reilly_scim_user_by_id)
  Note over TrutoRouter: Validates token & extracts flat arguments
  TrutoRouter->>TrutoRouter: getPropertiesBySchema()
  Note over TrutoRouter: Splits args into path, query, and SCIM body
  TrutoRouter->>TrutoAPI: Forward normalized request
  TrutoAPI->>OReilly: HTTP PATCH /scim/v2/Users/{id}
  
  alt Success
    OReilly-->>TrutoAPI: HTTP 200 OK
    TrutoAPI-->>TrutoRouter: Parsed SCIM User Resource
    TrutoRouter-->>ChatGPT: JSON-RPC Result
  else Rate Limit Exceeded
    OReilly-->>TrutoAPI: HTTP 429 Too Many Requests
    Note over TrutoAPI: Normalizes IETF ratelimit headers
    TrutoAPI-->>TrutoRouter: 429 Error Response
    TrutoRouter-->>ChatGPT: JSON-RPC Error (No backoff applied)
  end

The key design insight is that tool generation is dynamic and documentation-driven. Rather than hand-coding tool definitions, Truto derives them from the O'Reilly integration's resource definitions. A tool only appears in the MCP server if it has a corresponding documentation entry - this acts as a quality gate to ensure only well-documented SCIM endpoints are exposed to ChatGPT.

Step 1: Create the O'Reilly MCP Server

Truto scopes each MCP server to a single integrated account (a connected instance of O'Reilly for a specific tenant). The server URL contains a cryptographic token that encodes the account, allowed tools, and expiration. You can generate this server via the UI or programmatically via the API.

Method A: Via the Truto UI

1. Navigate to the integrated account page for the O'Reilly connection in your Truto dashboard.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration (e.g., allow only read and write methods, set an optional expiration).
5. Click Generate and copy the provided MCP server URL.

Method B: Via the API

For teams automating infrastructure, you can generate the server directly via a POST request. This validates that the O'Reilly integration has tools available, generates a secure token stored in Cloudflare KV, and returns the endpoint.

curl -X POST "https://api.truto.one/integrated-account/<O_REILLY_ACCOUNT_ID>/mcp" \
  -H "Authorization: Bearer <YOUR_TRUTO_API_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "OReilly SCIM Automation Server",
    "config": {
      "methods": ["read", "write", "custom"]
    }
  }'

The response contains the secure URL you will feed into ChatGPT:

{
  "id": "abc-123-def",
  "name": "OReilly SCIM Automation Server",
  "config": { "methods": ["read", "write", "custom"] },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890"
}

Step 2: Connect the MCP Server to ChatGPT

Once you have your Truto MCP URL, providing it to ChatGPT requires zero custom code. The URL itself encodes all authentication and routing context necessary for the session.

Method A: Via the ChatGPT UI

1. Open ChatGPT and navigate to Settings -> Connectors -> Add.
2. In the configuration modal, name your connection (e.g., "O'Reilly SCIM").
3. Paste the Truto MCP server URL (https://api.truto.one/mcp/<TOKEN>).
4. Click Add.

ChatGPT will immediately perform the MCP initialize handshake, discover the O'Reilly SCIM tools, and make them available in your session.

Method B: Via Manual Config File

If you are running a local agent, Cursor, or Claude Desktop alongside ChatGPT orchestration, you can mount the server via a standard JSON configuration using the official SSE transport utility.

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

O'Reilly SCIM Hero Tools for ChatGPT

Truto maps the complete O'Reilly SCIM surface area into discrete, documented tools. Below are the highest-leverage tools available for your AI agents to automate user lifecycles.

list_all_o_reilly_scim_users

This tool retrieves a list of SCIM users. It supports pagination and SCIM filter expressions on attributes like userName, name.givenName, and active. It automatically instructs the LLM to pass pagination cursors unchanged.

"Audit the O'Reilly directory. Find all users where the active status is true, but their primary email domain is not our corporate domain. Return a list of their external IDs."

create_a_o_reilly_scim_user

Provisions a brand new user in the O'Reilly platform. The tool enforces the required JSON schema, ensuring the LLM passes mandatory fields like userName, name, and emails.

"We have a new hire starting today. Provision an O'Reilly account for Jane Doe with the username jane.doe@company.com and set her externalId to her employee ID of 89332."

get_single_o_reilly_scim_user_by_id

Fetches the complete SCIM representation of a specific user. This is critical for context gathering before executing a partial update or verifying a provisioning task.

"Retrieve the full O'Reilly SCIM profile for user ID 102938. What is their current active status, and what primary email is registered to the account?"

o_reilly_scim_users_partial_update

Executes a SCIM PATCH operation to update specific attributes without overwriting the entire user record. O'Reilly restricts this to add and replace operations.

"Update the O'Reilly user ID 102938. Replace their familyName with 'Smith-Jones' and update their displayName to reflect the change. Do not modify any other fields."

update_a_o_reilly_scim_user_by_id

Executes a SCIM PUT operation. This replaces the entire user attribute tree. You must provide the full user record as if provisioning for the first time - missing fields will be erased.

"I am providing a completely new JSON payload for user ID 102938 synced from our HRIS. Replace the entire O'Reilly SCIM profile with this new payload."

delete_a_o_reilly_scim_user_by_id

Executes a hard delete on a provisioned user. This action is irreversible. For standard offboarding, the agent should use the partial update tool to set the user to inactive instead.

"The contractor account with ID 99483 was created by mistake and contains no learning history. Perform a hard delete on this user ID to permanently remove the record from O'Reilly."

To view the complete inventory of available endpoints and their exact JSON schemas, visit the O'Reilly integration page.

Workflows in Action

Exposing individual endpoints is just the baseline. The real power of connecting O'Reilly to ChatGPT via MCP is allowing the LLM to string these tools together into autonomous workflows.

Scenario 1: The Soft-Offboarding Automation

When an employee leaves, IT administrators rarely want to hard-delete the learning record. They want to revoke access by suspending the account.

"Mark the employee with the email 'jason.bourne@company.com' as deactivated in O'Reilly."

Step-by-step execution:

1. The agent calls list_all_o_reilly_scim_users passing a SCIM filter userName eq "jason.bourne@company.com".
2. It extracts the id from the resulting payload.
3. It calls o_reilly_scim_users_partial_update with the extracted id, issuing a SCIM patch replace operation to set active: false.
4. ChatGPT responds: "Jason Bourne's O'Reilly account has been successfully deactivated. His historical learning data remains intact."

flowchart TD
  A["User Prompt<br>Deactivate Jason"] --> B
  B["Tool: list_all_o_reilly_scim_users<br>Filter by Email"] --> C
  C["Extract User ID"] --> D
  D["Tool: o_reilly_scim_users_partial_update<br>Set active: false"] --> E
  E["Return Confirmation<br>to User"]

Scenario 2: License Auditing and Correction

IT teams frequently need to audit systems for improperly formatted usernames or external identities that drift from the primary HRIS truth.

"Audit the O'Reilly directory. Find any active users missing an externalId, generate a list of their emails, and output a CSV format I can send to HR."

Step-by-step execution:

1. The agent calls list_all_o_reilly_scim_users with pagination logic (looping with next_cursor if necessary).
2. The LLM processes the returned JSON array in its context window.
3. It filters the objects logically, finding active users where the externalId is null or missing.
4. It formats the output as a clean CSV block directly in the chat interface.

Security and Access Control

Connecting an LLM to your primary SCIM directory requires rigorous security controls. Truto's MCP servers provide several layers of enforcement that keep your O'Reilly tenant secure:

• Method Filtering: Limit the MCP server to specific HTTP methods. You can configure a server with config: { methods: ["read"] } to ensure ChatGPT can only run audits and lookups, physically preventing it from provisioning or deleting O'Reilly users.
• Tag Filtering: Restrict tool access by integration tags. If you only want an agent to manage schemas instead of users, tag filtering enforces that boundary at the documentation level.
• Expiration (TTL): Pass an expires_at ISO datetime when creating the server. Truto uses Cloudflare KV and Durable Objects to automatically clean up the database record and invalidate the URL the moment the time-to-live expires.
• Secondary Authentication: Enable the require_api_token_auth flag. Even if a bad actor intercepts the MCP server URL, they cannot execute tools without also passing a valid Truto API token in the authorization header.

Strategic Wrap-up

Building a custom integration between ChatGPT and O'Reilly means signing up to maintain SCIM parsers, write exponential backoff loops for 429 errors, and continually update JSON-RPC mappings. By utilizing Truto's managed MCP architecture, you offload the entire protocol layer.

Your engineers can focus on designing the system prompts and guardrails that govern the AI agent, while Truto ensures the underlying API calls to O'Reilly are authenticated, normalized, and executed flawlessly.