mcp-tools

Cron next runs

cron_next_runs

Read-onlyIdempotent

Preview up to 10 upcoming cron matches after a UTC instant to validate scheduler syntax and see run times without installing a schedule.

Instructions

Preview up to 10 cron matches strictly after a supplied UTC instant, within a 366-day search. Use to check existing scheduler syntax; use recurring_schedule to draft task recurrence calendars or meeting_time_zones for participant overlap. Returns UTC starts, local labels, normalized inputs and a dated syntax source; fewer matches or [] means the search window ended. Supports numeric stars, lists, ranges, steps and weekday names in the selected dialect; rejects L, W, # and named months. cloudflare requires UTC; other zones follow runtime daylight saving transitions. No schedule is installed or run.

Input Schema

TableJSON Schema

Name	Required	Description
`zone`	Yes	IANA time zone for matching local cron fields. cloudflare requires UTC. Daylight saving transitions follow the runtime time-zone database.
`after`	Yes	UTC ISO instant from 2000 through 2100; matches are strictly after this instant. Only Z offsets are accepted.
`count`	Yes	Maximum matches to return. The list may be shorter or empty if no further matches occur within the 366-day search.
`dialect`	Yes	Scheduler syntax and weekday numbering. github uses 0 or 7 for Sunday and 1–6 for Monday–Saturday; the others use 1–7 for Sunday–Saturday.
`expression`	Yes	Cron fields in the selected dialect: five for github/cloudflare, six or seven for quartz, six for aws (optional cron(...) wrapper). Supports *, lists, ranges, steps and weekday names; rejects L, W, # and named months. Quartz/aws require ? in exactly one day field.

Output Schema

TableJSON Schema

Name	Required	Description
`runs`	Yes	Chronological cron matches strictly after after, up to count; may be shorter or empty within the search window.
`tool`	Yes	Calculator identifier for this result.
`input`	Yes	Normalized inputs used for this calculation.
`method`	Yes	Calculation or ranking method applied to the inputs.
`provenance`	Yes	Dated data sources or runtime time-zone information used for this result.
`searchDays`	Yes	Maximum search window in days.
`assumptions`	Yes	Limits and assumptions to retain when presenting the result.

Schema Changelog

Changes observed during successful MCP inspections.

Changed38 schema fields changedv1.1.0Oct 3, 2026

changedInput schema / properties / after / description

Previous value: -"UTC ISO instant from 2000 through 2100; matches are strictly after this instant."New value: +"UTC ISO instant from 2000 through 2100; matches are strictly after this instant. Only Z offsets are accepted."

addedInput schema / properties / after / examples
```
Added value: +[
+  "2026-10-02T00:00:00Z"
+]
```
changedInput schema / properties / after / maxLength
```
Previous value: -30New value: +24
```
addedInput schema / properties / after / minLength
```
Added value: +20
```

addedInput schema / properties / after / pattern

Added value: +"^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}(?:\\.\\d{1,3})?Z$"

addedInput schema / properties / count / description

Added value: +"Maximum matches to return. The list may be shorter or empty if no further matches occur within the 366-day search."

addedInput schema / properties / count / examples
```
Added value: +[
+  3
+]
```

addedInput schema / properties / dialect / description

Added value: +"Scheduler syntax and weekday numbering. github uses 0 or 7 for Sunday and 1–6 for Monday–Saturday; the others use 1–7 for Sunday–Saturday."

addedInput schema / properties / dialect / examples
```
Added value: +[
+  "github"
+]
```

addedInput schema / properties / expression / description

Added value: +"Cron fields in the selected dialect: five for github/cloudflare, six or seven for quartz, six for aws (optional cron(...) wrapper). Supports *, lists, ranges, steps and weekday names; rejects L, W, # and named months. Quartz/aws require ? in exactly one day field."

addedInput schema / properties / expression / examples
```
Added value: +[
+  "0 9 * * 1-5"
+]
```

addedInput schema / properties / zone / description

Added value: +"IANA time zone for matching local cron fields. cloudflare requires UTC. Daylight saving transitions follow the runtime time-zone database."

addedInput schema / properties / zone / examples

Added value: +[
+  "UTC",
+  "America/New_York"
+]

addedOutput schema / description

Added value: +"Bounded cron preview with normalized syntax, UTC starts, local labels and scheduler source."

addedOutput schema / properties / assumptions / description

Added value: +"Limits and assumptions to retain when presenting the result."

addedOutput schema / properties / input / description

Added value: +"Normalized inputs used for this calculation."

changedOutput schema / properties / input / properties / after / description

