Skip to main content
Glama
chrischall

workday-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Read a Workday task / data card

workday_get_task
Read-onlyIdempotent

Retrieves a Workday task or data card by path and returns a structured read-only view: sections, labels, values, references, related tasks, and export links. Works through your signed-in Workday tab.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesWorkday 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`.
viewNoResponse 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.
depthNoLevels to follow (default 1). Supplying this implies `expand` unless `expand: false` is passed explicitly.
expandNoFollow 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.
maxCardsNoCap on child cards fetched (default 12). Supplying this implies `expand` unless `expand: false` is passed explicitly.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed1 schema field changedv0.6.2
    • addedInput schema / properties / view
      Added 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"
+}
  3. Changed3 schema fields changedv0.4.0
    • addedInput schema / properties / depth
      Added value: +{
+  "description": "Levels to follow (default 1). Supplying this implies `expand` unless `expand: false` is passed explicitly.",
+  "maximum": 3,
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / expand
      Added 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"
+}
    • addedInput schema / properties / maxCards
      Added 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"
+}
  4. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, and the description reinforces this with 'Read-only; no data is mutated.' It adds operational context beyond annotations: requests ride the signed-in Workday tab, SPA URLs are normalized automatically, and the result is a structured projection rather than a raw payload. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three compact sentences with the action and output contract front-loaded. It provides path sourcing, URL normalization, auth context, and a read-only guarantee without repeating schema content or adding filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description supplies the needed return contract: title, current user, sections as label/value fields, navigable references, related tasks, and export links. It also states the auth prerequisite and mutation guarantee, while the schema covers expand/depth/maxCards behavior, making the definition complete enough 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.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3 and the schema already explains path, view, depth, expand, and maxCards. The description adds genuinely useful meaning for the path parameter by specifying where to source it (prior references[].uri or relatedTasks[].uri) and that /d/... URLs normalize automatically, which an agent would otherwise have to infer.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Fetch a Workday page (task or data card) by its path' and enumerates the structured return contents. It distinguishes itself from raw fetching siblings like workday_fetch by emphasizing a structured, read-only view, and from worker-scoped tools by being path-driven.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly states when to use the tool: when you have a Workday path from a prior result's references[].uri or relatedTasks[].uri, or an open page URL, and it explains SPA URL normalization. It does not explicitly name excluded alternatives or say 'use workday_get_worker_task instead for worker-specific lookups', so it falls just short of full alternative routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools