AgentNave

Overview Schema Source Related Servers Discussions Admin

Wait for tasks or rounds

wait

Read-onlyIdempotent

Block until dispatched subagent tasks or rounds become ready, then collect terminal results and surface blockers or pending reviews.

Instructions

Return when any handle is ready; reason=ready contains all ready now in updates (tasks) and rounds, not necessarily all finished.

Ready: terminal; execution_blocked (still running; once/category); review_needed (pending_review needs decide_answers); seat_lost (failed/blocked seat while peers run; once/seat, answers withheld; retry via run_round.retry_seats). pending_ids lists unreceived ends for the given ids or inbox; all_finished means none remain. Handle blockers/reviews, then wait on pending_ids until all_finished; drop delivered handles. Ends are never pushed: wait after dispatch or independent work; collect every terminal result before ending your turn. wait_elapsed gives status/activity; wait again normally. Only wait_seconds=0 adds running tails (up to 1000 characters) and age, subject to include_output. Round answers arrive once; output_returned means reread with read_conversation. Unknown/expired/duplicate ids reject the whole call. Inbox ends arrive once; reviews stay ready until decided; nothing_pending means an empty inbox.

Input Schema

Name	Required	Description
`ids`	No	Distinct invocation_ids/round_ids; omit for this server inbox of unreceived tasks and rounds.
`wait_seconds`	No	Omit to wait up to 240s; 0 checks progress immediately and includes running tails; ready results are still received; neither value stops work.
`include_output`	No	false omits reply bodies and tails, including answers under review.
`manager_session_id`	No	Inbox chat filter when ids is omitted; ignored with ids; identity rules in MCP instructions.

Output Schema

Name	Required	Description	Default
`reason`	Yes
`rounds`	Yes
`updates`	Yes
`pending_ids`	Yes
`all_finished`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.65.0Nov 2, 2026

changedInput schema / properties / ids / description

Previous value: -"Distinct invocation_ids from start_agent and round_ids from run_round. Omit to wait on the inbox: every task and round of this server whose end you have not received yet."New value: +"Distinct invocation_ids/round_ids; omit for this server inbox of unreceived tasks and rounds."

changedInput schema / properties / manager_session_id / description

Previous value: -"With ids omitted, only this boss chat's tasks and rounds; same value as start_agent and run_round. Ignored with ids."New value: +"Inbox chat filter when ids is omitted; ignored with ids; identity rules in MCP instructions."

changedInput schema / properties / wait_seconds / description

Previous value: -"Omit for normal waiting (up to 240 seconds). Only 0 and 240 are accepted. Use 0 for a specific progress or intervention check: it returns at once and may include running reply tails. Ready results are still received normally. Never stops the work."New value: +"Omit to wait up to 240s; 0 checks progress immediately and includes running tails; ready results are still received; neither value stops work."

changedOutput schema / $defs / InvocationPayload / required

Previous value: -[
-  "invocation_id",
-  "status",
-  "reason",
-  "elapsed_ms"
-]New value: +[
+  "invocation_id",
+  "status",
+  "reason"
+]

addedOutput schema / properties / all_finished

Added value: +{
+  "title": "All Finished",
+  "type": "boolean"
+}

addedOutput schema / properties / pending_ids

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "title": "Pending Ids",
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "reason",
-  "updates",
-  "rounds"
-]New value: +[
+  "reason",
+  "pending_ids",
+  "all_finished",
+  "updates",
+  "rounds"
+]

Changed2 schema fields changedv0.58.0Oct 31, 2026

changedInput schema / properties / wait_seconds / anyOf

