Skip to main content
Glama
chrischall

workday-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Open a Workday app by name

workday_open_app
Read-onlyIdempotent

Opens a Workday app by name and retrieves its child cards, filling in content that hub pages leave empty. Matches your own app menu, so no task IDs needed.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appYesApp name or a distinctive part of it, e.g. `talent` or `my team`.
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 of child cards to follow (default 1, 0 = the hub page only).
maxCardsNoCap on child cards fetched (default 12). Each is a real browser fetch.

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.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so the description's 'Read-only' restates that, but it adds valuable context: it follows child links because hubs return near-empty shells, and it matches case-insensitively against the menu. This goes beyond the annotations by explaining the tool's behavior in a way that informs the agent about its depth and matching strategy.

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 a single paragraph that front-loads the purpose and key examples, then explains the child-following behavior. It's efficient but slightly verbose in the 'view' parameter description, which is in the schema anyway. Overall, it's well-structured and concise.

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 the tool's moderate complexity (4 params, 1 required) and rich annotation coverage, the description covers the essential usage (what it does, how it handles app names, the depth behavior). It doesn't mention the output shape, but there's no output schema, and returning child cards is implied. It also doesn't discuss performance costs, but the schema's maxCards hint covers that. Overall, it's adequately complete.

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 schema already documents each parameter. However, the description adds meaning by providing concrete examples for the 'app' parameter and explaining the default and trade-offs of 'view' (compact vs full) and 'depth' (child cards). This is more than the schema provides, especially for 'view', which has a detailed explanation of why there's no field projection.

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 clearly states a specific verb ('Open') and resource ('Workday app by name'), and lists concrete app names, distinguishing it from siblings like workday_get_apps and workday_get_task. It also clarifies that it follows child links, which is unique among the tools.

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 explains when to use this tool (when you need to open an app and read its child cards) and hints at alternatives (e.g., it works without task ids, implying workday_get_task is for tasks). It doesn't explicitly mention when not to use it, but the examples and contrast with siblings provide adequate 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