Loading ToolBench
Validates cron/schedule expressions and computes correct next-fire times across timezones, catching DST gap/overlap footguns that silently skip or double-fire scheduled jobs
Three well-named tools with strong descriptions (150 - 250 chars each) and complete input schemas. All parameters have types and descriptions. Tool names follow verb_noun pattern (validate_, detect_, get_). Schemas use Zod validation. However, output schemas are not explicitly documented in the source, only inferred from code logic. Error handling exists but lacks recovery guidance (e.g., 'Invalid cron expression' does not suggest next steps). No tool annotations (readOnlyHint, idempotentHint) despite all three being read-only operations. Parameter descriptions are good but could specify constraints more formally (e.g., daysToScan range, count max).
Scans a cron expression over a date range in a given timezone to detect DST (Daylight Saving Time) gaps (spring-forward, where a scheduled time never happens) and overlaps (fall-back, where a scheduled time happens twice). Returns verdict and list of affected dates.
Computes the next N fire times for a cron expression in a given timezone, accounting for DST transitions. Returns a list of ISO 8601 timestamps with wall-clock times and UTC equivalents.
Validates a cron expression and returns detailed analysis including normalization, human-readable explanation, and footgun warnings (DOM+DOW OR logic, every-minute, day-31 in short months, etc.)
Output schemas not documented. Tool descriptions explain what is returned (e.g., 'Returns verdict and list of affected dates'), but the actual JSON structure is not formally specified. LLMs cannot plan downstream operations without knowing field names and types.
No tool annotations. All three tools are read-only (no side effects), but readOnlyHint is not set. This prevents agents from understanding which tools are safe to call speculatively or in dry-run mode.
Error messages lack recovery guidance. When cron parsing fails, the error states what is wrong but does not suggest next steps (e.g., 'Invalid cron expression. Try @hourly, @daily, or a 5-field format: minute hour day month dow').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | A | 84 | 2026-07-28+ | v2 |
Parameter constraints not fully specified. daysToScan and count have defaults and max values mentioned in descriptions, but no formal min/max in schema. LLMs may pass invalid values (e.g., daysToScan=0 or count=1000).
No pagination or result limits documented for get_next_fire_times. While count defaults to 5 and maxes at 100, the response structure (array of timestamps) is not formally defined, making it hard for LLMs to plan multi-call sequences.