The short answer
For most tenants today, the practical answer runs through one of two credential models: a Workday Integration System User (ISU) and a registered API client, talking to Workday's REST, RaaS, WQL, or SOAP endpoints through a vendor-built or custom MCP server; or a desktop AI agent that signs in to Workday the way you do and works in it directly, with no API client to register. Workday itself is also now building a first-party route — MCP-based connectors and an agent that builds apps from tools like Claude Code — but it's early access through Workday Extend Professional, with general availability projected for the second half of 2026. Which route to pick depends on one question: what do you need the AI to read, write, or build — and who is accountable for the credentials that make it possible?
This is the practical map: what each route can and can't reach in Workday, what to set up before you connect anything, and where the honest limits are.
The four ways to connect an AI assistant to Workday
Search "Workday MCP server" and you'll find integration vendors' MCP servers — hosted bridges that expose Workday data as tools an AI client can call. A smaller number of teams build their own MCP server against Workday's public APIs. A growing option is a desktop AI agent that signs in to Workday directly and drives it, rather than calling an API at all. And Workday itself has announced a first-party route, currently in early access.
Integration vendors' MCP servers
These are hosted or self-hosted MCP servers that sit between your AI client and Workday. They wrap one or more of Workday's own interfaces — WQL, RaaS (Report-as-a-Service), REST, or SOAP — as callable tools, authenticating with the same Integration System User and API client model any other integration uses. Setup is fast: register the API client once, point the vendor's connector at it, and the tools appear inside Claude or ChatGPT. Check whether each tool reads or writes before you turn it on.
A custom MCP server
If your integration team already has API access patterns worked out, a self-hosted MCP server calling Workday's REST or WQL endpoints directly gives the most control over exactly which fields and operations are exposed, with nothing abstracted away.
A desktop AI agent with its own Workday sign-in
A newer pattern skips the API client model for parts of the job: an AI agent running on your own computer authenticates to Workday the way you do, in a visible browser, and can act on tasks that only exist in the Workday UI — not just the ones exposed through an API.
Workday's own route, in early access
In June 2026, Workday announced its own path: "Agent-Ready Tools," enterprise connectors built on MCP that give agents access to HR and finance data while inheriting Workday's own security model, delegation controls, and audit trail, plus a separate "Developer Agent" that builds Workday apps from natural-language prompts inside tools including Claude Code, Cline, Codex, Cursor, and Google Antigravity. Both are available now to early access customers through Workday Extend Professional; general availability is projected for the second half of 2026. Workday's 2026 R2 release separately added a narrower MCP server for Adaptive Planning, its financial planning product, available as a preview. None of this is a Claude.ai or ChatGPT chat-client integration — Developer Agent targets coding tools and CLIs, and Workday hasn't stated ChatGPT support for either tool.
What each route can and can't do
The honest constraint on every route is the same: an AI assistant can only do what the interface underneath it can do. Knowing which interface you're on tells you the real ceiling.
Read access: WQL, RaaS, and REST
WQL is Workday's own query language for reading tenant data, reachable through the WQL REST API or embedded in a report. RaaS turns an existing custom report into a callable web service that returns the same rows the report shows. Both are what most vendor MCP servers lean on for "ask a question about your workforce" — fast to wire up and low-risk, since there's nothing to accidentally change. Straight REST calls against Workday's functional APIs cover more ground, including some writes, but each endpoint has its own object model and scope requirements: "REST access" is whatever set of endpoints the API client was registered to reach, not one uniform capability.
Write access
Writing through an API client is a different, more consequential grant than read scopes, and the safe order is the same everywhere: start read-only, add write scopes deliberately, and put a confirmation step between the AI deciding to write and the write actually happening. An AI assistant with write-scoped credentials and no such step can change a business process, a security assignment, or a calculated field as fast as it can change a chat response.
Extend app building
A vendor or custom MCP server built on WQL, RaaS, or REST scopes doesn't reach Workday Extend app development — building, validating, and deploying an Extend app needs its own Workday Extend subscription and account, and its own build and deploy tooling, not just broad REST scopes. Workday's own early-access Developer Agent is built for exactly this gap, connecting to coding tools like Claude Code to build apps from a prompt, but it's not yet generally available and it's a separate product from the data-access MCP servers above.
Browser-only tasks
Plenty of real Workday admin work — stepping through a business process, working inside a task that isn't exposed as an API object, checking how a page renders for a given security group — only exists in the Workday UI, with no endpoint for "click through this screen." That's the gap a browser-driven AI agent closes, and why it needs a different safety model: a visible browser window instead of a hidden API scope.
What to check before you connect AI to a live tenant
- Credential scope. Know exactly which security domains the API client (or Workday's own connector) can reach before you point any AI tool at it — the scope you register is the ceiling on what the AI can ever do, regardless of what a tool's description claims.
- Read versus write, set explicitly. Don't grant write scopes by default. Add them only for the objects you intend the AI to change, once read-only behavior has proven correct.
- Which environment the credential points at. Confirm whether you're handing the AI a Sandbox, Implementation, or Production credential — Production is where a mistake reaches real employee and payroll data immediately.
- Who holds the credential. A vendor-hosted MCP server stores or proxies it on its own infrastructure; a self-hosted server or a desktop agent changes who's custodian of that secret. Check which model your data handling agreements permit before you pick one.
- Multi-client, multi-tenant separation. If you work across more than one Workday client, confirm the tool keeps each client's credentials and context separate — nothing about a general-purpose AI chat client does this by default.
- Approval before side effects. If any write scope is enabled, confirm a person sees the specific record and change before it happens, not a summary after the fact.
Where kiweely fits
kiweely takes a different shape than the routes above. It's a desktop app, not a Claude or ChatGPT plugin: your Workday sign-ins and your own AI account (a ChatGPT or Claude subscription, or an OpenRouter key) stay on your computer, not on a vendor's servers. It signs in to Workday the way you do, in a visible browser window you can watch and stop, which is what lets it reach browser-only tasks and Extend app building alongside WQL, reports, and admin work — not just the slice of Workday an API client can see. Every change waits for your approval, and it keeps each client's tenants and conversations separate for consultants who work across more than one.
The bottom line
For read-only questions against tenant data, a vendor MCP server built on WQL or RaaS is the fastest path and the smallest blast radius. For write access, treat the API client scope as the real safety boundary and insist on a confirmation step. For Extend app building or anything that only exists in the Workday UI, a data-access MCP server won't get you there today — you need a browser-driven desktop agent, or, once it reaches general availability, Workday's own Developer Agent. Whatever you connect, check the credential's scope, the environment, and who holds it first. See the mechanics of setting up an Integration System User and API client in the Integration System User and API client guide, and the differences between WQL, RaaS, and REST in the RaaS, WQL, and REST guide. For how a trust layer should handle Production tenants specifically, read the Production tenant problem; for multi-client credential separation, read keeping your clients' data separate. For Claude specifically, compare a Workday MCP server with Claude in kiweely. kiweely's own security model is on the Security page.