How to Get Started with a Workday MCP Server
May 5, 2026
If you're trying to give an AI agent access to Workday — to read worker data, retrieve PTO balances, submit time-off requests, or pull org structure — you need a Workday MCP server. The complication: Workday doesn't ship one.
There's no official Workday MCP server. There are three paths that get you to a working setup, and the right one depends on whether you want full control, the fastest hosted option, or one MCP connection that covers Workday plus other integrations your agent will eventually need. This post walks through the prerequisites that apply to all three paths, the trade-offs of each, and how to choose.
The Workday prerequisites apply no matter which path you take
Every Workday MCP path — official or not — starts the same way:
- Create an Integration System User (ISU) in Workday with the security groups required for the data your agent needs (HR, time off, finance, etc.)
- Register an API client under Workday REST: Authorization Code Grant, Bearer token type, redirect URI matching your MCP platform, refresh token timeout (commonly 30 days), and scopes matching your functional areas
- Capture the endpoints — REST base URL, token endpoint, authorization endpoint — for the platform you'll plug them into
The ISU + API client setup is the bulk of the work. Whichever path you pick, this part doesn't go away. For the full Workday OAuth2 walkthrough, see Unified.to's Workday OAuth2/SOAP credentials guide.
Path 1: Build your own MCP server against Workday's APIs
Implement an MCP server (Node/TypeScript or Python) that maps tool calls to Workday REST endpoints. Handle OAuth2 token acquisition and refresh, store tokens encrypted, enforce row-level scoping, and follow the MCP protocol spec for stdin/stdout communication.
When this makes sense: Workday is your only integration, you need deep workflow control, and you have engineering capacity for ongoing maintenance.
What it costs: Workday integration is fundamentally different from modern SaaS APIs. It exposes three API surfaces (SOAP, REST, Reports-as-a-Service), each with different authentication and coverage. The data model is deeply nested and effective-dated. Every customer has a different schema in practice, and Workday ships biannual releases that introduce deprecations. Bi-directional integrations typically take 6–12+ weeks for a B2B SaaS team building directly. Maintenance is continuous, not one-time. For the full breakdown, see Workday API Integration: What Engineers Need to Know.
The MCP layer adds work on top of all that — protocol handling, tool definitions, schema mapping for each Workday object you want to expose.
Path 2: Hosted vendor MCP servers
Several platforms ship Workday MCP servers as a hosted product. The major options:
- Workato — Workday End User MCP server, configured inside Workato's AI Hub. Focused on employee self-service workflows.
- CData — Workday MCP Server with JDBC-style data access. Self-hosted, runs as a Java-based MCP server using CData's JDBC driver.
- Knit — Workday MCP exposed through Knit's Workday integration.
- Merge Agent Handler — Workday Tool Pack registered as an MCP server in Claude Code or other MCP clients.
These platforms hide most of the REST/OAuth plumbing. You configure Workday as an app connection in their UI, capture the MCP URL they generate, and register it in your AI client config.
When this makes sense: You want fast prototyping with minimal auth code, you're comfortable with vendor lock-in for the MCP layer, and Workday is the integration you care about most.
What it costs: You're committing to that vendor's MCP runtime. If you later need ServiceNow, Salesforce, or QuickBooks tools available to the same agent, you're either adding more vendor MCP servers or switching paths. Pricing varies — most are platform subscriptions, not usage-based.
Path 3: A unified MCP server
Unified.to runs an MCP server that connects any Unified integration — Workday included — to MCP-compatible clients (Anthropic, OpenAI, Google Gemini, Cohere, and others). Workday is one of 440+ integrations exposed through the same MCP URL.
The setup:
- Create a Unified.to workspace and get your API key
- Add the Workday integration and authorize against your Workday tenant (Sandbox is available for testing with synthetic data)
- Capture the connection ID for the Workday connection
- Construct the MCP server URL:
${UNIFIED_MCP_URL}/sse?token=${UNIFIED_API_KEY}&connection=${CONNECTION_ID}&dc=us&type=anthropic
- Register the URL in your MCP client config
The token can be passed as a URL parameter or as Authorization: bearer {token}. Region codes are us, eu, or au. The type parameter matches the LLM provider you're using.
Tools exposed for Workday: HRIS Employee, Group, Company, Time Off; ATS Job, Candidate, Interview, Document, Scorecard; LMS Content; Accounting Invoice, Contact; and Passthrough for any provider-specific endpoint not in the unified schema.
When this makes sense: You want one MCP connection that covers Workday plus other integrations, you want every tool call to hit the source API live (no caching, no sync jobs), and you don't want to maintain MCP infrastructure yourself.
What it costs: Pricing is usage-based. Most current LLMs cap available tools per request — Groq at 10, OpenAI at 20, Cohere at 50 — so you'll need to scope tools using the tools or permissions URL parameters when wiring this into an agent.
How to choose
A short decision frame:
- Workday is your only integration and you have engineering capacity for ongoing maintenance → build your own
- Workday is the integration you care about most and you want fast prototyping → hosted vendor MCP
- Workday is one of several integrations your agent will need, and you want real-time data with no infrastructure to maintain → unified MCP
The path that hurts the least at scale is usually the one that doesn't require rebuilding when the second integration shows up. Agents that start with Workday often end up needing ATS, accounting, or messaging integrations soon after.
Whichever path you choose, the Workday prerequisites — ISU, API client registration, OAuth2 setup — apply. That's the work you can't skip.