Workday MCP Server

workday-mcp

Read-only MCP server for Workday. Reads your Workday org chart, worker profiles, pay, benefits, performance, and any task or data card, and returns them as structured JSON. Every request routes through your own signed-in *.myworkday.com tab via the ContextMint Bridge browser extension, reusing your existing SSO-authenticated session.

⚠️ Workday gives employees no personal API. This server reads the same internal *.htmld endpoints the Workday web app calls, dispatched through your own signed-in browser tab. It is read-only and touches only your own data. Check your employer's acceptable-use policy. Use at your own discretion.

🤖 This project was developed and is maintained by AI (Claude Code).

Why a bridge instead of the official API?

The official Workday REST/SOAP API requires a tenant administrator to register an OAuth API client + Integration System User — an employee can't self-provision it. Tenants also sit behind corporate SSO (Ping/Okta/Entra) with MFA, so there's no server-side login. The only surface an employee can reach for their own data is their live browser session, which is what this server relays.

Install

See SKILL.md for full setup. In brief:

{
  "mcpServers": {
    "workday": {
      "command": "npx",
      "args": ["-y", "workday-mcp"],
      "env": { "WORKDAY_TENANT": "your-tenant-slug" }
    }
  }
}

Then install ContextMint Bridge from its releases page (Chrome: unzip the chrome zip and load it unpacked in chrome://extensions; Safari is not available yet — it will ship inside the ContextMint app, which has no public download link, so use Chrome for now) and sign into Workday in your browser.

ContextMint Bridge is the fetchproxy browser extension under its new name, from the same maintainer — fetchproxy's own README points to it. Its source is public at https://github.com/nullnet-app/contextmint-bridge: build it yourself, or check a release zip against the .sha256 file published beside it (shasum -a 256 -c contextmint-bridge-chrome-<version>.zip.sha256).

Tools

The parser understands seven Workday page families — data cards, grids (real tables, with chunking and export links), form-style detail pages, worker profiles, org charts, app hubs, and report prompt forms — and labels each page with its kind. See docs/WORKDAY-API.md.

Manager quick start

workday_get_org_chart                                   → who reports where, with profileUris
workday_get_worker         { worker: "<profileUri>" }   → that person's full catalog
workday_get_worker_task    { worker: "…", task: "Compensation" }
workday_open_app           { app: "talent" }            → a whole app hub, crawled

Review and promotion season

workday_get_team                                        → your reports, with workerIds
workday_get_reviews        { worker: "247$42" }         → their review history
workday_get_reviews        { worker: "247$42", review: "latest" }   → ratings + comments
workday_get_feedback       { worker: "247$42" }         → feedback received
workday_get_request_form   { requestType: "promotion consideration" } → the form's questions
workday_get_inbox                                       → review steps and requests waiting on you
workday_get_my_requests                                 → status of what you submitted
workday_get_team_snapshot                               → grade, last promotion, rating for everyone
workday_get_request        { request: "20447$18949" }  → a draft's questions + saved answers
workday_update_request     { request, answers: { "8": "…" }, action: "save" }  → preview + confirmToken
workday_update_request     { …same…, confirmToken }     → writes, then re-reads to verify

Benefits enrollment season

workday_get_benefits                                    → what you have now, and what it costs
workday_get_benefit_enrollment                          → deadline, next year's cost changes, every plan on offer
workday_get_benefit_enrollment { planType: "medical", rates: true }  → each plan's price at every coverage level
workday_get_benefits       { show: "dependents" }       → who you can cover

Making elections — confirmation-gated, like the request write:

workday_update_benefit_enrollment { changes: [{ planType: "dependent care", waive: true },
                                              { planType: "health savings", annualContribution: 7800 }],
                                    action: "save" }      → preview + confirmToken
workday_update_benefit_enrollment { …same…, confirmToken } → writes, then re-reads to verify
workday_update_benefit_enrollment { changes: [], action: "submit" }   → Review and Sign, I Accept, Submit

Writes

Two tools change anything: workday_update_request and workday_update_benefit_enrollment (choose or waive plans, set an HSA/FSA amount, then Save for Later or sign and Submit). Both are gated by the fleet confirm flow (@chrischall/mcp-utils confirmWrite): the first call returns a preview of every changed answer and a single-use confirmToken and sends nothing; only a repeat call with that token writes. The token is bound to the request (or enrollment event), the action, the answers (or changes), the preview and a hash of what is saved from a fresh read, so it is refused if any of them changes. A benefits submit signs Workday's electronic signature on your behalf — the preview says so. Configure with MCP_CONFIRM_MODE / MCP_CONFIRM_TTL_SECONDS / MCP_CONFIRM_SECRET.

All ids are discovered at runtime from your own app menu and org chart — nothing tenant-specific is hardcoded, so this works on any Workday tenant.

Development

npm install
npm test          # vitest
npm run build     # tsc --noEmit + esbuild bundle → dist/bundle.js

The widget-tree parser (src/parse.ts) is the durable core; see docs/WORKDAY-API.md for the captured endpoint shapes and schema. License: MIT.