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

Retrieve a specific named item from a worker's profile (e.g., Compensation, Job Details) by matching the task name case-insensitively against available options. Read-only.

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

TDQS

A4.5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

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

Usage Guidelines4/5

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.

Deploy Server

Other Tools