Runlater

This connector has been deprecated

Duplicate

create_cron

Run an HTTP request on a recurring schedule: a 5-field cron expression in UTC with a single minute value (at most once an hour) (e.g. "0 6 * * *" is daily at 06:00 UTC). Each run is an ordinary task (see get_task) and costs delivery attempts. Dead man's switch: if a run fails, or cannot start because the trial's attempts ran out or it ended, AgentLater POSTs a signed alert to alert_url, and again when a run next succeeds. To hear how runs went, pass callback_url (a URL, or "inbox" for read_inbox) and capture: true to keep each run's response; report: "failures" sends only failed runs, so a healthy cron stays quiet (and doesn't wake you via set_wake). A run that cannot start at all (attempts ran out, the trial ended) never reports; it turns the cron failing, which goes to alert_url, so set alert_url too ("inbox" works). Calling again with the same name replaces that cron's schedule and request. At most 10 crons.

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": {
      "name": "<name>",
      "schedule": "<schedule>",
      "url": "<url>"
    },
    "name": "create_cron"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes	https:// URL on a public domain name.
`body`	No	Request body for every run. Not allowed with GET.
`name`	Yes	The cron's name, e.g. "daily-backup".
`method`	No		POST
`report`	No	Which runs report to callback_url: every run, or only failed ones. "failures" needs callback_url.	always
`capture`	No	Keep each run's response (status, 4 headers, first 16 KiB), as schedule_http's capture. Untrusted data.
`headers`	No	Headers to send on every run. Same rules as schedule_http. A header value may use {{secret:NAME}} (see set_secret); AgentLater fills it in only when sending, to hosts the secret allows.
`schedule`	Yes	minute hour day-of-month month day-of-week, in UTC.
`alert_url`	No	https:// URL that gets a signed POST when the cron starts failing (cron.failing) and when it recovers (cron.recovered). Or "inbox" to get those events from read_inbox instead.
`callback_url`	No	Where each run reports when it finishes, as schedule_http's callback_url: a signed POST of task.finished to an https:// URL (one extra delivery attempt per report; one is reserved per run), or "inbox" (free).
`max_attempts`	No	Attempts per run.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 6, 2026

changedInput schema / properties / headers / description

Previous value: -"Headers to send on every run. Same rules as schedule_http. A header value may use {{secret:NAME}} (see set_secret); RunLater fills it in only when sending, to hosts the secret allows."New value: +"Headers to send on every run. Same rules as schedule_http. A header value may use {{secret:NAME}} (see set_secret); AgentLater fills it in only when sending, to hosts the secret allows."

First observedNov 3, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations at all, the description carries the full burden and does so: each run costs delivery attempts, a dead man's switch POSTs a signed alert on cron.failing and cron.recovered, and a run that cannot start never reports because it flips the cron to failing. It also discloses the 10-cron cap, upsert-by-name replacement, and that captured responses are untrusted data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose and scheduling constraint are front-loaded, and most of the density is justified for an async tool with 11 parameters. A few parenthetical-heavy sentences (the dead man's switch and the "cannot start at all" paragraph) restate the same alert_url routing twice, which is the main trimming opportunity.

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?

For a complex recurring tool with no annotations and no output schema, the description covers cost model, failure and recovery signaling, per-run reporting, secrets, name-based replacement, and the cron quota. The only thing left implicit is what create_cron itself returns, which is a minor gap against the depth of everything else.

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?

Schema coverage is 91%, so the baseline is 3; the description still adds meaning beyond the schema by explaining that schedule requires a single minute value (at most once an hour), that callback_url "inbox" is free while a URL costs an extra attempt, and that alert_url "inbox" works. The {{secret:NAME}} header substitution rule is only in the schema, so not every parameter gains from the prose.

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 opening sentence gives a precise verb and resource: "Run an HTTP request on a recurring schedule," and immediately narrows the schedule grammar (5-field cron, UTC, single minute value). The recurring nature plus repeated references to schedule_http's semantics make it clear this is the scheduled counterpart to the one-shot sibling, without needing to open either schema.

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 real operating context: at most 10 crons, calling again with the same name replaces the schedule and request, and a healthy cron can be kept quiet with report: "failures". It never explicitly says when to prefer schedule_http or create_hook instead, so the when-not guidance is implied by the word "recurring" 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 Runlater tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?