Server Quality Checklist

Tool Scores

• browse_workday_tocA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare read-only, idempotent, non-destructive behavior. The description adds context on return structure (path, nodes with doc_id, child_count, children) and explains that non-null doc_ids indicate real pages, enhancing transparency beyond the 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 extremely concise: a brief opening sentence, then bulleted args and return format. Every sentence adds value, no redundancy. It front-loads the purpose and provides structured details efficiently.

  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 output schema exists, the description appropriately summarizes return values. It covers the core use case and links to a sibling tool (get_workday_doc). It is complete for the tool's exploratory purpose, though it could mention limitations regarding deep nesting.

  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% (baseline 3). The description adds usage context: 'Pass a breadcrumb path to expand a node; an empty path lists the top-level sections' and clarifies depth range (1-3). This adds meaningful guidance beyond the schema's simple 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 explicitly states the tool's purpose: exploring the documentation hierarchy when keyword search misses. It gives specific examples of top-level sections and explains how to use the returned doc_ids with get_workday_doc, clearly distinguishing its role from search.

  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 advises using this tool when keyword search fails and directs using returned doc_ids with get_workday_doc. While it implies when not to use (when search works), it does not explicitly exclude alternatives like lookup_extend_reference.

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

• get_workday_docA
  4.5/5.0
  Behavior4/5

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

  Annotations (readOnlyHint, idempotentHint, etc.) already indicate safety, but the description adds valuable behavioral details: truncation at 60k chars, error field only present on body fetch failure, and that html_url is always returned. This goes beyond annotations and provides a clear mental model of tool operation.

  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 remarkably concise: a single-sentence purpose followed by two short paragraphs covering usage and return format. Every sentence adds value, with no redundancy or filler. The structure is front-loaded and easy to scan.

  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 the tool's simplicity (two optional parameters, no nested objects, output schema provided), the description fully covers all aspects: input variants, edge cases (truncation, fetch failure), and output structure. No questions remain about how to use the tool or interpret results.

  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%, but the description adds meaningful context: explains that the parameters are mutually exclusive alternatives, specifies the source of doc_id ('from search_workday_docs'), and gives the exact URL format for html_url. This extra detail helps the agent understand how to choose and provide valid inputs.

  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 ('Fetch'), resource ('full markdown for one Workday documentation page'), and distinguishes from sibling tools like browse_workday_toc and search_workday_docs by specifying it retrieves a single page's content. The return fields are listed, leaving no ambiguity about the tool's purpose.

  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 says to use either doc_id or html_url, with clear sourcing from sibling tool search_workday_docs. It also notes that html_url is always returned for linking even if body fetch fails. While 'when not to use' is implicit (e.g., don't use for browsing or searching), the guidance is sufficient for an agent to correctly select and invoke the tool.

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

• search_workday_docsA
  4.8/5.0
  Behavior5/5

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

  Annotations already indicate read-only, non-destructive, idempotent. The description adds context: returns lightweight pointers, fallback to title-only matching, engine field in response, and empty results behavior. No contradictions.

  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 detailed and well-structured, but slightly verbose. It front-loads purpose and usage, but could be trimmed without losing value.

  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 the tool's complexity and available schema/output schema, the description covers all aspects: behavior, parameters, return format, and integration with sibling tools. No gaps.

  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 descriptions. The description adds examples for query and explains the effect of section and limit, but does not add new parameter info beyond the 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 it searches Workday documentation by concept, widget, API, or task. It distinguishes from siblings by specifying it returns lightweight pointers and directs to get_workday_doc for full text. Sibling browse_workday_toc is also mentioned.

  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 explains when to use this tool for searching, when to use get_workday_doc instead, and how to improve results (build index). It also describes fallback behavior and how to interpret the response.

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

• lookup_extend_referenceA
  4.9/5.0
  Behavior5/5

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

  Annotations provide readOnlyHint, idempotentHint, etc. Description adds value by explaining the tool returns excerpts inline, mentions the full-text index requirement, and describes the return structure, going 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.

  Conciseness4/5

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

  Description is front-loaded with purpose and usage, but contains some redundancy (e.g., repeats scope). However, every sentence is valuable and it remains clear. Minor room for conciseness improvement.

  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 the tool's complexity (3 params, output schema, annotations), the description covers purpose, usage, behavior, parameters, and return values completely. Output schema documents return structure, so no gaps.

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

  Parameters5/5

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

  Schema coverage is 100%, and the description enriches each parameter with examples (intent), detailed enum breakdown (kind), and explicit range/default (alternatives), adding meaning beyond the 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 it returns the best-matching reference page with inline content and alternative pointers, and distinguishes itself from siblings by scoping to the 'Extend App Components Reference' and directing broader queries to search_workday_docs.

  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 advises using this tool before writing code to ground on real schema/signature, and specifies when to use search_workday_docs for broader/conceptual docs, providing clear usage context and alternatives.

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