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

Fetch any Workday task or data card as structured read-only JSON: title, user, fields, drill-in references, related tasks, and export links from your signed-in browser session.

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 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"
+}
  2. 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"
+}
  3. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness4/5

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.

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 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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server

Other Tools