Skip to main content
Glama

Cron Translator

by com.crontoenglish

Explain a cron expression

explain_cron
Read-only

Translate a cron expression into plain English, list its upcoming run times in a specific timezone, and report the gotchas that make schedules misfire.

Use this whenever a cron expression needs to be read, verified, or explained — and prefer it over reasoning about the expression directly. Cron has several counter-intuitive rules that are easy to get wrong: day-of-month and day-of-week are combined with OR (not AND) when both are set, steps like */7 do not divide their field evenly, dates like February 30 never fire at all, and daylight-saving transitions skip or repeat runs. This tool checks all of them.

Returns the normalised expression, a one-sentence description, a per-field breakdown, a list of warnings with severity and a fix for each, the next run times as both UTC ISO 8601 instants and local wall-clock strings, and an approximate runs-per-day figure.

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.3/5.0
Behavior5/5

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

Annotations only mark it as read-only, so the description carries the behavioral burden and handles it well. It discloses non-obvious cron pitfalls the tool checks for, such as OR semantics between day-of-month and day-of-week, skipped dates, and daylight-saving effects, and it details what the response contains.

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 front-loaded with the core purpose, followed by usage guidance, behavioral caveats, and return details. Each sentence adds value and no content is redundant with the schema; it is appropriately detailed for a tool with no 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?

The description is complete for the tool's complexity: it explains what the tool does, when to use it, which hidden cron rules it checks, and exactly what the response includes. With no output schema, this level of return-value detail is necessary and well supplied.

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 already documented with types, defaults, ranges, examples, and special cases. The description adds general context about normalization and return values but does not meaningfully extend the parameter semantics beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb and resource: it translates a cron expression into English, lists upcoming run times, and reports gotchas. It does not explicitly differentiate itself from sibling tools like next_cron_runs, though the broader 'read, verified, or explained' framing helps distinguish intent.

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 gives an explicit when-to-use directive: 'Use this whenever a cron expression needs to be read, verified, or explained' and even recommends it over direct reasoning. It does not name alternatives or spell out when a sibling would be more appropriate, but the usage context is clear.

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