Previous value: -[
-  {
-    "maximum": 300,
-    "minimum": 0,
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      0,
+      240
+    ],
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / wait_seconds / description

Previous value: -"Longest wait in seconds, 300 when omitted; 0 returns at once, with the ready handles or a running snapshot of each. Never stops the work."New value: +"Omit for normal waiting (up to 240 seconds). Only 0 and 240 are accepted. Use 0 for a specific progress or intervention check: it returns at once and may include running reply tails. Ready results are still received normally. Never stops the work."

Changed3 schema fields changedv0.53.1Oct 29, 2026

addedOutput schema / $defs / InvocationPayload / properties / warnings

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "title": "Warnings",
+  "type": "array"
+}

addedOutput schema / $defs / SeatRunPayload / properties / output_returned
```
Added value: +{
+  "title": "Output Returned",
+  "type": "boolean"
+}
```

addedOutput schema / $defs / SeatRunPayload / properties / warnings

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "title": "Warnings",
+  "type": "array"
+}

Changed1 schema field changedv0.49.0Oct 27, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```

Changed10 schema fields changedv0.41.0Oct 25, 2026

addedInput schema / properties / ids / anyOf

Added value: +[
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / ids / default
```
Added value: +null
```

changedInput schema / properties / ids / description

Previous value: -"Distinct invocation_ids from start_agent and round_ids from run_round."New value: +"Distinct invocation_ids from start_agent and round_ids from run_round. Omit to wait on the inbox: every task and round of this server whose end you have not received yet."

removedInput schema / properties / ids / items
```
Removed value: -{
-  "type": "string"
-}
```
removedInput schema / properties / ids / minItems
```
Removed value: -1
```
removedInput schema / properties / ids / type
```
Removed value: -"array"
```

addedInput schema / properties / manager_session_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "With ids omitted, only this boss chat's tasks and rounds; same value as start_agent and run_round. Ignored with ids.",
+  "title": "Manager Session Id"
+}

addedInput schema / properties / wait_seconds

Added value: +{
+  "anyOf": [
+    {
+      "maximum": 300,
+      "minimum": 0,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Longest wait in seconds, 300 when omitted; 0 returns at once, with the ready handles or a running snapshot of each. Never stops the work.",
+  "title": "Wait Seconds"
+}

removedInput schema / required
```
Removed value: -[
-  "ids"
-]
```

changedOutput schema / properties / reason / enum

Previous value: -[
-  "ready",
-  "wait_elapsed"
-]New value: +[
+  "ready",
+  "wait_elapsed",
+  "nothing_pending"
+]

Addedv0.35.0Oct 24, 2026

TDQS

A4/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: up-to-240s blocking without stopping work, one-shot delivery of results and inbox ends, reviews staying ready until decided, and whole-call rejection on unknown/expired/duplicate ids. This is the kind of operational context annotations cannot express.

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

Conciseness3/5

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

Dense, run-on and jargon-heavy: 'handle', 'ends', 'tails' and 'once/seat' are used before being explained, forcing re-reads. The content largely earns its place, but the structure is a wall of clauses rather than front-loaded statements, which hurts scanability for a tool that will be called frequently.

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 stateful blocking tool with an output schema, the description covers the state machine, delivery-once semantics, error rejection and post-call workflow. Remaining gaps are terminological (undefined 'handle'/'ends') rather than missing operational facts an agent needs to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds a little beyond the schema — the 1000-character tail cap, that age accompanies running tails, and that ready results are still received with wait_seconds=0 — but most parameter meaning is already in the schema fields themselves.

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 action and object ('Return when any handle is ready') and enumerates the ready-state outcomes (terminal, execution_blocked, review_needed, seat_lost), which tells an agent this is a blocking poll rather than a fetch. It is distinguishable from read_conversation and decide_answers, though the core noun 'handle' is never defined, leaving a small ambiguity.

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 explicit sequencing: 'Handle blockers/reviews, then wait on pending_ids until all_finished; drop delivered handles' and 'Ends are never pushed: wait after dispatch or independent work.' It also routes elsewhere where appropriate ('retry via run_round.retry_seats', 'read_conversation', 'decide_answers'). No explicit negative case naming a sibling tool to use instead of wait, which keeps it from a 5.

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

Deploy Server