Server Quality Checklist

Tool Scores

• get-employee-photoC
  2.7/5.0
  Behavior1/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 merely restates the tool's purpose. It fails to disclose response format (e.g., binary image vs URL), behavior for missing photos, or any permissions needed, making it nearly information-free beyond the name.

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

  Conciseness4/5

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

  The description is a single, readable sentence with no redundancy. It is appropriately concise for a simple tool, though the brevity contributes to under-specification in other dimensions.

  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?

  Without an output schema or annotations, the description must explain return behavior and edge cases, but it does not. It is unclear whether the tool returns raw image data, a download URL, or something else, leaving the agent under-informed for a complete 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?

  The input schema already provides 100% coverage with clear descriptions for both employeeId and size. The description adds no extra semantic value beyond schema, so baseline 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool fetches an employee photo, with 'get' as the verb and 'employee photo' as the resource. It is easily distinguishable from sibling tools like get-employee or get-employee-directory, though it does not explicitly mention returning image data.

  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 use this tool versus alternatives. The description simply says 'by size' without explaining any prerequisites, exclusions, or comparison to other employee-related tools.

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

• get-whos-outB
  3.3/5.0
  Behavior3/5

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

  No annotations provided, so the description carries full burden. 'View' implies read-only, and the description discloses the return structure in detail (mixed events, fields, summary counts). However, it does not mention any potential side effects, auth requirements, or limitations. The return format is a useful behavioral disclosure, but authentication and rate limits are absent.

  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 concise sentences, front-loaded with purpose, followed by a clear understanding of return format. No wasted words.

  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 description explains the return types and fields, but 'summary counts' is vague and no structural details are provided for the counts. Without an output schema or annotations, more clarity on the response object would be needed for full completeness. The core purpose is clear, but edge cases and limits are unaddressed.

  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%, with both start and end parameters clearly documented including defaults. The description adds no param-specific details beyond what the schema already provides, so the baseline of 3 applies.

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

  Purpose4/5

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

  The description clearly states the verb 'View' and resource 'upcoming time off and holidays for a date range', which is specific. It doesn't explicitly differentiate from the sibling tool 'get-time-off-requests', but the inclusion of holidays and mixed event types implies a broader scope.

  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 on when to use this tool versus alternatives, no exclusions or prerequisites. The tool simply states its function without context.

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

• estimate-time-off-balanceA
  3.6/5.0
  Behavior3/5

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

  Without annotations, the description carries the burden of behavioral disclosure. It adds useful context about the return structure (array of time off types with specific fields) and indicates the operation is a calculation. However, it does not clarify behavior for edge cases (e.g., omitted date, past dates) or explicitly state that the operation is read-only and has no 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 two sentences, front-loaded with the main action, and every sentence provides substantive information. It avoids redundancy and is appropriately sized for a simple tool.

  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 low-complexity tool with good schema coverage and no output schema, the description is fairly complete. It explains the main purpose and return format. However, it omits behavior when the optional 'date' parameter is not provided, which is a minor gap.

  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 input schema provides 100% description coverage for both parameters (employeeId and date), including formats and purpose. The tool description adds no additional parameter semantics beyond what the schema already states, so the baseline of 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 clearly indicates the tool calculates future time off balances for an employee, with the verb 'Calculate' and resource 'future time off balances'. It also lists the specific return fields (current balance, units, policyType, usedYearToDate), distinguishing it from sibling tools like get-time-off-requests or get-whos-out.

  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 any guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or explicitly contrast with sibling tools like get-time-off-requests. The use case is implied by the name but not stated as guidance.

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

