Connect UKG Ready to Claude: Streamline Time, PTO, and Scheduling

If your team needs to connect UKG Ready to Claude to automate time tracking, synchronize payroll processing, or manage complex shift scheduling, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's natural language tool calls and UKG Ready's highly structured REST APIs. You can either build, host, 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 sibling guide on connecting UKG Ready to ChatGPT, or explore our broader architectural overview on connecting UKG Ready to AI Agents.

Giving a Large Language Model (LLM) read and write access to a sprawling Human Capital Management (HCM) ecosystem like UKG Ready is an engineering challenge. You have to handle credential lifecycles, map massive JSON schemas to MCP tool definitions, and deal with UKG Ready's strict subsystem dependencies. Every time an endpoint shifts or a module is reconfigured, 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 UKG Ready, connect it natively to Claude Desktop, and execute complex HCM workflows using natural language.

The Engineering Reality of the UKG Ready 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 specialized enterprise APIs is painful. UKG Ready is built to manage complex payroll awards, compliance-heavy PTO rules, and intricate workforce schedules. Its API reflects that deep operational complexity.

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

Subsystem-Dependent Endpoints and Feature Flags UKG Ready is heavily modular. Endpoints do not blindly accept requests; they check if the corresponding subsystem (HR, TLM, PR, or SCHEDULE) is enabled for the specific company environment. For example, if you attempt to interact with the Advanced Scheduler API (/company/schedules), but the company only licenses the Time & Labor (TLM) module, the API will reject the request. An LLM has no context on a tenant's license tier. You must build an abstraction layer that handles these silent failures and accurately exposes only the capabilities a specific tenant can access.

Asynchronous Payroll Processing Pipelines Payroll operations in UKG Ready are not synchronous CRUD operations. When you tell UKG Ready to finalize a payroll via ukg_ready_company_payrolls_finalize, you do not get a completed payroll object back. You get a jobs array containing task tracking IDs. The LLM must be explicitly instructed on how to poll these job IDs to confirm that the payroll run succeeded before it moves on to subsequent steps like delivering pay statements. If your custom MCP server doesn't orchestrate this state tracking, Claude will assume the action failed or hallucinate the result.

Fragmented Data Models Across API Versions Extracting a complete employee profile requires navigating significant fragmentation. UKG Ready relies heavily on its V1 endpoints for some demographic data while pushing developers toward its V2 endpoints for core employee records (/v2/companies/employees). To get an employee's full context—core identity, accrual balances, current schedule, and direct deposit info—you must orchestrate requests across four or five distinct relational endpoints. Exposing these raw endpoints directly to Claude often results in context window bloat and excessive LLM reasoning cycles.

Handling UKG Ready API Rate Limits

When building AI integrations, rate limits are a critical failure point. LLMs process data quickly and can easily overwhelm upstream APIs with parallel tool calls.

Truto does not retry, throttle, or apply backoff on rate limit errors. When UKG Ready returns an HTTP 429 Too Many Requests, Truto passes that error directly back to the caller. However, Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification.

Because Truto does not absorb rate limits, your MCP client or AI framework is responsible for detecting the 429 error in the tool call response, reading the standardized headers, and implementing its own retry or backoff logic before prompting the LLM to try again.

How to Create the UKG Ready MCP Server

Truto automatically derives MCP tools from a combination of the integration's defined resources and its documentation records. A tool only appears in the MCP server if it has a corresponding documentation entry. This documentation-driven approach acts as a quality gate, ensuring that Claude only sees well-described endpoints with strictly typed JSON schemas for queries and bodies.

You can generate an MCP server for a connected UKG Ready account using either the Truto UI or the API.

Method 1: Via the Truto UI

If you prefer a visual setup, you can generate the server directly from your dashboard:

1. Log in to Truto and navigate to the Integrated Accounts page.
2. Select your connected UKG Ready account.
3. Click the MCP Servers tab.
4. Click Create MCP Server.
5. Configure the server (set a name, apply method or tag filters, or set an expiration date).
6. Click Save and copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3d4e5f6...).

Method 2: Via the Truto API

For teams dynamically provisioning AI agents for their users, you can generate MCP servers programmatically.

Make a POST request to the /integrated-account/:id/mcp endpoint. This validates that the UKG Ready integration has tools available, generates a secure, hashed token stored in Cloudflare KV, and returns a ready-to-use URL.

