workday-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WORKDAY_TENANT | Yes | Your Workday tenant slug |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| workday_healthcheckA | Round-trips a small public wd5.myworkday.com URL (/acme-corp/get-global-prefs.htmld?feature=doNotShowMobileAd) through the fetchproxy bridge and returns diagnostics: the bridge's role (host/peer/null), port, version, the extension link (linked / pair pending / not attached / never answered), the elapsed round-trip time, and a plain-English hint distinguishing 'bridge never came up' from 'extension not connected' from 'real wd5.myworkday.com-side problem'. Read-only, no auth required. Call this when a real tool fails and you want to know which hop broke. |
| workday_get_appsA | List the Workday apps available on your home screen, each with a launchable task id. Use this to discover what you can read, then pass an app's |
| workday_open_appA | Open one of your Workday apps by name — "My Team Management", "Talent and Performance", "Time", "Absence", "Benefits and Pay", "Org Chart", "Total Rewards" — and read it, following the app down to the child cards that hold its real content. Most Workday app hubs return a near-empty shell on their own; this follows the links for you. Matched case-insensitively against your own app menu, so it works without knowing any task ids. Read-only. |
| workday_get_taskA | Fetch a Workday page (task or data card) by its path and return a structured, read-only view: title, current user, each section as label/value fields, navigable references (instance id + drill-in uri), and the page's related tasks + export links. The path is a Workday |
| workday_get_org_chartA | Read the reporting chain around you: each person with their business title, location, report count, and a |
| workday_get_workerA | Read a worker's Workday profile and return the CATALOG of everything readable about them: sections (Job, Compensation, Benefits, Contact, Personal, Performance, Career, Feedback) each listing named, fetchable tasks. Pass a |
| workday_get_worker_taskA | Open a single named item from a worker's profile — "Compensation", "Job Details", "Performance Reviews", "Management Chain", "Benefits", "Goals", "Pay Change History", and so on. Matched case-insensitively against that worker's own task catalog; if it does not match, the error lists exactly what is available. Read-only. |
| workday_get_my_profileA | Read your own worker profile — the same catalog |
| workday_fetchA | GET any Workday data endpoint and return the RAW JSON with secrets redacted — the escape hatch for pages the typed tools do not model yet. Prefer |
| workday_graphqlA | Run a read-only GraphQL query against Workday's PEX surface ( |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool has a clearly distinct purpose: healthcheck, app discovery, app opening, structured page fetching, worker catalog, worker item fetching, raw fetching, and GraphQL. The potential overlaps between get_task/fetch and get_worker/get_worker_task are explicitly resolved in the descriptions.
The set consistently uses the workday_ prefix and mostly follows verb_noun naming like workday_get_apps and workday_get_worker_task. Minor deviations like workday_healthcheck, workday_fetch, and workday_graphql break the pattern slightly but are still readable and predictable.
Ten tools is well-scoped for a read-only Workday integration. Each tool covers a distinct surface area without redundancy, and the count feels neither bloated nor thin.
The toolset covers app discovery, profile/worker data, org chart navigation, structured page access, raw endpoint access, and GraphQL for non-HTML surfaces. The read-only boundary is intentional, and the raw fetch plus GraphQL escape hatches prevent dead ends.