This server provides read-only access to your personal Workday data (pay, benefits, compensation, etc.) through your existing signed-in browser session — no admin-provisioned API credentials needed.
Discover your Workday apps (workday_get_apps): List all apps on your Workday home screen, each with a launchable task ID — the starting point for exploring available data.
Read any Workday task or data card (workday_get_task): Fetch structured data from any Workday page by its path or URL, returning the page title, label/value fields, navigable references (instance IDs + drill-in URIs), related tasks, and export links. Supports SPA /d/... URLs and bare endpoint suffixes.
Check connection health (workday_healthcheck): Verify the end-to-end bridge between the MCP server and your signed-in Workday browser tab, with diagnostics distinguishing bridge, extension, or Workday-side failures.
Key constraints: All operations are read-only (no data is created, modified, or deleted), and everything routes through your own browser session via the fetchproxy extension.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@workday-mcp what are my current tasks?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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 fetchproxy
browser extension, reusing your existing SSO-authenticated session.
⚠️ Workday gives employees no personal API. This server reads the same internal
*.htmldendpoints 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).
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.
Related MCP server: Edenred Plus MCP
See SKILL.md for full setup. In brief:
{
"mcpServers": {
"workday": {
"command": "npx",
"args": ["-y", "workday-mcp"],
"env": { "WORKDAY_TENANT": "your-tenant-slug" }
}
}
}Then install the fetchproxy extension and sign into Workday in your browser.
Tool | What it does |
| List your Workday apps with launchable task ids — the discovery entry point |
| Open an app by name ("Talent and Performance", "Absence") and follow it down to the child cards holding its real content |
| Read any task/data card by id or path → fields, full table rows, references, related tasks, export links. |
| Your reporting chain — each person with title, location, report count, and a |
| A worker's profile: the catalog of everything readable about them (9 sections, ~40 named tasks) |
| Open one named item from that catalog — "Compensation", "Performance Reviews", "Management Chain" |
| The same catalog, for yourself |
| Raw |
| Read-only GraphQL against Workday's PEX surface (mutations refused). The only route to Inbox / search |
| Verify the bridge + session end-to-end with an actionable hint |
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.
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, crawledAll 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.
npm install
npm test # vitest
npm run build # tsc --noEmit + esbuild bundle → dist/bundle.jsThe widget-tree parser (src/parse.ts) is the durable core; see
docs/WORKDAY-API.md for the captured endpoint shapes and
schema. License: MIT.
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_get_task (structured) when it works; reach for this to explore an unfamiliar page or to see fields the parser drops. Bare uris get .htmld appended and /d/ SPA paths are normalized. Read-only (GET only).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Workday path, e.g. `/acme/inst/1$715/247$42.htmld` or `2998$43525`. | |
| maxBytes | No | Payload cap before truncation (default 60000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent, openWorld), the description discloses secrets redaction, URL normalization (bare URIs get .htmld appended, /d/ SPA paths normalized), and read-only GET constraint. These are critical behavioral traits not implied by annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, tightly packed with purpose, usage guidance, behavior, and constraints. Every phrase is necessary, no redundancy, and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a fetch tool: it states what it does, when to use it, how it transforms paths, and that it's read-only. With no output schema, the return type (RAW JSON) is specified. No other behavioral aspects are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters (path and maxBytes) with descriptions/purpose. The description adds path normalization behavior ('Bare URIs get .htmld appended and /d/ SPA paths are normalized') which is not in the schema, providing extra semantic value. However, maxBytes behavior is not elaborated beyond the schema, so a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a raw Workday endpoint and returns RAW JSON with secrets redacted. It explicitly identifies itself as an escape hatch for endpoints not modeled by other tools, distinguishing it from siblings like workday_get_task (which is structured).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly recommends preferring workday_get_task when it works, and explains when to use this tool: 'to explore an unfamiliar page or to see fields the parser drops.' This gives clear when/when-not guidance for alternative selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 taskId to workday_get_task to open it. Some apps share a generic launcher id; if one returns a near-empty page, open the app in your browser and pass that URL to workday_get_task instead. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations (readOnlyHint, idempotentHint, openWorldHint) by explaining read-only nature and generic launcher IDs behavior, with no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences with no fluff; each sentence adds essential information (purpose, usage, edge case, read-only status).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description fully explains purpose, how to use results, and handles edge cases. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline is 4. Description adds value by explaining the output's taskId usage, but no parameter details needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists Workday apps from the home screen and provides a launchable task id, distinguishing it from siblings like workday_get_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this to discover apps, then pass taskId to workday_get_task, with fallback instructions for generic launchers. Covers when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read your own worker profile — the same catalog workday_get_worker returns, for yourself. Use it to find your pay, benefits, time off, goals, and feedback. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds 'Read-only' reinforcing this. The description also adds useful context about the data content (pay, benefits, time off, goals, feedback) and ties it to workday_get_worker's return, providing value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every word earns its place. It avoids redundancy and clearly communicates the tool's scope and typical use cases without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only self-profile tool, the description is complete. It explains what data is available, references a sibling tool for context, and declares read-only behavior. No output schema is provided, so the description doesn't need to detail return values beyond referencing workday_get_worker's catalog.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter details. The description correctly implies no input is needed by focusing on 'your own' profile, and the baseline for zero-parameter tools is 4. There is no missing parameter information to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'your own worker profile', distinguishing it from the sibling tool workday_get_worker by emphasizing 'for yourself'. It also lists example data fields (pay, benefits, time off, goals, feedback), making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need your own profile, and contrasts with workday_get_worker by noting 'the same catalog workday_get_worker returns, for yourself'. However, it does not explicitly state when NOT to use it or mention alternative sibling tools beyond this implicit contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the reporting chain around you: each person with their business title, location, report count, and a profileUri you can pass straight to workday_get_worker. Resolves the Org Chart app from your own app menu. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint, openWorldHint, and idempotentHint, so the description's 'Read-only' is redundant but harmless. It adds value by disclosing the return shape (per-person business title, location, report count, profileUri), the scope ('around you'), and the integration path to workday_get_worker. This goes beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences communicate purpose, output fields, scope, integration, and access context without filler. The most important verb ('Read') and resource ('reporting chain') are front-loaded, and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with no output schema, the description is complete: it states what is returned, the personal scope ('around you'), the app-resolution behavior, and a concrete downstream use of profileUri. Sibling tools are differentiated well, and no critical usage context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage, so there is no parameter ambiguity. The description appropriately focuses on output semantics rather than inputs, using the extra room to explain what the returned data will include and how profileUri can be consumed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and scope: 'Read the reporting chain around you.' It then details the output elements (business title, location, report count, profileUri) and cross-references workday_get_worker, which clearly distinguishes this from sibling tools like workday_get_worker or workday_get_my_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the use case clear—viewing one's own reporting chain and pulling the org chart app from the app menu. It also indicates a natural follow-up by noting the profileUri can be passed to workday_get_worker. It does not explicitly state when not to use this tool, but the context is sufficient for a zero-parameter read tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 *.htmld endpoint — take it from a prior result's references[].uri or relatedTasks[].uri, or paste the URL of a Workday page you have open (SPA /d/... URLs are normalized automatically). Every request rides your signed-in Workday tab. Read-only; no data is mutated.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Workday data endpoint path, e.g. `/acme/inst/13102!ABC/cacheable-task/2998$43525.htmld`, or a copied `/acme/d/...` SPA URL, or a bare suffix like `quickaccess/fetch.htmld`. | |
| view | No | Response shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact strips image/avatar URLs from the response; "full" returns Workday's payload untouched. No field projection: this server has no verified record of which Workday fields matter, and inventing one would risk dropping a field a caller needs. | |
| depth | No | Levels to follow (default 1). Supplying this implies `expand` unless `expand: false` is passed explicitly. | |
| expand | No | Follow the page down to the child cards holding its real content. Turn this on when a page comes back with no sections — container/hub pages delegate everything to children whose uris exist only inside the parent response. | |
| maxCards | No | Cap on child cards fetched (default 12). Supplying this implies `expand` unless `expand: false` is passed explicitly. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description reinforces read-only and adds substantial behavioral detail: authentication dependency (signed-in tab), URL normalization, compact vs full response semantics, and expand/depth behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but dense, with every sentence contributing meaningful information. It leads with the core function, then details path sourcing, response shape, and read-only guarantee. No filler, but slightly verbose for a concise definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully specifies the return structure (title, user, sections, references, related tasks, export links) and explains the expand behavior and caps. All 5 parameters are covered in schema and description, and the tool's context (read-only, auth) is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds valuable semantics beyond the schema: it explains the path's origin and normalization, the rationale behind compact vs full (stripping image URLs, no field projection), and the implication of depth/maxCards on expand. This elevates it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Fetch) and resource (Workday page) and enumerates the returned structure, clearly distinguishing it from siblings that fetch workers, apps, etc. It is not a tautology and gives concrete detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit guidance on where to obtain the path (from prior results' references/relatedTasks or from an open page URL) and notes that requests ride the signed-in tab. It doesn't name alternatives or exclusion conditions, but the context is clear for a read-only fetch tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 profileUri from workday_get_org_chart or any reference, or a bare worker id like 247$42. Then use workday_get_worker_task to open one by name. Shows only what your own Workday permissions already allow. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| worker | Yes | A full profile uri (e.g. `/acme/inst/1$715/247$42.htmld`) or a bare worker instance id (e.g. `247$42`). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but the description adds valuable context about the catalog structure and permission constraints ('Shows only what your own Workday permissions already allow'). It does not contradict annotations and provides extra behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose, and every sentence adds value—covering output, input format, and next steps without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and no output schema, the description adequately explains the return format (catalog of sections and tasks), input requirements, and follow-up tool usage. It also notes permission limits, making it complete for the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema description is detailed, but the description enriches parameter understanding with concrete examples (bare id '247$42') and source references (profileUri from workday_get_org_chart), which goes beyond the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a worker's profile and returns a catalog of all readable sections and tasks. It distinguishes from sibling workday_get_worker_task by explaining it returns a catalog, not individual tasks, and mentions it is read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit input guidance (profileUri from get_org_chart or bare worker id) and indicates the next step ('Then use workday_get_worker_task to open one by name'). It also notes permission limitations, giving a clear usage flow without needing alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Task name as it appears on the profile, e.g. `Compensation`. | |
| view | No | Response shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact strips image/avatar URLs from the response; "full" returns Workday's payload untouched. No field projection: this server has no verified record of which Workday fields matter, and inventing one would risk dropping a field a caller needs. | |
| worker | Yes | Profile uri or bare worker instance id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint, openWorldHint, and idempotentHint annotations, the description adds concrete behavioral details: case-insensitive matching, error listing of available tasks, and a read-only note. No contradiction with annotations; it enriches them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, information-dense sentence front-loads the core function, lists examples, notes matching behavior, and error handling, followed by a terse 'Read-only.' No redundant words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with a view parameter that explains response shape and full schema coverage, the description covers essential context: purpose, matching, error behavior, and safety. No critical gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all three parameters (100% coverage), including detailed semantics for the view parameter. The tool description itself doesn't add parameter-level meaning, so it meets the baseline without enhancing it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Open') and a precise resource ('a single named item from a worker's profile'), with concrete examples like 'Compensation' and 'Job Details'. It clearly distinguishes this from sibling tools such as workday_get_task by scoping to a worker's profile tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for opening items on a worker's profile, which implies when to use it. It doesn't explicitly name alternatives or state exclusions, but the scope is unambiguous enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a read-only GraphQL query against Workday's PEX surface (/wday/pex/graphql). This is the only route to surfaces that have no GET-able .htmld endpoint — notably the Inbox / "My Tasks" and global search. Workday does not publish these operations, so you supply the document; expect to iterate. mutation and subscription documents are REFUSED — this server is read-only — as are type-system (SDL) documents, whose definition boundaries cannot be tracked reliably.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A GraphQL `query` document. Mutations are rejected. | |
| maxBytes | No | Payload cap before truncation (default 60000). | |
| variables | No | Variables for the query. | |
| operationName | No | Operation name; also sent as the `?operation=` query parameter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint; the description adds that mutation/subscription documents are refused, that the server is read-only, and that the agent should 'expect to iterate' due to unpublished operations. This goes beyond the annotations by specifying exact refusal boundaries and the iterative nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences), front-loads the core purpose and endpoint, then provides usage context and constraints. Every sentence adds value, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a GraphQL tool with no output schema, the description covers the key behavioral expectations: read-only, endpoint, refusal of mutations/subscriptions, and the need to iterate. It does not detail response format or error handling, but given the standard nature of GraphQL responses and the presence of annotations, it is sufficiently complete for an agent to act.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds the phrase 'you supply the document; expect to iterate' which reinforces the query parameter's purpose but does not add new meaning beyond the schema. No extra parameter-specific details are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool runs a read-only GraphQL query against a specific endpoint ('/wday/pex/graphql'), names the resource precisely, and distinguishes it from siblings by noting it's the only route to surfaces like Inbox and global search that lack GET-able .htmld endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'This is the only route to surfaces that have no GET-able .htmld endpoint — notably the Inbox / "My Tasks" and global search.' It also conveys that Workday does not publish these operations, implying alternative tools should be used whenever a standard endpoint exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already supply readOnlyHint, openWorldHint, and idempotentHint, so the bar for behavioral disclosure is lower. The description adds value by stating 'Read-only, no auth required' and by enumerating the specific diagnostic outputs (role, port, version, link state, round-trip time, plain-English hint). This gives meaningful transparency beyond the annotations, though it does not mention the fact it performs an external network round-trip and may have latency or transient failure beyond the annotations' coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry the full burden: the first packs the resource, action, and full diagnostic list; the second gives the usage trigger. The text is information-dense with no obvious padding. It could be slightly cleaner if the diagnostic list were bulleted, but it stays readable and all clauses earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must cover what the tool returns; it does comprehensively: bridge role, port, version, link status, elapsed round-trip time, and the plain-English hop diagnosis. It also covers the invocation context (zero params, read-only, no auth) and the expected failure scenario. Nothing an agent needs to decide or call the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100% (the schema is an empty object). The baseline for no-parameter tools is 4, and the description correctly adds no parameter explanation because none is needed. There is no ambiguity in parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Round-trips a small public wd5.myworkday.com URL through the fetchproxy bridge') and names the exact resource (the bridge). It clearly differentiates from sibling tools like workday_fetch and workday_graphql by positioning this as a diagnostic healthcheck rather than a data-retrieval call. The title 'Verify the fetchproxy bridge end-to-end' is fully translated into concrete behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The last sentence gives an explicit trigger: 'Call this when a real tool fails and you want to know which hop broke.' This clearly communicates a primary use case and implies the healthcheck is not a routine fetch tool. However, it does not name alternatives or provide a when-not-to-use condition, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| app | Yes | App name or a distinctive part of it, e.g. `talent` or `my team`. | |
| view | No | Response shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact strips image/avatar URLs from the response; "full" returns Workday's payload untouched. No field projection: this server has no verified record of which Workday fields matter, and inventing one would risk dropping a field a caller needs. | |
| depth | No | Levels of child cards to follow (default 1, 0 = the hub page only). | |
| maxCards | No | Cap on child cards fetched (default 12). Each is a real browser fetch. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint; the description adds beyond this by explaining that it follows child cards, matches case-insensitively, and requires no task ids. It also confirms read-only alignment with annotations. No contradictions; adds meaningful behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the purpose and concrete examples, then the key behavioral note. Every word earns its place; no fluff or redundancy. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 params (1 required), no output schema, and annotations covering safety, the description gives sufficient context: what it does, how it behaves (following links), and parameter hints. It doesn't mention response size or pagination, but those aren't critical for a read-only tool. Slightly more could be said about potential large responses, but it's complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 4 parameters with detailed descriptions (100% coverage), so the description doesn't need to compensate. It adds minor value (e.g., mentioning case-insensitive matching in the description) but the schema already handles parameter meaning effectively. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'open' and resource 'Workday apps', with concrete examples ('My Team Management', 'Time', etc.) and the key behavior of following child cards. It distinguishes itself from siblings like workday_get_apps by emphasizing it works without task ids and follows links, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: most app hubs return empty shells, so this tool follows links to get the real content. This implies the right scenario for use, but it doesn't explicitly state when not to use it or mention alternatives like workday_fetch. A solid but not exhaustive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.6.2workday_get_task1 field changedInput schema / properties / viewAdded value: +{
+ "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact strips image/avatar URLs from the response; \"full\" returns Workday's payload untouched. No field projection: this server has no verified record of which Workday fields matter, and inventing one would risk dropping a field a caller needs.",
+ "enum": [
+ "compact",
+ "full"
+ ],
+ "type": "string"
+}workday_get_worker_task1 field changedInput schema / properties / viewAdded value: +{
+ "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact strips image/avatar URLs from the response; \"full\" returns Workday's payload untouched. No field projection: this server has no verified record of which Workday fields matter, and inventing one would risk dropping a field a caller needs.",
+ "enum": [
+ "compact",
+ "full"
+ ],
+ "type": "string"
+}workday_open_app1 field changedInput schema / properties / viewAdded value: +{
+ "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact strips image/avatar URLs from the response; \"full\" returns Workday's payload untouched. No field projection: this server has no verified record of which Workday fields matter, and inventing one would risk dropping a field a caller needs.",
+ "enum": [
+ "compact",
+ "full"
+ ],
+ "type": "string"
+}v0.4.0workday_fetchworkday_get_my_profileworkday_get_org_chartworkday_get_task3 fields changedInput schema / properties / depthAdded value: +{
+ "description": "Levels to follow (default 1). Supplying this implies `expand` unless `expand: false` is passed explicitly.",
+ "maximum": 3,
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / expandAdded value: +{
+ "description": "Follow the page down to the child cards holding its real content. Turn this on when a page comes back with no sections — container/hub pages delegate everything to children whose uris exist only inside the parent response.",
+ "type": "boolean"
+}Input schema / properties / maxCardsAdded value: +{
+ "description": "Cap on child cards fetched (default 12). Supplying this implies `expand` unless `expand: false` is passed explicitly.",
+ "maximum": 40,
+ "minimum": 1,
+ "type": "integer"
+}workday_get_workerworkday_get_worker_taskworkday_graphqlworkday_open_appv0.1.0workday_get_appsworkday_get_taskworkday_healthcheckScored 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.
Browser MCP for logged-in tasks. Uses your Chrome — credentials stay local. Zero-token replay.
Hosted MCP server with managed OAuth for 15+ toolkits: Google Workspace, Fitbit, Oura, Kalshi, etc.
Public MCP server for discovering open jobs. Search, filter, and get application links.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
