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. It adds valuable behavioral details beyond annotations: secrets redaction, raw JSON output, `.htmld` appending, and `/d/` SPA path normalization. This is substantive context, though not exhaustive about truncation or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and every sentence earns its place: purpose and output type, usage guidance versus an alternative, path normalization behavior, and read-only confirmation. It is front-loaded with the main purpose and contains no filler.

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

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

For a two-parameter tool with no output schema, the description adequately explains what the tool returns (RAW JSON with secrets redacted) and how path normalization works. The schema covers `maxBytes` and examples, and sibling guidance is explicit. Nothing critical is missing 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.

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 meaningful path semantics beyond the schema by explaining bare URIs get `.htmld` appended and `/d/` SPA paths are normalized, which helps the agent construct valid `path` values. It does not add detail about `maxBytes`, but the schema already covers that fully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb+resource ('GET any Workday data endpoint') and names its core value: returning RAW JSON with secrets redacted as an escape hatch for unmodeled pages. It also distinguishes itself from the typed sibling tools by framing itself as the fallback for exploring unfamiliar pages.

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

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

The description explicitly says to prefer `workday_get_task` (structured) when it works, and to use this tool for exploring unfamiliar pages or seeing fields the parser drops. This directly tells the agent when to choose this tool versus the alternative.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, and the description echoes 'Read-only.' It adds meaningful behavioral context beyond those annotations by disclosing that some apps share a generic launcher id and may return a near-empty page, plus the recommended workaround. This helps the agent anticipate an edge case and recover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action, and every sentence earns its place: first states what is listed, second explains why and how to use the output, third handles a known edge case. There is no redundant or filler content.

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

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

For a parameterless discovery tool with no output schema, the description is sufficient: it specifies what is returned (apps each with a launchable task id), the intended flow into workday_get_task, and the fallback behavior for problematic launchers. The annotations cover safety and idempotency, so nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is no input schema burden to compensate for; the baseline is 4. The description still usefully clarifies that the launchable taskId appears in the output and is the value that connects to workday_get_task, giving the schema-less return value practical semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: 'List the Workday apps available on your home screen.' It also distinguishes itself from the sibling workday_get_task by noting that the returned taskId should be passed there, so an agent can tell this discovery tool apart from the actions that consume its output.

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

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

It explicitly frames when to use this tool ('Use this to discover what you can read') and then routes the agent to workday_get_task with the taskId. It also provides a conditional fallback for generic launcher ids, telling the agent to open the app in a browser and pass the URL to workday_get_task instead, which is clear, specific guidance beyond a bare list.

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

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

Annotations already establish readOnlyHint and idempotentHint, and the description reinforces the read-only nature. It adds value by listing the types of data available and equating the response with `workday_get_worker`'s catalog, giving the agent behavioral expectations 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences front-load the action and scope, then add the concrete use cases. The only minor redundancy is restating 'Read-only' when the annotation already says it, but this is a low-cost safety signal.

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

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

For a zero-parameter, self-scoped read tool with strong readOnly/idempotent annotations, the description fully explains what the tool does and why an agent would call it. Pointing to `workday_get_worker`'s catalog also gives the agent a reference for expected return shape.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the description has no parameter burden to carry. The description still helps by indicating the content of the returned profile, which is useful given there is no output schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: 'Read your own worker profile.' It immediately distinguishes itself from the sibling `workday_get_worker` by noting it returns the same catalog for yourself. There is no ambiguity about what the tool does.

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

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

It provides clear context: use this tool to read your own profile and find pay, benefits, time off, goals, and feedback. It references `workday_get_worker` as returning the same catalog, implicitly signaling the difference, but it never explicitly states when to prefer one over the other.

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

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

Annotations already provide readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it resolves the Org Chart app from the user's app menu and describes how the profileUri can be consumed by workday_get_worker. No contradiction 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the core action and output details. Every sentence contributes: what it reads, what fields are returned, how the output connects to another tool, and that it is read-only. No filler.

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

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 compensates well by enumerating the returned fields and linking to workday_get_worker. Minor ambiguity remains about the exact scope of the 'reporting chain' (direct reports vs. full hierarchy), but it is sufficient for selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so the baseline is 4. The description clarifies the implicit subject of the operation by saying 'around you', which makes it clear the tool operates relative to the authenticated user without needing any explicit input.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Read the reporting chain around you' and enumerates the output fields (business title, location, report count, profileUri). It also differentiates from the sibling workday_get_worker by explaining that the returned profileUri is meant to be passed directly to that tool.

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

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

The usage context is implied clearly: use this when you need the reporting chain around the current user, and 'Resolves the Org Chart app from your own app menu' adds context. However, it never names alternatives or says when not to use this tool versus siblings like workday_get_my_profile or workday_get_worker.

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

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

Annotations already declare readOnlyHint and idempotentHint, and the description reinforces this with 'Read-only; no data is mutated.' It adds operational context beyond annotations: requests ride the signed-in Workday tab, SPA URLs are normalized automatically, and the result is a structured projection rather than a raw payload. No contradiction 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three compact sentences with the action and output contract front-loaded. It provides path sourcing, URL normalization, auth context, and a read-only guarantee without repeating schema content or adding filler.

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

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

