Server Quality Checklist

Tool Scores

• first_business_day_of_monthC
  2.8/5.0
  Behavior1/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. The description only states the basic function without disclosing behavioral traits such as whether holidays are considered, how weekends are handled, or how parameters like 'country' and 'subdivision' affect results. This lack of detail undermines safe and effective tool selection.

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

  Conciseness3/5

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

  The description is a single sentence, achieving brevity. However, it sacrifices detail; while the sentence is front-loaded and clear, it omits necessary behavioral context. It is appropriately concise but at the expense of completeness, warranting an average score.

  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?

  Given the tool's complexity (4 parameters, no output schema, many siblings), the description is insufficiently complete. It lacks explanation of how the result is computed (e.g., shifts from first of month, holiday handling) and does not clarify the role of optional parameters. The description does not adequately support correct tool 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 75% (3 of 4 parameters have descriptions). The description adds no additional parameter semantics beyond the schema. With high coverage, the baseline is 3, and no extra value is provided, so the score remains 3.

  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: 'Returns the first working day of a given month.' The verb 'returns' specifies the action, and the resource 'first working day' is distinct from siblings like 'last_business_day_of_month' and 'next_business_day'. It directly conveys the purpose without ambiguity.

  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 provides no guidance on when to use this tool versus alternatives. With 13 sibling tools, the agent receives no hints about context, prerequisites, or when not to use it. The usage must be inferred entirely from the tool name and description, which is insufficient.

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

• next_business_dayB
  3.1/5.0
  Behavior2/5

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

  No annotations provided. Description does not disclose behavior such as returning the same date if already a business day, handling of weekends/holidays, or the effect of country/subdivision parameters.

  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?

  Single sentence with no wasted words, but under-specified. Loses a point for missing critical context.

  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?

  Given 3 parameters, localization support, and many sibling tools, the description is too brief. Lacks explanation of default holiday calendar, behavior for non-business days, and relationship to other tools.

  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 baseline is 3. Description adds no extra information beyond what the schema already provides for each parameter.

  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 clearly states verb 'Find', resource 'first working day', and constraint 'after a date'. It effectively distinguishes from sibling tools like 'previous_business_day' and 'is_business_day'.

  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 vs siblings (e.g., when to use 'next_business_day' vs 'add_business_days'). No prerequisites or edge-case handling mentioned.

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

• last_business_day_of_monthB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description should disclose behavioral traits like holiday handling via country/subdivision. It only says 'working day' without clarification, and output format is unspecified.

  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?

  Single sentence with no extraneous words. Front-loads the core action efficiently.

  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?

  Despite 4 parameters and no output schema or annotations, the description omits return format, holiday logic, and usage examples. Incomplete for a tool with many siblings.

  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 75% (3 of 4 parameters described). The description adds no extra parameter context beyond the schema, so baseline score 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 states the tool returns the last working day of a given month, with a specific verb and resource. It effectively distinguishes from siblings like 'first_business_day_of_month'.

  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. Context such as comparing with other business day tools is absent.

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

• previous_business_dayB
  3.3/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 disclose behavior. It only says 'Find,' suggesting a read operation, but does not explain how business days are determined, whether it considers holidays, or if the operation is idempotent.

  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 with no unnecessary words. It is front-loaded and easy to parse.

  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 has 3 parameters and no output schema. The description is minimal and does not explain the return value or how holidays are handled. Acceptable for a simple tool but lacks completeness.

  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 has 100% description coverage, so the description adds no additional meaning beyond the schema. Baseline score of 3 applies as the description does not enhance parameter 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 clearly states the verb 'Find' and the resource 'last working day before a date,' distinguishing it from sibling tools like next_business_day or is_business_day.

  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 lacks context about prerequisites or comparison with similar tools.

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

• is_business_dayA
  3.6/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 bear the full burden. It does not disclose any behavioral traits beyond the core function, such as whether external holiday data is used, any authentication needs, rate limits, or side effects. The description is minimal.

  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 conveys the essential purpose without any wasted words. It is appropriately sized for the tool's simplicity.

  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 boolean-returning tool with no output schema, the description covers the main purpose. However, since no output schema exists, the agent might benefit from explicit mention of the return value (true/false). Still, the context is largely complete given the tool's straightforward nature.

  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% (all three parameters have descriptions in the schema). The description adds some context by mentioning weekends and public holidays, which connects to the country parameter. However, it does not add significant new meaning beyond the schema's parameter 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 clearly states the tool returns a boolean indicating whether a date is a working day, accounting for weekends and public holidays. It uses a specific verb ('Returns') and resource ('working day'), and distinguishes it from sibling tools that compute next/previous business days or ranges.

  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 use when checking a single date's business day status, but does not explicitly provide when-not-to-use guidance or mention alternative siblings (like 'next_business_day' or 'business_days_between'). No exclusions or context on when this tool is preferred.

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