Previous value: -"UTC ISO instant from 2000 through 2100; matches are strictly after this instant."New value: +"UTC ISO instant from 2000 through 2100; matches are strictly after this instant. Only Z offsets are accepted."

addedOutput schema / properties / input / properties / after / examples
```
Added value: +[
+  "2026-10-02T00:00:00Z"
+]
```
changedOutput schema / properties / input / properties / after / maxLength
```
Previous value: -30New value: +24
```
addedOutput schema / properties / input / properties / after / minLength
```
Added value: +20
```

addedOutput schema / properties / input / properties / after / pattern

Added value: +"^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}(?:\\.\\d{1,3})?Z$"

addedOutput schema / properties / input / properties / count / description

Added value: +"Maximum matches to return. The list may be shorter or empty if no further matches occur within the 366-day search."

addedOutput schema / properties / input / properties / count / examples
```
Added value: +[
+  3
+]
```

addedOutput schema / properties / input / properties / dialect / description

Added value: +"Scheduler syntax and weekday numbering. github uses 0 or 7 for Sunday and 1–6 for Monday–Saturday; the others use 1–7 for Sunday–Saturday."

addedOutput schema / properties / input / properties / dialect / examples
```
Added value: +[
+  "github"
+]
```

addedOutput schema / properties / input / properties / expression / description

Added value: +"Cron fields in the selected dialect: five for github/cloudflare, six or seven for quartz, six for aws (optional cron(...) wrapper). Supports *, lists, ranges, steps and weekday names; rejects L, W, # and named months. Quartz/aws require ? in exactly one day field."

addedOutput schema / properties / input / properties / expression / examples
```
Added value: +[
+  "0 9 * * 1-5"
+]
```

addedOutput schema / properties / input / properties / zone / description

Added value: +"IANA time zone for matching local cron fields. cloudflare requires UTC. Daylight saving transitions follow the runtime time-zone database."

addedOutput schema / properties / input / properties / zone / examples
```
Added value: +[
+  "UTC",
+  "America/New_York"
+]
```

addedOutput schema / properties / method / description

Added value: +"Calculation or ranking method applied to the inputs."

addedOutput schema / properties / provenance / description

Added value: +"Dated data sources or runtime time-zone information used for this result."

addedOutput schema / properties / provenance / properties / checked / description
```
Added value: +"Date the referenced catalog or scheduler source was checked."
```
addedOutput schema / properties / provenance / properties / sourceUrl / description
```
Added value: +"Official rate or scheduler syntax reference URL."
```

addedOutput schema / properties / runs / description

Added value: +"Chronological cron matches strictly after after, up to count; may be shorter or empty within the search window."

addedOutput schema / properties / runs / items / properties / label / description
```
Added value: +"Start formatted in the requested IANA time zone."
```
addedOutput schema / properties / runs / items / properties / startUtc / description
```
Added value: +"Start instant in ISO 8601 UTC."
```
addedOutput schema / properties / searchDays / description
```
Added value: +"Maximum search window in days."
```

addedOutput schema / properties / tool / description

Added value: +"Calculator identifier for this result."

First observedv1.0.0Oct 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, and the description adds substantial extra context: no schedule is installed or run, the 366-day window bound, that fewer matches or [] means the window ended, dialect-specific rejection rules (L, W, #, named months), and that cloudflare requires UTC while other zones follow runtime DST transitions.

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?

Purpose and window bound are front-loaded, and each subsequent sentence carries a distinct constraint (dialect limits, zone rules, no side effects). It is dense but not padded, though the return-shape sentence is partly redundant with the output schema.

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 read-only preview tool with full schema coverage and an output schema, the description covers everything an agent needs: what is matched, the search bound, dialect/zone caveats, and the absence of side effects. The return-value sentence is extra but harmless.

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% and the schema already documents dialect numbering, the ? requirement for quartz/aws, the Z-only constraint on 'after', and the 366-day/count semantics. The description largely restates these ('Supports numeric stars, lists, ranges, steps and weekday names... rejects L, W, # and named months'), so it earns the baseline 3 rather than more.

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?

States a specific verb and resource ('Preview up to 10 cron matches strictly after a supplied UTC instant, within a 366-day search') and explicitly distinguishes itself from siblings recurring_schedule and meeting_time_zones by naming what each of those is for instead.

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?

Gives explicit when-to-use ('Use to check existing scheduler syntax') plus named alternatives with their selecting conditions ('recurring_schedule to draft task recurrence calendars or meeting_time_zones for participant overlap'), so routing is unambiguous.

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

Deploy Server