Server Quality Checklist

Tool Scores

• get_ukg_timecardsB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description carries the full transparency burden, but it only says 'Retrieve' and mentions optional date constraints. It does not disclose behavior around the path/query override parameters, pagination, tenant-specific response details, or required permissions.

  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, front-loaded sentence with no filler or redundant wording. It efficiently communicates the core purpose and the main optional constraint.

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

  Completeness2/5

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

  This is a 5-parameter tool with a nested query object and no output schema, but the description only covers employee and date range. It does not explain the path override, arbitrary query parameters, or what a successful result looks like, making it under-specified for invocation.

  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 the baseline is 3 because the schema already documents all five parameters. The description adds minimal value beyond naming the employee and date range, but it does not clarify date formats or the meaning of path/query beyond their schema 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 uses a specific verb ('Retrieve') and clearly identifies the resource ('timecards'), the target ('an employee'), and the optional constraint ('date range'). It is distinct enough from siblings like get_ukg_employee and get_ukg_compensation, which target different resources.

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

  Usage Guidelines2/5

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

  No when-to-use or when-not-to-use guidance is provided, and no alternatives are mentioned despite closely related siblings such as call_ukg_endpoint and get_ukg_saved_report_csv. The description only implies use for employee timecards, leaving the choice among these tools to inference.

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

• call_ukg_endpointB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure, but it only reveals that credentials are pre-configured. For a generic REST tool that supports DELETE and PATCH methods, it doesn't warn about mutation risks, response size limits, session expiration, or what happens when endpoints aren't tenant-enabled, leaving the agent blind to potential side effects.

  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 exactly two sentences, each earning its place. The first sentence states the action, and the second provides the use-case context. No wasted words, no repetition of schema information, and front-loaded with the most critical information.

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

  Completeness2/5

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

  For a generic REST endpoint tool with no output schema and no annotations, the description should cover response formats, pagination behavior, rate limiting, or error scenarios.Resource conflict: This should be 2, not 3. The description only covers the 'explore' aspect and leaves critical behavioral details absent.

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

  Parameters1/5

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

  Schema description coverage is merely 20% (only 'path' is documented), yet the description provides zero parameter documentation. While the schema offers enums for method and accept, the 80% of undocumented parameters (body, query) get no clarification, and the low coverage requires the description to compensate — which it fails to do entirely.

  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 calls a UKG Ready REST endpoint with configured credentials, using a specific verb ('Call') and resource ('UKG Ready REST endpoint'). The phrase 'explore tenant-enabled endpoints' distinguishes this generic explorer from the specific sibling tools like get_ukg_employee and list_ukg_timecards, making its 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 provides useful context ('Use this to explore tenant-enabled endpoints') that implies this is a fallback/exploration tool when specific helpers don't exist. However, it doesn't explicitly name alternatives or state when to prefer the specific sibling tools, leaving some ambiguity for the agent.

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

• get_ukg_compensationA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'Retrieve' and offers no information about authentication requirements, access restrictions, pagination, response shape, or potential side effects. This is minimal and leaves notable ambiguity for a tool with no other metadata.

  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, clear sentence that communicates the core behavior in an efficient way. It is front-loaded with the action and resource, with no filler or redundancy.

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

  Completeness3/5

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

  The tool appears simple, but the presence of path and query overrides plus lack of annotations and output schema creates some ambiguity about request behavior and return expectations. The description is adequate for basic selection and invocation, but it could benefit from clarifying the endpoint semantics or relationship to call_ukg_endpoint.

  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 the baseline is 3. The description adds only a high-level distinction between employee-specific and collection-level retrieval, mostly reinforcing what the employeeId parameter already states rather than providing additional semantics.

  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 ('Retrieve') and identifies a clear resource ('compensation data'), further clarifying whether the target is an individual employee or the tenant collection. This distinguishes it from sibling tools like get_ukg_employee or get_ukg_timecards.

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

  Usage Guidelines3/5

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

  The description implies this tool is for compensation data, but it does not explicitly state when to prefer it over generic alternatives like call_ukg_endpoint. It gives clear context by contrasting employee-level vs collection-level retrieval, but no exclusions or alternative guidance are provided.

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

