Server Quality Checklist

Tool Scores

• get_time_entriesA
  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 carries full responsibility for behavioral disclosure. It indicates a read operation ('Get') but omits important context such as whether entries are scoped to the authenticated user or all users, whether the date range is inclusive, and any potential pagination or ordering behavior. This leaves significant ambiguity for an agent.

  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 sentence of eight words, front-loaded with the action and resource. There is no redundant or filler content; every word serves a purpose.

  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?

  This is a simple read tool with two well-described parameters and no output schema. The description is minimally sufficient but leaves gaps: it does not clarify the scope of time entries (e.g., user-specific vs. all users) or hint at the response format. Given the absence of annotations and output schema, the description could be more complete, but it remains viable for an agent to select and invoke correctly with the information present.

  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% (both start_date and end_date have format descriptions). The tool description adds the concept of a 'period', which slightly clarifies the relationship between the two parameters, but it does not add substantive meaning beyond the schema. 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 ('Get') and resource ('time entries') with a scope ('for a given period'). This clearly distinguishes it from sibling tools like list_my_projects and create_time_entry, which have different resources or actions.

  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 for retrieving time entries within a date range, which is clear from the parameter requirement. However, it does not explicitly state when to use this tool versus alternatives like create_time_entry, nor does it mention any exclusions or prerequisites.

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

• list_absence_typesA
  4.2/5.0
  Behavior3/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. It states the primary action (listing) but does not mention potential aspects such as authentication requirements, whether all absence types are always returned, or what the return format looks like. This is acceptable for a simple read-only tool but lacks depth beyond the core 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 that is front-loaded with the action and resource. It contains no superfluous words and is easily scannable, making it 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?

  Considering the low complexity of the tool (no parameters, no annotations, no output schema), the description is largely complete. It covers the main purpose and gives examples. A slight gap is that it does not specify what information is returned for each absence type, but for a simple listing this is not critical, so a high score is justified.

  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 input schema has zero parameters, so the baseline for parameter semantics is 4. The description does not need to explain any parameters, and it adds context by providing example values, though those are not directly related to parameter semantics. This is sufficient given the absence of parameters.

  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 with a specific verb 'List' and a specific resource 'absence types', including examples ('Vacation, Sick Leave, etc.'). This distinguishes it from sibling tools that handle projects and time entries, making the purpose unambiguous.

  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 implicitly defines when to use the tool: whenever a list of available absence types is needed. Although it does not explicitly mention alternatives, the sibling tools are clearly different (projects, time entries), so there is no real ambiguity. However, it lacks explicit 'when not to use' guidance, so a perfect score is not warranted.

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

• list_my_projectsA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It adds two meaningful qualifiers ('active' and 'where time can be logged'), which go beyond a simple 'list projects'. However, it does not disclose return format, pagination, or any other behavioral traits, leaving some 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 a single sentence of 9 words, front-loaded with the verb and resource. Every word earns its place, and there is no redundancy or irrelevant information.

  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 adequately explains its purpose and scope. It could potentially mention pagination or the relationship between projects and tasks, but these are not essential for a basic list tool.

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

  Parameters4/5

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

  The tool has zero parameters, so the schema provides no information. The baseline for 0 params is 4, and the description does not need to compensate for missing parameter details. It clearly explains what the tool returns, which is 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 ('List') and a clear resource ('active projects and tasks') with a specific purpose ('where time can be logged'). It distinguishes itself from siblings like list_absence_types (absence types) and get_time_entries (time entries) by scoping to projects/tasks eligible for time logging.

  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 clear usage context: when you need to see available projects/tasks for logging time. It doesn't explicitly mention when not to use it or alternative tools, but the context is evident from the phrasing and sibling names.

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

• create_time_entryA
  4.4/5.0
  Behavior4/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. It discloses the create/update nature and the mandatory parameter constraint, though it does not elaborate on update semantics or return values.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the action, no redundant language. Every word earns its place.

  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 6-param tool with no output schema, the description covers the essential usage rule and action, but could mention outcomes (e.g., what an update does to existing entries) or return values. Still, it is largely sufficient for basic use.

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

  Parameters4/5

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

  Schema coverage is 100%, so parameters are well-documented. The description adds the 'must provide one' rule beyond the schema's mutual-exclusivity notes, providing valuable parameter guidance.

  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 'Create or update a time entry in Beebole' with a specific verb and resource, and adds the key mutual-exclusivity constraint that distinguishes it from sibling list/get tools.

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

  Usage Guidelines4/5

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

  The description gives explicit context for when to use the tool (creating/updating time entries) and a critical usage rule (must provide either project_id or absence_id), but it does not explicitly mention alternatives like get_time_entries for viewing.

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