Server Quality Checklist

Tool Scores

• workday_get_taskA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint/openWorldHint/idempotentHint, so the read-only confirmation is redundant. However, the description adds genuine context: authentication model ('Every request rides your signed-in Workday tab'), SPA URL normalization behavior, and the container/hub delegation semantics for expand. The 'no data is mutated' phrasing mildly re-labels the annotation rather than disclosing something new, but the auth and normalization details carry the score above the baseline.

  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 tight three sentences of prose that front-loads the core purpose and output shape, with each of the following sentences adding distinct value (path construction, then auth/read-only confirmation). The parenthetical list of output fields is dense but scannable. It's near-ideal — the only minor inefficiency is that 'Read-only; no data is mutated' restates the annotation, but this does not meaningfully inflate length.

  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?

  For a read-only tool with no output schema, the description carries the burden of explaining return shape, and it does so substantively (title, current user, label/value sections, references, related tasks, export links). Combined with schema documentation for edge cases (expand for hub pages, maxCards capping), an agent has what it needs to invoke this correctly. The absence of caveats around error cases or rate limiting is a minor gap but not critical for an idempotent read operation.

  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% — all four params (path, depth, expand, maxCards) have rich inline descriptions including examples, defaults, and cross-parameter dependencies (e.g., 'Supplying this implies expand'). The tool description adds value beyond the schema by telling the agent WHERE valid paths come from (prior references or pasted URLs) and implicitly informing value selection when chaining results. This exceeds the baseline of 3 for full schema coverage.

  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 precise verb+resource pairing — 'Fetch a Workday page (task or data card) by its path and return a structured, read-only view' — and enumerates the structured output (title, current user, sections, navigable references, related tasks, export links). This distinguishes it clearly from siblings like workday_fetch (which implies a rawer response) and workday_get_worker_task, while the title reinforces the scope.

  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 gives clear context on path provenance ('take it from a prior result's references[].uri or relatedTasks[].uri') and even provides failover guidance (SPA URLs are normalized, container pages need expand). However, it never explicitly names an alternative tool or states when NOT to use this tool in favor of a sibling like workday_fetch, so it stops short of full exclusion guidance.

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

• workday_graphqlA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and openWorldHint; the description adds that mutation/subscription documents are refused, that the server is read-only, and that the agent should 'expect to iterate' due to unpublished operations. This goes beyond the annotations by specifying exact refusal boundaries and the iterative nature.

  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 concise (3 sentences), front-loads the core purpose and endpoint, then provides usage context and constraints. Every sentence adds value, with no filler or repetition.

  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?

  For a GraphQL tool with no output schema, the description covers the key behavioral expectations: read-only, endpoint, refusal of mutations/subscriptions, and the need to iterate. It does not detail response format or error handling, but given the standard nature of GraphQL responses and the presence of annotations, it is sufficiently complete for an agent to act.

  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?

  Schema description coverage is 100%, so all parameters are documented in the schema. The description adds the phrase 'you supply the document; expect to iterate' which reinforces the query parameter's purpose but does not add new meaning beyond the schema. No extra parameter-specific details are given.

  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 the tool runs a read-only GraphQL query against a specific endpoint ('/wday/pex/graphql'), names the resource precisely, and distinguishes it from siblings by noting it's the only route to surfaces like Inbox and global search that lack GET-able .htmld endpoints.

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

  Usage Guidelines5/5

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

  Explicitly states when to use this tool: 'This is the only route to surfaces that have no GET-able .htmld endpoint — notably the Inbox / "My Tasks" and global search.' It also conveys that Workday does not publish these operations, implying alternative tools should be used whenever a standard endpoint exists.

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

• workday_open_appA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the description's 'Read-only' is redundant but consistent. The description adds valuable behavioral details: it follows links to child cards (multi-step navigation) and performs case-insensitive matching against the app menu. No contradictions 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 a single, well-structured paragraph that leads with the core action, lists concrete examples, explains the follow-through behavior, and ends with key matching details. Every sentence earns its place; there is no fluff or repetition.

  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?

  For a tool with 3 parameters, high schema coverage, and strong annotations (read-only, idempotent), the description is adequate. It explains the purpose, the navigation behavior, and matching semantics. It does not describe output format, but no output schema exists, and the description's mention of 'read it' implies the content is returned. Overall, it's sufficiently complete for an agent.

  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 baseline is 3. The description adds extra semantic value by explaining case-insensitive app matching and the concept of 'child cards' that depth controls, which goes slightly beyond the schema's param descriptions. It doesn't fully compensate for every nuance but adds meaningful context.

  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 uses a specific verb ('Open') with a clear resource ('Workday apps by name') and explicitly lists example app names, then explains the follow-through to child cards. It distinguishes itself from sibling tools like workday_get_apps (list) and workday_fetch (generic fetch) by focusing on opening a specific app by name and traversing its content.

  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 gives strong context for when to use this tool: 'Most Workday app hubs return a near-empty shell on their own; this follows the links for you.' This implies when the tool is needed, but it does not explicitly name alternatives or state when not to use it (e.g., for raw API access). It offers clear situational guidance without formal exclusions.

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

• workday_get_my_profileA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and idempotentHint, and the description adds 'Read-only' reinforcing this. The description also adds useful context about the data content (pay, benefits, time off, goals, feedback) and ties it to workday_get_worker's return, providing value beyond 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 two sentences, front-loaded with the core purpose, and every word earns its place. It avoids redundancy and clearly communicates the tool's scope and typical use cases without fluff.

  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 zero-parameter, read-only self-profile tool, the description is complete. It explains what data is available, references a sibling tool for context, and declares read-only behavior. No output schema is provided, so the description doesn't need to detail return values beyond referencing workday_get_worker's catalog.

  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?

  The tool has zero parameters, so the schema provides no parameter details. The description correctly implies no input is needed by focusing on 'your own' profile, and the baseline for zero-parameter tools is 4. There is no missing parameter information to compensate for.

  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 the verb 'Read' and the resource 'your own worker profile', distinguishing it from the sibling tool workday_get_worker by emphasizing 'for yourself'. It also lists example data fields (pay, benefits, time off, goals, feedback), making the tool's purpose unmistakable.

  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 implies when to use this tool: when you need your own profile, and contrasts with workday_get_worker by noting 'the same catalog workday_get_worker returns, for yourself'. However, it does not explicitly state when NOT to use it or mention alternative sibling tools beyond this implicit contrast.

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

• workday_get_org_chartA
  4.5/5.0
  Behavior4/5

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

  Annotations already establish readOnlyHint, openWorldHint, and idempotentHint, so the description's 'Read-only' is redundant but harmless. It adds value by disclosing the return shape (per-person business title, location, report count, profileUri), the scope ('around you'), and the integration path to workday_get_worker. This goes beyond the structured annotations without contradicting 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?

  Two focused sentences communicate purpose, output fields, scope, integration, and access context without filler. The most important verb ('Read') and resource ('reporting chain') are front-loaded, and every clause earns its place.

  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 zero-parameter read-only tool with no output schema, the description is complete: it states what is returned, the personal scope ('around you'), the app-resolution behavior, and a concrete downstream use of profileUri. Sibling tools are differentiated well, and no critical usage context is missing.

  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?

  The tool has zero parameters and 100% schema description coverage, so there is no parameter ambiguity. The description appropriately focuses on output semantics rather than inputs, using the extra room to explain what the returned data will include and how profileUri can be consumed.

  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 action and scope: 'Read the reporting chain around you.' It then details the output elements (business title, location, report count, profileUri) and cross-references workday_get_worker, which clearly distinguishes this from sibling tools like workday_get_worker or workday_get_my_profile.

  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 makes the use case clear—viewing one's own reporting chain and pulling the org chart app from the app menu. It also indicates a natural follow-up by noting the profileUri can be passed to workday_get_worker. It does not explicitly state when not to use this tool, but the context is sufficient for a zero-parameter read tool.

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

• workday_get_workerA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and idempotentHint, but the description adds valuable context about the catalog structure and permission constraints ('Shows only what your own Workday permissions already allow'). It does not contradict annotations and provides extra behavioral insight.

  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 sentences, front-loaded with the main purpose, and every sentence adds value—covering output, input format, and next steps without any fluff.

  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 one parameter and no output schema, the description adequately explains the return format (catalog of sections and tasks), input requirements, and follow-up tool usage. It also notes permission limits, making it complete for the tool's scope.

  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% and the schema description is detailed, but the description enriches parameter understanding with concrete examples (bare id '247$42') and source references (profileUri from workday_get_org_chart), which goes beyond the baseline for full schema coverage.

  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 the tool reads a worker's profile and returns a catalog of all readable sections and tasks. It distinguishes from sibling workday_get_worker_task by explaining it returns a catalog, not individual tasks, and mentions it is read-only.

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

  Usage Guidelines5/5

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

  The description provides explicit input guidance (profileUri from get_org_chart or bare worker id) and indicates the next step ('Then use workday_get_worker_task to open one by name'). It also notes permission limitations, giving a clear usage flow without needing alternatives.

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

• workday_get_worker_taskA
  4.7/5.0
  Behavior5/5

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

  While annotations already declare readOnlyHint and idempotentHint, the description adds genuinely useful behavioral context: case-insensitive matching, the error listing available tasks, and the 'Read-only' confirmation. This goes well beyond the structured 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?

  Two sentences, front-loaded with the core action, examples inline, and no wasted words. Every sentence contributes meaningful guidance.

  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 two simple parameters, a read-only hint, and full schema coverage, the description fully explains behavior, matching rules, and error output. No output schema is needed for this kind of open action, and the description covers the important runtime details.

  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% with clear parameter descriptions. The description adds extra value by giving expanded task examples and specifying case-insensitive matching, which helps an agent construct valid inputs beyond the raw schema.

  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 the action ('Open a single named item from a worker's profile') with concrete examples like 'Compensation' and 'Job Details'. It differentiates from siblings like workday_get_task by scoping to a worker's profile task catalog.

  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 context: use for opening a named task from a worker's profile, with matching semantics and error behavior. It does not explicitly say when NOT to use it or name alternatives, but the worker-profile scoping is clear enough for an agent to select it correctly.

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

• workday_healthcheckA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds valuable behavioral context: it describes the round-trip mechanism, the fixed URL tested, the diagnostic fields (role, port, version, elapsed time, hint), and the failure categories. No contradiction.

  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?

  Description is concise (~3 sentences) with key info front-loaded: action, output, usage context. Every sentence adds value—no fluff.

  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?

  Given zero parameters, no output schema, and strong annotations, the description fully covers the tool's purpose, behavior, and use case. It leaves no ambiguity about what the tool returns or when to use it.

  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?

  With zero parameters and 100% schema coverage, the description compensates by explaining the fixed URL and the diagnostic outputs, adding meaning beyond the empty schema. Baseline 4 is appropriate.

  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 specifies the exact action: round-tripping a public wd5.myworkday.com URL through the fetchproxy bridge to return diagnostics. It clearly distinguishes from sibling tools (workday_get_apps, workday_get_task) by focusing on connectivity health, not data retrieval.

  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?

  Explicitly states when to call: 'when a real tool fails and you want to know which hop broke.' Also highlights that it's read-only and needs no auth. Lacks explicit 'when not to use', but the context is clear enough.

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

• workday_fetchA
  4.9/5.0
  Behavior5/5

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

  Beyond annotations (readOnly, idempotent, openWorld), the description discloses secrets redaction, URL normalization (bare URIs get .htmld appended, /d/ SPA paths normalized), and read-only GET constraint. These are critical behavioral traits not implied by annotations alone.

  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 sentences, tightly packed with purpose, usage guidance, behavior, and constraints. Every phrase is necessary, no redundancy, and the key action is front-loaded.

  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?

  The description is complete for a fetch tool: it states what it does, when to use it, how it transforms paths, and that it's read-only. With no output schema, the return type (RAW JSON) is specified. No other behavioral aspects are missing.

  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?

  The schema already documents both parameters (path and maxBytes) with descriptions/purpose. The description adds path normalization behavior ('Bare URIs get .htmld appended and /d/ SPA paths are normalized') which is not in the schema, providing extra semantic value. However, maxBytes behavior is not elaborated beyond the schema, so a 4 is appropriate.

  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 the tool fetches a raw Workday endpoint and returns RAW JSON with secrets redacted. It explicitly identifies itself as an escape hatch for endpoints not modeled by other tools, distinguishing it from siblings like workday_get_task (which is structured).

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

  Usage Guidelines5/5

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

  It explicitly recommends preferring workday_get_task when it works, and explains when to use this tool: 'to explore an unfamiliar page or to see fields the parser drops.' This gives clear when/when-not guidance for alternative selection.

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

• workday_get_appsA
  4.9/5.0
  Behavior5/5

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

  Description adds context beyond annotations (readOnlyHint, idempotentHint, openWorldHint) by explaining read-only nature and generic launcher IDs behavior, with no contradiction.

  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?

  Four concise sentences with no fluff; each sentence adds essential information (purpose, usage, edge case, read-only status).

  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 zero-parameter list tool, the description fully explains purpose, how to use results, and handles edge cases. No output schema needed.

  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?

  No parameters, so baseline is 4. Description adds value by explaining the output's taskId usage, but no parameter details needed.

  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?

  Description clearly states it lists Workday apps from the home screen and provides a launchable task id, distinguishing it from siblings like 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 Guidelines5/5

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

  Explicitly says to use this to discover apps, then pass taskId to workday_get_task, with fallback instructions for generic launchers. Covers when-to-use and alternatives.

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