Skip to main content
Glama

wake_when_idle

Wake when watched agents go idle or a timeout passes, holding delivery until pane input clears. Use one-shot for specific agents or a standing watch for all project workers.

Instructions

Wake up when watched agents go idle (exact state from Claude Code hooks) or max_wait_seconds passes - except delivery HOLDS past that bound instead, for as long as the target pane is on a dialog or has unsubmitted human text in it, rather than pasting the wake body into either (.claude/rules/tmux-and-panes.md). Two shapes, and you pass EXACTLY ONE of them. agents=[...] is a ONE-SHOT over a named list: mode=any fires on the first fresh idle transition, mode=all fires when every watched agent is idle (returns already_satisfied without scheduling anything if they all are now), and either way it stops watching once it fires. scope="project" is a STANDING WATCH over the crew you spawn in this project, including workers spawned later: it never stops watching, and on each finish it delivers a roster naming who finished and who is still going, until max_wait_seconds runs out or you wake_cancel it. You may hold ONE standing watch per project: a second call is refused and names the one already running, since two would report every finish twice. Use the standing watch when you are running more than one worker - a one-shot leaves every other worker unwatched from the moment it fires. Use either instead of polling. Refuses a lead target: a lead has no idle/working state channel.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYes
modeNoDefaults to any. Only meaningful with agents.
scopeNoWatch the crew you spawn in this project as a STANDING watch that keeps watching after each finish, including workers spawned later. Mutually exclusive with agents.
agentsNoAgents to watch, as a ONE-SHOT. Mutually exclusive with scope.
deliver_toNoDeliver to a spawned agent instead of this session.
project_idNoDifferent project override. Use ONLY when the user explicitly asks for another project by name; otherwise stay in the current scope, even when results are empty.
max_wait_secondsNoFor agents=[...]: how long to wait for idle before firing anyway, default 900. For scope="project": THE WATCH'S LIFETIME, default 14400 (4 hours), after which it delivers one last wake saying it has expired and stops watching. Not a hard deadline either way: delivery holds past it while the target pane is on a dialog or has unsubmitted text, until the pane clears.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo
noteNo
scopeNo
statusNo
wake_idNo
standingNo
watchingNo
deliver_toNo
expires_atNo
watching_nowNo
max_wait_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that one-shots stop watching after firing, standing watches never stop until timeout or wake_cancel, already_satisfied is returned when all agents are idle, delivery holds past max_wait_seconds under dialog/unsubmitted-text conditions, and duplicate standing watches are refused.

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 description is dense and every sentence carries information, but the opening sentence is a long run-on that packs the core purpose, timeout exception, delivery hold, and a rules-file reference into one hard-to-parse statement. The two-shape structure that follows is clear, but the front-loading hurts readability.

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 tool with two distinct behavioral modes, seven parameters, and an output schema, the description is remarkably complete. It explains lifecycle, timeout handling, delivery behavior, failure/refusal cases, and when to prefer each shape. The only real gap, body semantics, is minor and does not undermine call correctness.

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 high at 86%, and the description still adds meaningful semantics for mode, scope, max_wait_seconds defaults/lifetime, and agents/scope mutual exclusivity. However, the required body parameter is left entirely undocumented in both the schema and the description, preventing a perfect score.

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 identifies a specific verb and resource: wake up when watched agents go idle or when max_wait_seconds passes. It clearly distinguishes the two invocation shapes (one-shot agents vs standing scope) and frames the tool as a reactive subscription, setting it apart from siblings like wake_set or wake_list.

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?

It explicitly advises when to use the standing watch ('Use the standing watch when you are running more than one worker'), explains why a one-shot is insufficient in that case, and recommends 'Use either instead of polling.' It also states refusal conditions: duplicate standing watches and lead targets.

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