With no output schema, the description supplies the needed return contract: title, current user, sections as label/value fields, navigable references, related tasks, and export links. It also states the auth prerequisite and mutation guarantee, while the schema covers expand/depth/maxCards behavior, making the definition complete enough 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3 and the schema already explains path, view, depth, expand, and maxCards. The description adds genuinely useful meaning for the path parameter by specifying where to source it (prior references[].uri or relatedTasks[].uri) and that /d/... URLs normalize automatically, which an agent would otherwise have to infer.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Fetch a Workday page (task or data card) by its path' and enumerates the structured return contents. It distinguishes itself from raw fetching siblings like workday_fetch by emphasizing a structured, read-only view, and from worker-scoped tools by being path-driven.

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

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

The description clearly states when to use the tool: when you have a Workday path from a prior result's references[].uri or relatedTasks[].uri, or an open page URL, and it explains SPA URL normalization. It does not explicitly name excluded alternatives or say 'use workday_get_worker_task instead for worker-specific lookups', so it falls just short of full alternative routing guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds meaningful behavioral context beyond those: the tool returns a catalog of fetchable tasks rather than the raw profile data itself, organizes results by section, and reflects only the caller's own existing Workday permissions. No contradiction 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no filler, front-loaded with what the tool does, then input guidance, then downstream routing, then a safety note. Every sentence earns its place and the structure leads with the most important information for an agent.

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

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

With one parameter, no output schema, and strong annotations, the description covers all an agent needs: input provenance, accepted formats, output shape at a high level, downstream tool to invoke, and permission constraints. Nothing required to call the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 specifying acceptable input forms (`profileUri` from `workday_get_org_chart`, any reference, or bare id like `247$42`) and naming a concrete source of the URI, which supplements the schema's generic examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description names the specific action (Read a worker's Workday profile) and the exact deliverable (a CATALOG of everything readable, organized by sections). It distinguishes itself from the sibling workday_get_worker_task by explicitly directing the agent to that tool for opening individual tasks.

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

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

The description states where to get input (`profileUri` from `workday_get_org_chart` or any reference) and how to proceed after the call (`use workday_get_worker_task`). It also notes permission limitations. It does not explicitly enumerate when to prefer siblings like workday_get_my_profile, but the flow guidance is clear enough.

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

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.

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.

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.

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.

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.

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.

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

Annotations already indicate readOnlyHint and openWorldHint, and the description reinforces and expands on them by specifying that mutation/subscription documents are refused, SDL documents cannot be tracked reliably, and users should expect to iterate because Workday does not publish these operations. This adds meaningful behavioral detail beyond the annotations rather than 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, information-dense, and front-loaded with the core purpose before moving into alternatives and constraints. Each sentence earns its place: endpoint and read-only nature, use-case uniqueness, publisher constraints, and explicit refusal rules. No filler or repetition.

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

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

For a complex GraphQL tool with four parameters and no output schema, the description covers the essential operational context: endpoint, supported operations, unsupported operations, why iteration should be expected, and the specific surfaces it serves. Combined with a fully documented input schema and meaningful annotations, nothing critical is missing for an agent to select and call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 100%, so the schema already documents all four parameters. The description adds slight context around the query document ('you supply the document; expect to iterate') and reiterates that mutations are rejected, but it does not meaningfully elaborate on maxBytes, variables, or operationName beyond what the schema provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('run a read-only GraphQL query'), a specific resource ('Workday's PEX surface /wday/pex/graphql'), and distinguishes the tool from siblings by noting it is the only route for surfaces without GET-able .htmld endpoints, such as Inbox and global search. This is far beyond a tautology and makes the tool's unique role clear.

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

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

The description gives clear when-to-use context: it is the only route for surfaces lacking GET-able .htmld endpoints, notably Inbox/My Tasks and global search. It also states what is refused (mutations, subscriptions, SDL documents), but does not explicitly name sibling tools to use for the other cases, so it falls just short of full alternative routing.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful context: it clarifies no auth is required, explains the round-trip nature, and details the diagnostic output including failure-mode distinctions. This goes beyond the annotations by describing what the tool actually does and what the results mean.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense sentence that front-loads the purpose and then enumerates the diagnostic outputs. Every clause adds value—the URL example, the list of fields, and the usage guidance. While it's longer than typical descriptions, the complexity of the tool warrants it, and it's structured logically from action to output to use case.

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

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

For a zero-parameter tool with no output schema, the description fully compensates. It details every diagnostic field returned (role, port, version, extension link, latency, hint) and explains the failure-mode classification. It also gives the trigger condition. There is nothing an agent needs to know to invoke or interpret the result that is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameters, and the empty schema is fully covered. It mentions the URL used internally, but that's not a user-provided parameter. No further semantic guidance is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool round-trips a specific URL through the fetchproxy bridge and returns diagnostics. It names the exact resource (wd5.myworkday.com URL) and output (bridge role, port, version, extension link, latency, hint). It distinguishes itself from sibling get/fetch tools by framing itself as a diagnostic for bridge health, not a data retrieval operation.

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

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

The description explicitly says 'Call this when a real tool fails and you want to know which hop broke.' This gives a clear trigger condition and distinguishes it from normal data-fetching siblings. It doesn't list exclusions (e.g., when not to use), but the context is strong enough to infer it's for troubleshooting, not routine calls.

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

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.

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.

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.

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.

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.

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.