• business_days_betweenA
  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 must carry the full burden. It explains the half-open nature and negative result behavior. However, it does not disclose the source of public holidays, potential rate limits, or whether the tool requires network access. These gaps lower 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, front-loaded with the core purpose, and contains no redundant words. All information is pertinent and efficiently conveyed.

  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 4 parameters, no annotations, and no output schema, the description is quite complete. It covers the core functionality, half-open interval, and negative results. A minor gap is the lack of mention of the holiday calendar source (e.g., defaults to US), but overall very good.

  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?

  With 100% schema description coverage, the baseline is 3. The description adds context about half-open interval and negative results, which relates to start_date and end_date, but does not add new information about country or subdivision beyond the schema. Value added is marginal.

  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 counts working days between two dates, excluding weekends and public holidays. It also explains the half-open interval, distinguishing it from siblings like is_business_day or next_business_day.

  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 provides basic usage context (half-open interval, negative results) but does not explicitly guide when to use this tool over siblings such as add_business_days or is_business_day. No exclusion criteria are mentioned.

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

• validate_recurrence_ruleA
  3.8/5.0
  Behavior3/5

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

  No annotations exist, so the description must carry the burden. It states 'Parsing only; nothing is scheduled,' indicating no side effects. However, it does not disclose the return format (e.g., boolean vs errors) or what 'supported' entails.

  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 primary purpose, and contains no superfluous information. Every word contributes value.

  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 validation tool with one parameter, the description is nearly complete. The missing output schema is a gap, but the context signal of 'no output schema' is noted. The 'nothing is scheduled' detail adds important context.

  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 covers the single parameter 'rule' with 100% description coverage. The tool description adds no additional semantic info beyond the schema's example and format specification.

  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 validates iCalendar recurrence rules (RRULE) for validity and support, and emphasizes it is parsing-only with no scheduling. This distinguishes it from sibling tools like 'explain_recurrence_rule' and 'next_recurrence_occurrences'.

  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 for validation via 'Check whether ... is valid', but does not explicitly state when to use it over siblings or when not to use it. No alternatives or exclusions are provided.

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

• add_business_daysA
  4/5.0
  Behavior4/5

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

  With no annotations, the description discloses key behaviors: it moves forward/backward, skips weekends and public holidays (implied by country/subdivision), allows negative numbers, and returns unchanged for zero. However, it does not mention any limitations like maximum range or holiday resolution details.

  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?

  Three short sentences, front-loaded with primary purpose. Each sentence adds value: main move, negative handling, zero case. No filler or redundant text.

  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 no output schema, the description could clarify return format (likely date string). But it covers core logic well. Context of 4 params and no enums/nesting makes this fairly complete for a calendar calculation 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?

  All 4 parameters are described in the schema (100% coverage). The description adds no extra semantics beyond the schema. For example, negative 'days' is already in schema description. Baseline 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?

  Description clearly states the tool moves a date by a number of business days, using 'move a number of working days forward or backward from a date'. It explicitly mentions skipping weekends and public holidays, and distinguishes from siblings like next_business_day (single day) and business_days_between (count). The verb 'move' and resource 'working days from a date' are specific.

  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?

  No explicit guidance on when to use this tool versus alternatives like next_business_day or previous_business_day. The description implies general offset scenarios but does not set exclusions or prerequisites. For a tool with many date siblings, this is a missed opportunity.

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

• next_cron_occurrencesA
  4/5.0
  Behavior3/5

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

  With no annotations, description provides key behavioral info: pure calculation, no side effects, up to 60 timestamps. But lacks details on error handling (invalid expression, timezone) and what happens if no future occurrences exist. Adequate but not comprehensive.

  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, no fluff. Front-loaded with the core functionality. Every word 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?

  Covers necessary aspects for a simple computation tool: purpose, input, output scope. Could mention error behavior or timezone but not critical. Given no output schema or annotations, it's reasonably 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 coverage is 100%, so the description adds little beyond the schema. It reinforces that 'start' is after which occurrences are computed and that expression is five-field. Baseline 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?

  Clear verb ('computes') and resource ('five-field cron expression') specified. Distinguishes from siblings by emphasizing it's a pure calculation with no side effects. The description explicitly mentions the action, input, and output format.

  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?

  Implicitly states when to use via 'no job is created, stored, or executed' but doesn't explicitly list alternatives or when not to use. However, the context of sibling tools like 'validate_cron_expression' is clear, so a slight deduction.

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

• sla_due_timeA
  4/5.0
  Behavior3/5

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

  With no annotations, the description covers key behaviors: counting only business hours, waiting outside hours, default hours, and locality. However, it fails to specify the return format (e.g., a datetime string).

  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 purpose, no redundancy. Every sentence adds value.

  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?

  Missing output schema and no description of return value or error conditions. For a tool with 6 parameters and no annotation support, more detail is needed.

  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 context about default behavior (09:00-17:00, wall-clock locality), enriching understanding beyond schema definitions.

  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 computes SLA due time using business hours and working days, distinguishing it from sibling tools like next_business_day or add_business_days.

  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?

  It describes when to use (SLA due time), but does not explicitly exclude alternatives or mention when not to use it, though implied by its specific function.

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