curl -X POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "UKG Ready Scheduling & PTO Agent",
    "config": {
      "methods": ["read", "write"],
      "tags": ["time_and_labor", "scheduling"]
    }
  }'

The response contains the secure URL you will use to connect your client:

{
  "id": "mcp_a1b2c3d4",
  "name": "UKG Ready Scheduling & PTO Agent",
  "config": { 
    "methods": ["read", "write"],
    "tags": ["time_and_labor", "scheduling"]
  },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890"
}

Connecting the MCP Server to Claude

Because Truto's MCP servers are entirely self-contained within the generated URL, connecting them to an AI client requires zero additional authentication logic. The URL contains a cryptographic token that securely maps to the specific UKG Ready tenant.

Method A: Via the Claude UI

If you are using Claude's enterprise or desktop interfaces that support direct UI configuration (or ChatGPT's UI):

1. In Claude, navigate to Settings → Integrations → Add MCP Server. (Note: If you are using ChatGPT, the path is Settings → Apps → Advanced settings → Developer mode → Add Custom Connector).
2. Provide a name, like "UKG Ready Integration".
3. Paste the Truto MCP URL (https://api.truto.one/mcp/...).
4. Click Add or Save.

Claude will immediately send an initialize JSON-RPC request to the URL, discover the available UKG Ready tools, and make them available in your chat context.

Method B: Via Claude Desktop Config File

For developers running Claude Desktop locally and testing agentic workflows, you can wire up the server using the claude_desktop_config.json file. Truto's MCP endpoints use the standard Server-Sent Events (SSE) transport over HTTP POST.

You can use the official @modelcontextprotocol/server-sse package to proxy the connection.

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

Restart Claude Desktop. The application will execute the npx command, establish the SSE connection, and parse the tool definitions dynamically derived from UKG Ready's config.resources.

Hero Tools for UKG Ready

Truto normalizes the sprawling UKG Ready API into distinct, AI-readable tools. The schema generation engine automatically injects property descriptions, handles cursor pagination instructions (like limit and next_cursor), and enforces required fields.

Here are 6 high-leverage tools available for UKG Ready.

1. get_single_ukg_ready_employee_by_id

Retrieves the core employee record, including their internal ID, account status, full name, and external identification numbers. This is the foundational tool for establishing identity context before performing time or scheduling operations.

"Get the core employee file for the employee with ID 449210. I need to know their current account status before we process their timesheet."

2. list_all_ukg_ready_employee_time_entries

Fetches time entries for a specified employee within a given date range (maximum 31 days). This exposes exactly when an employee punched in or out and is critical for auditing payroll anomalies.

"Fetch all time entries for employee 449210 from October 1st to October 15th. Summarize any days where they clocked more than 8 hours."

3. ukg_ready_employee_ptorequests_create_v_2

Creates a new time off request (FullDay, Partial, Multiple, or Dynamic). The strict JSON schema for this tool ensures the LLM provides the correct request types and date arrays required by UKG's V2 endpoints.

"Submit a full day PTO request for employee 449210 for next Friday. Use the 'FullDay' request type and associate it with their standard vacation timeoff ID."

4. list_all_ukg_ready_company_schedules

Retrieves schedules filtered by a date range. This endpoint requires the Advanced Scheduler (__SCHEDULE__) subsystem to be enabled on the tenant. It allows the agent to view overall coverage and shift allocations.

"List the company schedule for the week starting November 6th. I need to see if we have enough coverage on the warehouse floor."

5. ukg_ready_employee_schedules_bulk_update

Updates an employee's schedule for a specified date range, effectively replacing existing schedule data in that range. This allows an AI agent to react to call-outs and redistribute shifts.

"Update the schedule for employee 449210 to cover the morning shift from 08:00 to 16:00 on November 7th. Override their previous assignment."

6. list_all_ukg_ready_employee_accrual_balances_v_2

Fetches an employee's accrual balances (vacation, sick time, floaters) as of a specific date. UKG formats these hours in HH:MM (or HH.DD), and the tool's schema describes this explicitly so Claude knows how to interpret the math.

"Check the current accrual balances for employee 449210. Do they have enough PTO remaining to cover a 3-day absence?"

To view the full inventory of UKG Ready tools, required parameters, and JSON schemas, visit the Truto UKG Ready Integration Page.

Workflows in Action

Connecting an LLM to UKG Ready transforms point-to-point API scripts into autonomous agentic workflows. Here is how Claude orchestrates multi-step processes using Truto's MCP tools.

Scenario 1: PTO Validation and Submission

An employee asks an AI HR assistant via Slack to take next Thursday off. The agent must verify identity, check balances, and submit the request seamlessly.

"I'm feeling burnt out. Can you put in a request for me to take next Thursday off?"

1. get_single_ukg_ready_employee_by_id: Claude queries the authenticated user's ID to retrieve their core UKG profile and verify their active status.
2. list_all_ukg_ready_employee_accrual_balances_v_2: Claude fetches the employee's current PTO balance, reading the HH:MM format to ensure they have at least 8 hours available.
3. ukg_ready_employee_ptorequests_create_v_2: Claude constructs the strictly typed JSON body (setting request type to FullDay for the specified date) and executes the creation tool. It returns a success message to the employee.

Scenario 2: Payroll Anomaly Detection

A payroll administrator asks the agent to find and summarize overtime risks before initiating the final payroll run.

"Look at the time entries for the warehouse team over the last 14 days. Flag anyone who is approaching overtime so we can adjust their schedule before payroll closes."

1. list_all_ukg_ready_employees: Claude retrieves the list of active employees belonging to the warehouse cost center.
2. list_all_ukg_ready_employee_time_entries: Claude iteratively calls this tool for the identified employees, passing the past 14 days as the start_date and end_date parameters.
3. list_all_ukg_ready_company_schedules: Claude pulls the upcoming schedule for the flagged employees to identify which future shifts can be trimmed to avoid hitting the overtime threshold.

sequenceDiagram
    participant User as Payroll Admin
    participant Claude as Claude Desktop
    participant Truto as Truto MCP Server
    participant UKG as UKG Ready API

    User->>Claude: "Check warehouse team time entries for OT risks."
    Claude->>Truto: call tool: list_all_ukg_ready_employees
    Truto->>UKG: GET /v2/companies/{cid}/employees
    UKG-->>Truto: Employee list (JSON)
    Truto-->>Claude: Employee IDs
    
    Claude->>Truto: call tool: list_all_ukg_ready_employee_time_entries
    Truto->>UKG: GET /timesheets/entries (14 days)
    UKG-->>Truto: Time entry records
    Truto-->>Claude: Formatted time data
    
    Claude->>User: "Found 3 employees nearing OT limits. Here is the breakdown..."

Scenario 3: Shift Redistribution

A manager needs to cover a shift for an employee who just called in sick.

"Sarah called in sick tomorrow. Remove her from the schedule and assign her shift to John."

1. ukg_ready_employee_schedules_bulk_delete: Claude targets Sarah's employee ID for tomorrow's date, executing a deletion of her scheduled shift block.
2. ukg_ready_employee_ptorequests_create_v_2: Claude submits a sick leave request on Sarah's behalf to ensure her absence is documented and paid correctly.
3. ukg_ready_employee_schedules_bulk_update: Claude executes an update on John's schedule, injecting the specific shift parameters (time, role, cost center) previously assigned to Sarah.

Security and Access Control

Exposing an HCM system to an AI model requires strict governance. Truto's MCP implementation allows you to tightly scope what the LLM can see and do at the server configuration level:

• Method Filtering (methods): Restrict the MCP server to only perform read operations (like get and list). If you want an agent that can only audit schedules but never alter them, filter out all write methods. Truto enforces this during dynamic tool generation.
• Tag Filtering (tags): Restrict the exposed tools by functional domain. You can create an MCP server that only sees tools tagged with time_and_labor, completely hiding the payroll or recruiting endpoints from the model.
• Additional Authentication (require_api_token_auth): By default, possession of the MCP token URL grants access. Setting this flag requires the MCP client to also pass a valid Truto API token in the Authorization header, adding a second layer of identity verification.
• Temporary Access (expires_at): Create ephemeral MCP servers for temporary workloads. Set an ISO timestamp, and Truto will automatically destroy the server, its KV storage, and the associated cleanup alarms when the time expires.

Moving to Autonomous HCM Workflows

Integrating UKG Ready has traditionally meant building rigid, hard-coded syncs that break the moment a tenant's subsystem configuration changes or an async payroll job times out.

By routing Claude through Truto's MCP server, you offload the complexity of pagination, authentication, and endpoint routing. The LLM simply reads the dynamically generated tool descriptions, understands the required parameters, and executes the workflows natively. Your engineering team stops maintaining bespoke integration scripts and starts building autonomous, reasoning agents that can handle the full lifecycle of time, PTO, and workforce scheduling.