• list_ukg_exceptionsA
  3.5/5.0
  Behavior3/5

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

  The description adds one useful behavioral detail: the view is scoped to the configured API user. However, it does not disclose pagination behavior, default date ranges, or whether exceptions are limited to a certain time window. Given the absence of annotations, more disclosure would be needed for a higher score.

  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, clear, front-loaded sentence with no fluff. Every word earns its place, making it easy to scan and understand.

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

  Completeness3/5

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

  For a tool with 5 parameters, no output schema, and no annotations, the description is adequate but minimal. It doesn't mention return behavior, default values, or what happens when no parameters are provided, which an agent would likely need to know for correct use.

  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?

  All five parameters are documented in the schema with descriptions and coverage is 100%, so the baseline of 3 is appropriate. The description itself does not add additional parameter semantics, but it doesn't need to since the schema is self-sufficient.

  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 and resource ('List timekeeping exceptions') and adds context about the visibility scope ('visible to the configured UKG Ready API user'). This clearly distinguishes it from sibling tools like list_ukg_employees and get_ukg_timecards.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to choose this tool over alternatives such as call_ukg_endpoint or get_ukg_timecards. There is no mention of exclusions, prerequisites, or typical use cases beyond the basic definition.

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

• get_ukg_saved_report_csvA
  3.6/5.0
  Behavior2/5

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

  No annotations are present, and the description does not disclose side effects, permissions, rate limits, or whether the operation is read-only. It only states a prerequisite without describing behavior.

  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 concise sentence with no superfluous words, making it easy to parse.

  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 simple download tool, the description covers the action and a key prerequisite. It doesn't mention output details or error conditions, but remains adequate given the tool's simplicity.

  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 schema already fully documents the reportId parameter, and the description adds no extra meaning beyond the prerequisite, so it meets the baseline but adds little value.

  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 downloads a UKG Ready saved report as CSV, which is specific and distinct from sibling tools like listing employees or timecards.

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

  Usage Guidelines3/5

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

  It mentions a prerequisite (report must be shared with configured API user) but does not explicitly contrast with alternatives like call_ukg_endpoint or provide when-not-to-use guidance.

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

• list_ukg_employeesA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of disclosure. It adds useful context by indicating results are limited to what the configured API user can see, but it does not mention pagination, result format, or explicitly confirm whether this is a read-only operation beyond what 'List' implies.

  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, front-loaded sentence that achieves high clarity with zero filler. Every word adds value: the verb, the object, and the visibility qualifier.

  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 simple endpoint with two optional parameters and no output schema, the description and the schema together provide enough to invoke the tool effectively. The scope qualifier adds useful context, and the schema covers the endpoint override and query parameters, so no critical information is missing.

  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?

  Parameter semantics are already fully documented in the input schema: 'path' explains its override default and 'query' notes additional UKG tenant parameters. The description adds no extra parameter-level meaning, so the baseline 3 applies.

  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 clear verb 'List' with a specific resource 'employees' and adds a meaningful scope qualifier ('visible to the configured UKG Ready API user'), making it easy to distinguish from the singular get_ukg_employee and the generic call_ukg_endpoint.

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

  Usage Guidelines2/5

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

  The description does not provide guidance on when to use this tool versus alternatives like get_ukg_employee or call_ukg_endpoint. No exclusions, prerequisites, or comparison points are given beyond the implied permission-scoped visibility.

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

• get_ukg_employeeA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. 'Get' clearly indicates a read operation and 'one ... by ID' sets expectations of a single-record lookup, but it does not describe error behavior, authorization requirements, response shape, or any quirks of the underlying UKG Ready API. This is adequate for a simple getter but not rich in transparency.

  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 one short sentence, front-loads the verb and resource, and contains no redundant or filler words.

  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 simple get-by-ID tool with fully described parameters, the description plus schema is sufficient to select and invoke the tool. The only minor gap is the lack of an output schema or return-value description, but the tool name and description make the returned employee object reasonably predictable.

  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 coverage is 100% and each parameter has a meaningful description (employeeId, path override placeholder, query object). The tool description adds no semantic value beyond the schema beyond reiterating that the lookup is by ID, so the baseline of 3 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 uses a specific verb and resource—'Get one UKG Ready employee by ID'—and clearly scopes the operation to a single record keyed by employee ID, distinguishing it from sibling tools like list_ukg_employees and get_ukg_timecards.

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

  Usage Guidelines3/5

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

  The phrase 'by ID' and 'one' imply the appropriate use case: fetch a single known employee rather than a list. However, it does not explicitly state when to prefer this over sibling tools or provide exclusion criteria, so usage guidance remains implied rather than explicit.

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