• explain_recurrence_ruleA
  4.2/5.0
  Behavior4/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 clearly states the tool is non-destructive and read-only ('Nothing is scheduled or executed'). This is sufficient for a simple explanation tool, though details about the output format (plain English description) are missing.

  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: two sentences that convey the purpose and key behavioral trait. No unnecessary 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?

  Given the tool's low complexity (single parameter, no output schema), the description covers the essential aspects: input format, action, and non-execution behavior. It differentiates from sibling tools like 'validate_recurrence_rule' and 'explain_cron_expression'. A minor gap is the lack of output description, but for a simple explanation it is acceptable.

  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% with a clear description of the 'rule' parameter including format and example. The tool description does not add extra meaning beyond the schema, so a baseline score 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 clearly states the tool's function: 'Describes an iCalendar recurrence rule (RRULE) in plain English.' The additional sentence 'Nothing is scheduled or executed' reinforces the scope and distinguishes it from scheduling-related siblings like 'next_recurrence_occurrences'.

  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 explicitly states that the tool only explains rules and does not schedule or execute anything, guiding the agent to use it for explanation purposes. It implicitly differentiates from siblings like 'explain_cron_expression' by specifying iCalendar RRULE, but does not list alternative tools for other cases.

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

• next_recurrence_occurrencesA
  4.2/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 clearly states the tool is a pure calculation with no side effects (creates no schedule, stores nothing, runs nothing) and lists the RRULE features it honours. This provides sufficient transparency for a simple computation 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 two sentences with no wasted words. The first sentence states the core purpose and supported features, while the second clarifies side-effect-free behavior. Perfectly front-loaded and efficient.

  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 output schema, no nested objects), the description covers purpose, supported features, and behavioral transparency. It omits output format and timezone handling, but for a straightforward computation tool, this is adequate. The pure calculation statement adds valuable context.

  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% with each parameter described. The description adds minimal extra meaning: it only reiterates the RRULE features for the 'rule' parameter and does not enhance understanding of 'count' or 'start' beyond the schema. Baseline of 3 is appropriate since schema already does the heavy lifting.

  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 expands an iCalendar recurrence rule into next occurrences from a start date and time, specifically naming supported RRULE parts (INTERVAL, COUNT, etc.). It distinguishes itself from sibling tools like explain_recurrence_rule (explanation) and validate_recurrence_rule (validation) by focusing on computation.

  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 use when you need to compute future occurrences without side effects, stating 'creates no schedule, stores nothing, and runs nothing.' While it does not explicitly say when not to use or list alternatives, the context of sibling tools (e.g., explain_cron_expression, validate_recurrence_rule) helps differentiate usage.

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

• explain_cron_expressionA
  4.4/5.0
  Behavior4/5

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

  The description explicitly states that the tool is read-only ('never schedules or executes anything'), which is crucial for behavioral safety. It also mentions supported features (ranges, lists, steps, names). Since no annotations are provided, the description carries the full burden, and it meets it well, though it could elaborate on error handling or invalid input 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 extremely concise—two sentences that efficiently state purpose, supported features, and a critical behavioral disclaimer. No unnecessary words or repetition.

  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 (single parameter, no output schema), the description is fairly complete. It explains input and behavior. However, it lacks explicit mention of the return format (plain English string), which could be inferred but is not stated. The sibling tools are similar, and the description provides enough differentiation.

  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 100% coverage with a description and example for the single parameter. The description adds meaning beyond the schema by specifying that the expression is 'five-field' and supports 'ranges, lists, steps, and month or weekday names,' which guides the agent on valid input patterns.

  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: 'Translate a five-field cron expression into plain English.' It uses a specific verb ('Translate') and resource ('cron expression'), and distinguishes itself from sibling tools like 'validate_cron_expression' (validation) and 'next_cron_occurrences' (computation).

  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: it supports ranges, lists, steps, and names, and explicitly states that it 'never schedules or executes anything.' This helps differentiate from tools that might schedule or execute. However, it does not explicitly list when not to use it or name alternatives beyond the negative scheduling statement.

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

• validate_cron_expressionA
  4.8/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It confirms no side effects ('nothing is scheduled or run') and that it is only syntactic validation. Could add detail on return format, but is sufficient for a simple check.

  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 that front-load the core purpose and immediately clarify the limitation. No wasted words.

  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?

  For a simple validation tool with one parameter and no output schema, the description is complete. It covers what it does, what it doesn't do, and the expected input format.

  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?

  The parameter 'expression' is fully described in the schema with an example. The description adds the context of 'five-field' cron expression, which complements the schema perfectly.

  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 checks whether a five-field cron expression is syntactically valid, using a specific verb and resource. It distinguishes itself from sibling tools that explain or compute occurrences.

  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 states 'Parsing only; nothing is scheduled or run,' which tells when to use it (for validation only) and when not to (for actual scheduling or execution).

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