Skip to main content
Glama

Cron Translator

by com.crontoenglish

Next cron run times

next_cron_runs
Read-only

List the next run times for a cron expression in a specific timezone, with no prose.

Use this when the only question is "when does this next fire" — for example to check whether a job will run before a deadline, or to show a user their upcoming schedule. Do not compute these dates yourself: weekday arithmetic, month lengths, and daylight-saving shifts make manual calculation unreliable.

Returns each run as a UTC ISO 8601 instant plus a local wall-clock rendering in the requested timezone. Refuses Quartz-only syntax (L, W, #, ?) rather than guessing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoHow many upcoming run times to return. 1-25, default 5.
timezoneNoIANA timezone name, for example "UTC", "America/New_York", or "Europe/Berlin". Cron expressions carry no timezone of their own, so this decides when the schedule actually fires. Defaults to UTC.UTC
expressionYesA standard five-field cron expression: "minute hour day-of-month month day-of-week", for example "0 9 * * 1-5". Accepts *, numbers, ranges (9-17), lists (1,15), steps (*/5), three-letter month and day names (JAN, MON), and the @daily, @hourly, @weekly, @monthly, @yearly macros. A six-field expression is accepted and its leading seconds field is reported as non-standard.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses the exact return shape (UTC ISO 8601 instant plus local wall-clock rendering), confirms timezone semantics, and states that Quartz-only syntax is refused rather than guessed. This gives the agent useful behavioral expectations without relying solely on annotations.

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 efficiently organized: a one-line summary, a usage rationale, a caution against manual computation, and then the return format and constraint. Every sentence adds necessary information, and the key purpose is front-loaded.

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?

With no output schema, the description adequately explains the return format. It covers the timezone behavior, unsupported syntax handling, and usage motivation, while the input schema handles parameter details. Nothing essential for correct invocation seems missing.

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 already provides 100% parameter coverage, so the baseline is satisfied. The description adds extra meaning by clarifying the expression behavior — specifically that unsupported Quartz syntax (L, W, #, ?) is rejected — and by reinforcing that the timezone determines when the schedule fires.

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 opens with a specific verb and resource: 'List the next run times for a cron expression in a specific timezone.' This clearly distinguishes the tool from its siblings build_cron and explain_cron, which presumably create or explain schedules rather than compute upcoming runs.

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 when to use this tool: when the only question is 'when does this next fire', with concrete examples like checking deadlines or showing schedules. It also warns against manual date computation. It does not name sibling tools or give explicit when-not-to-use conditions, but the context is clear enough.

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

All Cron Translator toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation4/5

build_cron is clearly distinct as the English-to-cron direction, but explain_cron and next_cron_runs both return upcoming run times. The descriptions draw a clear boundary between full explanation and bare run-times, so an agent can usually select correctly, though the overlap creates minor ambiguity.

Naming Consistency4/5

build_cron and explain_cron follow a clean verb_noun pattern with 'cron' as the object, but next_cron_runs breaks the pattern by leading with an adjective instead of a verb. The naming is still readable and predictable overall, just not perfectly uniform.

Tool Count5/5

Three tools is a well-scoped size for a cron translation server: one for English-to-cron, one for cron-to-explanation, and one for bare run-time lookup. Each tool has a clear purpose and none feels like filler.

Completeness4/5

The server covers both translation directions and schedule enumeration, which are the core workflows for its purpose. Minor gaps exist, such as lack of support for Quartz-style syntax in next_cron_runs and no standalone 'validate-only' tool, but explain_cron largely absorbs that need.

Resources