Workday MCP Server: Setup, Tools & Real Limits
Workday MCP can give an AI client governed access to HR and finance data, but the setup and risk depend heavily on which server you choose.
A Workday MCP connection lets an AI client discover approved Workday capabilities and call them from a conversation. Today, the credible choices are tenant-provisioned Workday Agent Gateway endpoints or a public, read-only CData bridge. For production, we would choose Workday’s governed route; for a local proof of concept, CData is the more reproducible starting point.
Table of contents
- What Workday MCP actually is
- What exists today
- How to set up a Workday MCP server
- Tools you get
- Permissions and blast radius
- Real limits
- When not to use Workday MCP
What Workday MCP actually is
Workday MCP is a translation layer: an MCP client sees named tools, and the server turns approved tool calls into Workday requests. It does not grant new access or replace Workday’s security configuration.
An agent can ask which tables are available, which fields describe workers, or how many records match an approved filter. An official endpoint may also perform tenant-enabled actions when the tool and authorization exist. MCP standardizes tool discovery and invocation; the server determines the actual capabilities. The protocol separates tools from resources and prompts, so “supports MCP” never means “supports every Workday operation” (MCP server concepts).
Workday remains the system of record. Our view: use MCP for bounded questions and supervised workflows, not as an unattended substitute for HR operations.
What exists today
There is an official Workday route, but not a universal public package anyone can install. Workday Agent Gateway supplies official MCP endpoints for production tenants; the clearest public, runnable alternative is CData’s third-party local server.
| Option | What it is | Best fit | Main trade-off |
|---|---|---|---|
| Workday Agent Gateway | Tenant-provisioned official MCP endpoints | Governed enterprise deployment | Tools depend on products, tenant setup, and entitlement |
| CData Workday MCP server | Java bridge over a licensed CData JDBC driver | Local, read-only evaluation | Extra driver; local stdio; SQL-shaped access |
| Workday demo MCP server | Mock reference server | Testing without company data | Tools and records are not production access |
Workday’s AI Conversation Bridge repository labels its included server as a demo and says to replace it with official Agent Gateway endpoints in production. Its mock tool names are not evidence that the same names exist in your tenant.
CData’s Workday MCP repository is public, MIT-licensed, local, and read-only. It depends on CData’s commercial JDBC driver, so source availability is not Workday support. Browse official integrations when vendor ownership is required. Also, @workday/canvas-kit-mcp builds Canvas Kit interfaces; it does not query Workday HCM or finance data.
How to set up a Workday MCP server
Start with a non-production tenant, dedicated integration identity, and read-only authorization. For Agent Gateway, use the endpoint, client registration, and tool assignments supplied in your Workday environment; never guess a tenant URL.
For Workday APIs, OAuth 2.0 is the expected authorization basis: an administrator creates an API client and receives a client ID and secret. Workday says an exposed trusted-client secret must be regenerated (Workday API client documentation). Grant only the required functional domains; Workday domain security determines what the identity can see.
For the public CData route:
- Clone the repository and run
mvn clean installto produceCDataMCP-jar-with-dependencies.jar. - Install and license the CData JDBC Driver for Workday, then authenticate and test the connection in its utility.
- Create the documented
.prpfile with the driver path,cdata.jdbc.workday.WorkdayDriver, JDBC URL, and an explicit table allowlist. We would not leaveTablesblank. - Point the MCP client at the JAR and
.prpfile, then restart it.
The repository verifies this client shape:
{
"mcpServers": {
"workday": {
"command": "/PATH/TO/java",
"args": [
"-jar",
"/PATH/TO/CDataMCP-jar-with-dependencies.jar",
"/PATH/TO/workday.prp"
]
}
}
}
Replace the placeholders with absolute paths and keep .prp out of source control. This server uses stdio, so the client launches it locally. The MCP Directory config generator can check JSON syntax, but it cannot choose Workday permissions.
Tools you get
The public CData server exposes three verified, read-only tools. With Prefix=workday, the repository’s examples name them as follows.
| Tool name | What it does | Practical use |
|---|---|---|
workday_get_tables | Lists available tables as CSV | Discover the permitted data surface |
workday_get_columns | Lists columns for one table as CSV | Build a narrow query |
workday_run_query | Executes a SQL SELECT | Retrieve filtered rows |
The CData README documents only those three and describes run_query as SELECT-only (tool definitions). Official Agent Gateway tools are not a fixed public catalog; they reflect customer configuration. Run tools/list against your authorized endpoint and document the schemas before approving a workflow.
Do not copy Workday’s mock demo names into production. They illustrate employee and time-off flows, but the data and server are development components. If tools/list does not return a tool, your agent does not have it.
Permissions and blast radius
Start read-only, use a dedicated integration account, and restrict Workday domains and MCP tools. A shared administrator identity turns one mistaken prompt, leaked token, or malicious document into organization-wide exposure.
MCP guidance recommends least-privilege scopes, encrypted token storage, HTTPS remotely, and never logging credentials (MCP authorization guide). Workday adds the integration user’s domain security and business-process permissions. Both layers must deny access by default.
A careless Workday write can submit time off, change personal data, initiate compensation or supplier processes, or trigger downstream approvals. Require confirmation for every write, idempotency where supported, audit logs, and a workflow-specific allowlist. Never give a general chat agent payroll, bank, national-ID, or broad worker-profile access.
Real limits
The biggest limits are pagination, tenant throttling, model context size, and incomplete API coverage. MCP does not remove Workday API boundaries; the server must filter and compress results.
Workday REST collections default to 20 objects and usually cap a page at 100, though some APIs allow 1,000 (REST pagination documentation). WQL differs: its query cache can hold 10,000 rows and lasts only for the user session, up to 30 minutes (WQL pagination). Neither number is a sensible model-context target.
A huge worker CSV can exhaust context, increase cost, and expose unrelated personal data. Filter and aggregate in the query, select only necessary columns, cap rows, and summarize outside the model. Use another transport for large exports.
Workday throttles REST, RaaS, and SOAP under load. It documents 429 for REST/RaaS, possible 500 responses for overloaded SOAP/RaaS, and recommends exponential backoff and caching rather than one universal request rate (integration limits). Blind retries can worsen an incident.
An API also cannot perform an unexposed business process, bypass approvals, or safely infer company policy from missing data. Preview endpoints may change, custom fields vary by tenant, and descriptors are not stable identifiers. Unsupported tasks should stop, not invite improvisation.
When not to use Workday MCP
Do not use Workday MCP when the job is deterministic, bulk-oriented, or already handled better inside Workday. Choose the narrowest mechanism that produces an auditable result.
Use a plain API script for scheduled exports, payroll feeds, bulk reconciliation, and fixed transformations. Code offers repeatable pagination, tests, validation, and explicit failure handling without sending rows through a model. Workday positions its REST APIs for low-latency transactions; MCP adds little when there is no conversational ambiguity.
Prefer Workday’s own AI and Agent Gateway when native access rules, tenant context, support, and governed actions matter more than client choice. Workday Adaptive Planning advertises an external-LLM MCP connection that retains native access rules (Workday Adaptive Planning AI).
Our verdict: prove read-only value locally with CData, then move production to a tenant-governed official endpoint or purpose-built integration. Avoid community write servers unless you can audit every tool, auth flow, dependency, and failure path. MCP makes agent clients interchangeable, but adds model unpredictability and another security boundary. Compare the best MCP servers before placing sensitive Workday data behind any agent.