Clawhard Studio

Next cron run times in a timezone

tick_next_runs

Read-onlyIdempotent

Use when you or the user just wrote a cron expression (GitHub Actions, Vercel cron, Cloudflare Cron Triggers, systemd, an agent schedule) and need its next fire times. Pass the expression and an IANA timezone (default UTC). Returns the next N runs as local wall times and UTC ISO, a plain-English field breakdown, and DST gap/fold warnings (spring-forward skips, fall-back double fires). Example: {"expression":"0 9 * * 1-5","timezone":"America/New_York","count":5}. Uses the tz database, so DST rules match the region and year. Not for converting a meeting time across cities (use Meridian) or for email DNS (use Stamp).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "expression": "<expression>"
    },
    "name": "tick_next_runs"
  }
}

Input Schema

Name	Required	Description
`from`	No	Optional ISO datetime to start from (default now), e.g. 2026-03-07T12:00:00Z.
`count`	No	How many next runs to return (1–20). Default 5.
`timezone`	No	IANA timezone for local wall times, e.g. America/New_York. Default UTC.
`expression`	Yes	Cron expression: 5 fields (minute hour day-of-month month day-of-week) or 6 with seconds first. Also accepts @hourly, @daily, @weekly, @monthly, @yearly.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered by structured data rather than prose. The description does add genuinely useful behavior beyond that: it discloses the shape of the return value (local wall times, UTC ISO, plain-English field breakdown) and DST gap/fold warnings such as spring-forward skips and fall-back double fires, which is the real risk an agent must anticipate. That is above the bar for an annotated read-only tool, though it says nothing about invalid-expression errors or the 1-20 count ceiling behavior.

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?

Front-loaded with the trigger clause, then the output contract, then a compact example, then exclusions. Every sentence carries distinct information: no restated title, no filler, and the example is doing real work showing field names.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 must carry the return-value burden, and it does: run count, dual time representations, field breakdown, and DST hazard reporting. Error behavior for a malformed expression is the one gap, but for a pure read/compute tool with full annotation coverage and fully documented parameters this is close to complete.

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 of the four parameters documented including min/max bounds and the 5- vs 6-field cron format with @-macro shorthands. The description's contribution is largely an example invocation and a restatement of the UTC default already in the schema. Baseline 3 applies since the schema does the heavy lifting.

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+resource ('need its next fire times' for a cron expression) and scopes the domain (GitHub Actions, Vercel, Cloudflare, systemd). It also explicitly delimits itself against Meridian (time conversion) and Stamp (DNS), so an agent can pick it out of the sibling list without opening schemas.

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?

Opens with an explicit trigger condition ('Use when you or the user just wrote a cron expression ... and need its next fire times') and closes with when-not-to-use plus the named alternative for each exclusion. Nothing about selection is left to inference.

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

All Clawhard Studio tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?