Skip to main content
Glama

ACTION_WAIT_UNTIL_TIME

Waits until a specified clock time or timestamp before continuing a workflow, polling every second and returning time_reached so automation can resume on schedule or handle a timeout.

Instructions

等待到指定时刻再继续(每秒轮询)。输出:time_reached, wait_until_time。执行器默认单节点超时 30 分钟:等待超过 29 分钟需同时设 node_timeout_ms=0(或足够大),否则 timeout_ms 会被截到 29 分钟。clock 模式下今天已过的时刻顺延到明天;超时后 time_reached=false 并继续 next。。字符串参数支持 ${var} 插值;结果以变量快照 JSON 返回。

Input Schema

NameRequiredDescriptionDefault
modeNoclock=钟点,timestamp=毫秒时间戳(默认 clock)
timeYes目标时刻:clock 模式为 HH:mm 或 HH:mm:ss,timestamp 模式为毫秒时间戳;支持 ${var}
requireNo执行后要求为 true 的变量名(如 click_success),不满足按出错处理
on_errorNo节点出错时:skip=跳过继续(默认),stop=停止整个工作流
output_varNo是否等到的结果变量名(time_reached 总会写)(默认 time_reached)
timeout_msNo最长等待毫秒(至少 1000);默认 29 分钟,设了 node_timeout_ms 时默认 12 小时
node_timeout_msNo单节点超时毫秒,0=不限;默认 30 分钟

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/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 it well: it discloses 1-second polling, the 30-minute executor timeout and its truncation of timeout_ms to 29 minutes, clock-mode day roll-over, and that on timeout time_reached=false and the workflow continues. Missing only edge cases such as a past timestamp in timestamp mode.

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?

Front-loaded with purpose, then caveats in decreasing importance, with no filler. Minor deductions for the duplicated full-width period ('next。。') and a trailing sentence about ${var} interpolation that is generic boilerplate across all tools.

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?

Covers the hard parts of a 7-parameter, annotation-free wait tool: output variable names, timeout semantics, and roll-over behavior. Without an output schema it also names the returned keys, leaving little an agent would need to guess before invoking it.

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 100%, so 3 is the baseline; the description goes beyond it by explaining the timeout_ms/node_timeout_ms interaction (truncation to 29 minutes), that time_reached is always written regardless of output_var, clock-mode roll-over for time, and ${var} interpolation for string parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and target: 'wait until the specified moment then continue (polling every second)', which is unambiguous and distinct from a relative pause. It never names the closest sibling (ACTION_DELAY) as the alternative for relative waits, so differentiation is left implicit.

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?

Gives concrete when-to-configure guidance: clock mode rolls a time already passed today to tomorrow, and waits over 29 minutes require node_timeout_ms=0 or a large value. It does not tell the agent when NOT to use this tool (e.g. use ACTION_DELAY for a fixed relative pause).

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