Runlater

This connector has been deprecated

Duplicate

watch_http

Hand off waiting on a long-running job: AgentLater polls a public https:// URL (now, then every 5m to 24h) until the response matches until, the deadline passes (at most 7d), or 3 polls in a row fail (408, 425, 429, 5xx, timeout, network). Any other 4xx, or a redirect, ends it at once. Each poll costs one delivery attempt, taken as it runs, not reserved up front: a long watch can use up attempts other tasks are waiting for. The watch is a task: get_task shows its progress under watch, cancel_task stops it, and callback_url receives a signed POST with the result, including the matched value and up to 16 KiB of the last response body. Headers (e.g. an API token) are deleted when it ends. Pass on_match to act without waiting for your next turn: when (and only when) until matches, AgentLater sends that one request as an ordinary task, linked by watch.action_task_id and triggered_by. Its attempt (and its callback's) is reserved when the watch is created; a timeout, failure or cancel sends nothing.

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": {
      "url": "<url>",
      "every": "<every>",
      "until": "<until>",
      "deadline": "<deadline>"
    },
    "name": "watch_http"
  }
}

Input Schema

Name	Required	Description	Default
`url`	Yes	https:// status URL on a public domain name.
`body`	No	Request body for every poll. Not allowed with GET.
`every`	Yes	Time between polls, from "5m" to "24h". The first poll is immediate.
`until`	Yes	When the job is done. path + in: a 2xx JSON response has one of these values at this JSON Pointer, e.g. { "path": "/status", "in": ["succeeded", "failed"] }. status: the response status is one of these, e.g. { "status": [404] } to wait until something is gone. Given both, both must hold. Only the first 64 KiB of a response is read.
`method`	No		GET
`headers`	No	Headers to send on every poll, e.g. Authorization. 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.
`deadline`	Yes	Stop polling after this long, e.g. "6h"; at least one interval, at most "7d".
`on_match`	No	A request to send once, as soon as the watch matches, e.g. start the smoke tests when a deploy reports SUCCEEDED. It is a task like schedule_http's: signed, retried, shown by get_task, reporting to its own callback_url. It is sent at least once, so the receiver should dedupe on RunLater-Task-Id. Not sent if cancel_task was called while the matching poll was out (watch.action_skipped: "canceled"). Its header values and body are deleted from the watch when it ends.
`callback_url`	No	https:// URL that receives a signed POST with the watch's final state, or "inbox" for read_inbox.
`idempotency_key`	No	Repeat a call with the same key and request to get the same watch back.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 6, 2026

changedInput schema / properties / headers / description

Previous value: -"Headers to send on every poll, e.g. Authorization. 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 poll, e.g. Authorization. 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."

changedInput schema / properties / on_match / properties / headers / description

Previous value: -"Headers to send. 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. 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.5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: exact failure-tolerance policy (3 consecutive 408/425/429/5xx/timeout/network, any other 4xx or redirect ends instantly), the 7d cap, per-poll attempt consumption taken as it runs (a real cost/contention warning), header deletion at end, and cancel semantics mid-poll. It also discloses the delivery contract — signed callback POST with matched value and up to 16 KiB of the last body — and that the watch appears under get_task.

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?

Effectively one dense paragraph, but it is front-loaded: the polling mechanism and termination rules come before the on_match elaboration, and nearly every clause adds a distinct operational fact. The run-on density (multiple semicolon-joined rules in single sentences) makes it harder to scan than it needs to be.

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?

For a 10-parameter tool with nested objects, no output schema, and no annotations, the description covers lifecycle, cost, cancellation, and callback behavior well enough to invoke safely. The remaining gap is the synchronous return value of the call itself — presumably a watch/task identifier — which is never mentioned and cannot be inferred from an absent output schema.

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 description coverage is 90%, so the schema already defines most fields; the description's value is in explaining the on_match lifecycle beyond the schema — that the action is a separate task linked by watch.action_task_id/triggered_by, that its attempt and callback are reserved at watch creation, and that a timeout, failure, or cancel sends nothing. It doesn't clarify the top-level response (what the create call returns), which is left implicit.

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 precise verb-and-resource framing ("Hand off waiting on a long-running job: AgentLater polls a public https:// URL") and immediately scopes the mechanism (interval 5m–24h, deadline cap, termination conditions). An agent can distinguish this from sibling HTTP tools like schedule_http/queue_http because the defining behavior — repeated polling until a match predicate holds — is stated up front.

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 gives clear situational context: use it when you need to wait on a long-running job without holding a turn, and it explicitly recommends on_match when the agent should act without waiting for its next turn. It never states exclusions or contrasts against the closest alternatives (schedule_http, queue_http), leaving the agent to infer which HTTP tool fits.

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?