• get-employee-goalsA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose the return fields (title, description, percentComplete, status, dueDate, milestones) and notes that milestones apply only to milestone-based goals. However, it does not mention error conditions, authentication requirements, or whether the operation is strictly read-only (though 'Get' and 'Returns' imply this). Provide more context on edge cases would increase 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 two sentences: the first states the tool's core purpose, the second lists the key return fields. It is concise, front-loaded, and every sentence adds value without redundancy.

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

  Completeness4/5

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

  Given the tool's simplicity (2 params, no output schema, no annotations), the description covers the essential return shape and purpose. It could optionally note the filter parameter's effect, but the schema already enumerates 'open', 'closed', and 'all' with a default. The description is complete enough for an agent to invoke it correctly for a straightforward goal-retrieval task.

  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%, with clear descriptions for both 'employeeId' and 'filter' (including enum values and default). The description adds no additional parameter semantics—it only mentions return fields. Per the rubric, baseline is 3 when schema covers parameters, and the description does not need to repeat that information.

  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's purpose with a specific verb and resource: 'Get performance goals and objectives for an employee.' This distinguishes it from sibling tools like get-employee-photo or list-company-files, which serve different purposes.

  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 usage when you need an employee's goals, but it does not explicitly mention alternatives or exclusions. For example, it does not say 'use get-employee-directory instead for contact info.' The purpose itself gives enough context for a straightforward getter, but there is no explicit when-to-use guidance.

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

• get-time-off-requestsA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses the operation is a read/filter (via 'Retrieve and filter'), and it adds useful context about returned fields including 'available actions (approve/deny/etc.)'. However, it does not explicitly state read-only behavior, permissions, pagination, or response format. It is not misleading but leaves some transparency gaps.

  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 purpose, and every sentence contributes. It avoids fluff and conveys the key points (retrieve/filter, return fields, filtering capability) efficiently.

  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?

  With no output schema, the description takes responsibility for explaining return values, and it does list key fields (id, employeeId, status, dates, type, amount, actions, notes). However, it omits details like pagination, default limits, sorting, or how multiple filtering parameters combine. It is adequate for a simple list tool but not fully complete for a 7-parameter 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 mentions 'extensive filtering' but does not add meaning beyond what the schema already documents for each parameter. It reinforces the filtering nature but does not introduce new semantics or parameter relationship details.

  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's function: 'Retrieve and filter time off requests.' It uses a specific verb ('retrieve', 'filter') and resource ('time off requests'), and the listed sibling tools (e.g., get-employee, estimate-time-off-balance) are distinct enough to avoid confusion. It fully distinguishes itself from siblings.

  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 usage for retrieving and filtering time off request records, which is a clear context. However, it does not explicitly mention when not to use this tool or name specific alternatives (e.g., get-whos-out for who is out, estimate-time-off-balance for balances). It lacks exclusion guidance but provides sufficient context.

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

• get-company-fileA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full behavioral disclosure. It supplements the schema by specifying that binary files are returned as base64-encoded content, and that the response includes file size and metadata. This goes beyond the parameter schema, though it does not detail error cases or authentication requirements.

  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 main action, and every word adds value. There is no fluff or repetition of schema details.

  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 tool with one parameter and no output schema, the description provides sufficient context: the download action, handling of binary files (base64), and additional metadata. The only minor gap is the lack of clarification for non-binary files, but overall this is largely complete.

  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% for the sole parameter (fileId), so the schema already explains its purpose. The description adds no new parameter semantics beyond the schema, which is acceptable at the baseline of 3 for high 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 uses a specific verb ('Download') and resource ('specific company document') with an explicit mechanism ('by ID'). This clearly distinguishes it from sibling tools like list-company-files (which lists files) and employee-specific tools.

  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 usage: you need a file ID and want the document content. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites like obtaining the ID via list-company-files. There are no exclusions but no explicit 'when not to use' guidance either.

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

