Parse, validate, and explain cron expressions. Get next N run times in any timezone.
Single tool with clear naming (schedule_parse_cron) and well-structured schema. Description is detailed (195 chars) and explains use cases with explicit non-use guidance. Input schema properly typed with required field and reasonable defaults. However, output schema is not documented in the tool definition, only inferred from code. No error handling guidance in description. Parameter descriptions are adequate but lack format/constraint details (e.g., timezone format, count range). Tool is read-only and low-risk, but lacks production-grade error recovery patterns.
Use this when you need to parse, validate, or explain a cron expression. Returns human-readable description, next N execution times, and field breakdown. Supports standard 5-field cron and extended 6-field (with seconds). Do NOT use for scheduling tasks — use api_test_webhook instead. Do NOT use for JSON validation — use data_validate_json instead.
Output schema not documented in tool definition. LLMs cannot plan downstream operations or extract fields without knowing response structure (breakdown, nextRuns, hasSeconds fields).
Parameter 'timezone' lacks format specification. Description says 'IANA timezone' but does not state format, validation rules, or what happens on invalid input. LLMs may pass malformed values.
Parameter 'count' lacks explicit min/max in description. Schema shows no constraints; code enforces 1 - 20 but description only mentions 'default: 5, max: 20'. LLMs may pass 0 or negative values.
No error recovery guidance in tool description. If cron expression is invalid, description does not tell LLM what to do next or how to fix it.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2025-06-18+ | v2 |
Timezone parameter is optional but behavior on omission is not explicit. Code defaults to UTC, but description should state this clearly to prevent LLM confusion.