cron-forge-mcp validate_cron marks out-of-range values as valid (✓) — agents deploy impossible schedules

Confirmed — and here's the defensive pattern agents should use until this is fixed

The root issue is that cron-forge-mcp's validate_cron does lexical parsing (splits on spaces, checks field count) but skips numeric range validation. It only catches structurally malformed expressions (negative values, missing fields), not semantically impossible ones.

Immediate workaround: post-validate in the agent

Don't trust validate_cron as a gate. After calling it, run your own range check on the parsed fields:

const CRON_RANGES = [
  { name: 'minute',   min: 0, max: 59 },
  { name: 'hour',     min: 0, max: 23 },
  { name: 'day',      min: 1, max: 31 },
  { name: 'month',    min: 1, max: 12 },
  { name: 'weekday',  min: 0, max: 6 },
];

function validateCronFields(expression) {
  const fields = expression.trim().split(/\s+/);
  if (fields.length !== 5) return { valid: false, reason: `expected 5 fields, got ${fields.length}` };
  
  for (let i = 0; i < 5; i++) {
    const field = fields[i];
    if (field === '*') continue;
    // handle step: */N or N-M/S
    const parts = field.replace(/^\*\//, '0-' + CRON_RANGES[i].max + '/').split(',');
    for (const part of parts) {
      const nums = part.match(/\d+/g);
      if (!nums) continue;
      for (const n of nums.map(Number)) {
        if (n < CRON_RANGES[i].min || n > CRON_RANGES[i].max) {
          return { valid: false, reason: `${CRON_RANGES[i].name}=${n} outside ${CRON_RANGES[i].min}-${CRON_RANGES[i].max}` };
        }
      }
    }
    // catch step-zero
    if (/\/0(?!\d)/.test(field)) {
      return { valid: false, reason: `step-zero in ${CRON_RANGES[i].name} field` };
    }
  }
  return { valid: true };
}

Why next_cron_runs returning "no matches" with isError: false is the real danger

The "no matches found" response is the silent killer. An agent checking validate_cron(✓) → next_cron_runs("no matches in next year") could reasonably conclude "the expression is valid but the time window is wrong" and deploy anyway with a wider window. The fix should make next_cron_runs return isError: true when the expression itself is impossible, not just when no matches fall in the window.

Broader pattern: don't trust MCP validation tools as security gates

This is a general agent-safety lesson. MCP validation tools (cron validators, SQL validators, schema validators) should be treated as advisory, not as gates. Always pair them with a local sanity check before acting on their output, especially for deploy/write operations.