Skip to main content
Glama

watch_http

Hand off waiting on a long-running job: RunLater 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, RunLater 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.

Input Schema

NameRequiredDescriptionDefault
urlYeshttps:// status URL on a public domain name.
bodyNoRequest body for every poll. Not allowed with GET.
everyYesTime between polls, from "5m" to "24h". The first poll is immediate.
untilYesWhen 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.
methodNoGET
headersNoHeaders 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.
deadlineYesStop polling after this long, e.g. "6h"; at least one interval, at most "7d".
on_matchNoA 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_urlNohttps:// URL that receives a signed POST with the watch's final state, or "inbox" for read_inbox.
idempotency_keyNoRepeat a call with the same key and request to get the same watch back.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are supplied, and the description carries the full load admirably: it discloses the exact failure taxonomy (3 consecutive failures on 408/425/429/5xx/timeout/network, immediate termination on other 4xx or redirect), the attempt-consumption model (taken as it runs, not reserved), header deletion on completion, callback payload contents, and at-least-once delivery with dedupe on RunLater-Task-Id. This is behavior an agent could not infer from the schema alone.

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?

Long but dense—nearly every sentence delivers distinct information (failure rules, attempt accounting, lifecycle, on_match linkage). The lead sentence is front-loaded with purpose. A few clauses are tightly packed and could be split for readability, but there is minimal filler relative to the tool's complexity.

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 10-parameter, nested-object tool with no annotations and no output schema, the description covers the gaps that matter: termination conditions, attempt accounting, progress/cancellation path, callback result contents (matched value plus up to 16 KiB of last body), and on_match side effects. An agent has enough to invoke it correctly without external context.

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 already 90%, so the schema does most of the work, but the description adds genuine meaning: on_match is described as an ordinary task linked by watch.action_task_id and triggered_by whose attempt is reserved at watch creation, and `until` is characterized via the matching semantics. It stops short of adding detail for parameters like idempotency_key or the method enum, which remain schema-only.

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?

Opens with a specific verb+resource framing ("Hand off waiting on a long-running job") and immediately defines the mechanism: polling a public https:// URL until the response matches `until`, the deadline passes, or 3 consecutive polls fail. This is clearly distinguishable from schedule_http (recurring scheduled request) and from get_task/cancel_task, so an agent can route to the right tool without opening the 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?

States the use case explicitly (offload waiting on a long-running job), then explains the key alternative branch: use on_match to act immediately without waiting for the agent's next turn, and notes that a timeout/failure/cancel sends nothing. It references related tools (get_task, cancel_task, schedule_http, set_secret) but does not give an explicit "use this instead of schedule_http when..." comparison or a clear when-not-to-use statement.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.