• get-employeeA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must convey behavioral traits. It states that it 'Returns employee object with fields' and mentions customization, which partially describes behavior. However, it does not disclose error handling, read-only nature, or other operational details. The description adds some value but not rich context.

  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 long, front-loaded with the core action, and avoids unnecessary details. It efficiently conveys the purpose and key behavior without redundancy.

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

  Completeness4/5

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

  Given the tool's simplicity (3 optional parameters, no output schema), the description adequately covers the core functionality. It lists common fields and explains the field selection mechanism. While it doesn't address sibling tool distinctions, the description is sufficient for a straightforward employee data retrieval tool.

  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 lists example fields and references the 'fields' parameter, but does not add significant meaning beyond the schema's parameter descriptions. It reinforces the parameter behavior without adding new details.

  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 'Get' and the resource 'employee', and specifies the customizable field selection capability. It distinguishes itself from sibling tools like get-employee-photo and get-employee-directory by focusing on general employee data with flexible field 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?

  The description provides clear context that this is the tool for retrieving employee data with selectable fields. It does not explicitly mention alternatives or exclusions, but the broad scope of the tool is self-evident. Sibling tools are specialized, making usage context reasonably clear.

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

• get-meta-fieldsA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full behavioral burden. It discloses the return format (array with id, type, name, optional alias) and implies a read-only 'discover' operation. However, it does not explicitly state authentication needs, rate limits, or side effects, leaving some behavioral transparency gaps. The description adds value beyond the purpose but does not fully cover potential behavioral concerns.

  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 only two sentences and front-loads the core purpose. It wastes no words while conveying the tool's scope and output. Every phrase contributes to understanding.

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

  Completeness4/5

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

  Given the tool's simplicity (no params, no output schema, no annotations), the description explains the return shape and its purpose. It is complete for a metadata-discovery tool. A minor gap is that it does not specify whether this includes custom fields or requires any special permissions, but the tool is still likely usable without that detail.

  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 contains nothing to explain. The baseline for 0 parameters is 4. The description adds useful context by detailing the structure of the returned field definitions, which is more than the empty schema provides.

  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's function: 'Discover all available BambooHR data fields.' It uses a specific verb ('discover') and resource ('data fields'), and it distinguishes itself from sibling tools that focus on specific employee records (e.g., get-employee, get-employee-photo) by returning field metadata rather than actual employee data.

  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 clear context: 'Essential for understanding what employee data fields can be requested.' This implies using the tool before querying employee data. However, it does not explicitly mention when not to use it or name alternative tools, falling short of the explicit when/when-not guidance required for a 5.

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

• list-company-filesA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of transparency. It discloses the return structure (categories and file fields), making it clear this is a metadata listing, not a download. However, it omits potential details like pagination or authorization, but these are not critical for a simple list tool.

  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 only two sentences, with the main purpose front-loaded. Every sentence adds value: the first states the action, the second details the return structure. No filler or redundancy.

  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 (0 parameters, no output schema, sibling differentiation), the description fully covers the essentials: it states what is returned and the data fields. It is sufficiently complete for an agent to know when and how to invoke 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?

  The schema has zero parameters, so the description need not explain any. The baseline for 0-parameter tools is 4, and the description adds no confusing parameter info, making it 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's function: browsing available company files and categories. It uses a specific verb ('browse') and resource ('company files'), and distinguishes itself from the sibling tool 'get-company-file' by emphasizing the listing/overview nature.

  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 the tool is used for browsing/listing files but does not explicitly state when to use it versus alternatives like 'get-company-file'. There is no mention of when not to use it or any exclusion criteria.

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

• get-employee-directoryA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It discloses the output format (array), the scope (company-wide), and the included fields, which is meaningful behavioral detail. It does not mention auth or rate limits, but for a simple read-only directory getter this is reasonable.

  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 sentence that leads with the primary action and scope, then enumerates the return fields. Every word earns its place with no redundancy.

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

  Completeness4/5

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

  Given the tool's simplicity (no parameters, no output schema), the description is almost complete. It names the return type, scope, and representative fields, though 'and more' is slightly vague. Still, it gives an agent enough context to invoke correctly.

  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 baseline is 4. The description adds no parameter information, but none is needed; the schema already covers everything.

  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 uses specific verb 'Get' and resource 'company-wide employee directory', clearly distinguishing it from sibling tools like get-employee (singular). It also specifies the return type (array of employee objects) and key fields, making the tool's function 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 phrase 'company-wide employee directory' conveys clear context: use when you need the full directory rather than an individual employee. However, it does not explicitly name alternatives or exclusion scenarios, so it misses the highest bar for 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.