Skip to main content
Glama
chrischall

workday-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Open one task on a worker profile

workday_get_worker_task
Read-onlyIdempotent

Fetch a specific section from a worker's Workday profile, such as Compensation or Job Details, using the exact task name. If the name doesn't match, receive a list of available tasks.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taskYesTask name as it appears on the profile, e.g. `Compensation`.
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.
workerYesProfile uri or bare worker instance id.

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

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses case-insensitive matching against the worker's own task catalog, and that a mismatch returns an error listing exactly what is available. These are useful behavioral details not present in structured fields.

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?

Two tightly written sentences front-load the action and examples, then add matching and error behavior. There is no filler or repetition of schema details.

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

Completeness4/5

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

Given full schema coverage and readOnly/idempotent/openWorld annotations, the description covers action, scope, matching behavior, error behavior, and read-only semantics. It does not describe the return payload shape, but no output schema exists and the 'view' parameter already documents response shaping.

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 value by giving concrete task examples and clarifying that matching is case-insensitive against that worker's task catalog, which enriches the meaning of the 'task' and 'worker' parameters beyond their schema descriptions.

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 ('Open') and an exact resource ('single named item from a worker's profile'), with concrete examples like 'Compensation' and 'Job Details'. The worker-profile anchoring clearly distinguishes it from generic siblings such as 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.

Usage Guidelines4/5

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

It provides clear usage context: this tool opens a named item from a specific worker's profile, and it describes matching and error behavior. It does not explicitly state when not to use it or name alternatives, but the scope is unambiguous enough for an agent to route correctly.

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