Skip to main content
Glama

Cron Translator

by com.crontoenglish

Build a cron expression from English

build_cron
Read-only

Convert an English schedule description into a standard five-field cron expression, then explain and validate the result.

Use this when a user describes a schedule in words and needs the expression. This is a RULE-BASED converter, not a language model: it handles a fixed grammar and returns an error listing the supported phrasings when a phrase falls outside it. That refusal is deliberate — a plausible-looking wrong schedule is worse than no answer. If a phrase is rejected, rephrase it into one of the supported shapes and call again.

Returns the expression, which rule matched, any words the rules did not use (check these — leftover words may mean the phrase was misread), the English description of the result, warnings, and the next run times.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
phraseYesAn English schedule description, for example "every weekday at 9am" or "on the 1st of every month at midnight". Times accept 24-hour ("14:30"), 12-hour ("2:30pm"), "midnight", and "noon".
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

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?

The description discloses important behavioral traits beyond the readOnlyHint annotation: it is rule-based rather than a language model, it deliberately refuses out-of-grammar phrases because wrong schedules are dangerous, and it warns about leftover words that may indicate misreading. It also enumerates the returned fields, including warnings and next run times.

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 compact yet information-dense. The first sentence states the core purpose, and the following sentences each add necessary operational detail: when to use it, how refusal behaves, how to recover, and what the response contains. No filler or repetition.

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?

Even without an output schema, the description fully prepares an agent to call the tool: input format, timezone semantics, failure behavior, retry guidance, and a complete list of returned fields. It also warns about the subtle risk of unparsed words, which is exactly the kind of context an agent needs.

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 covers both parameters well with examples, so the baseline is 3. The description adds extra value by explaining why timezone matters — cron expressions carry no timezone, so it decides when the schedule actually fires — and by framing phrase as the English schedule to be interpreted.

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: converting an English schedule description into a standard five-field cron expression, then explaining and validating it. This clearly distinguishes build_cron from siblings like explain_cron and next_cron_runs, which handle different directions of cron-related work.

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?

It explicitly states when to use the tool: 'Use this when a user describes a schedule in words and needs the expression.' It also gives recovery guidance for rejected phrases. However, it does not explicitly name the sibling alternatives or state when not to use them, so exclusions are implied rather than stated.

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