wait_for_generation
Block until the feature's generation finishes, polling at the server-recommended interval (normally 3 seconds), and return the final generation status.
This is an MCP / CLI convenience — there is no REST wait endpoint. Over raw HTTP, poll GET …/generation yourself. See Long-running operations.
Arguments
| Argument | Type | Required | Description |
|---|---|---|---|
feature | string | yes | Feature id or name. |
timeoutSeconds | integer | no | How long to wait (default 120, max 170). |
project | string | no | Project public id (defaults to the configured project). |
- MCP
- CLI
Tool wait_for_generation — { "feature": "12", "timeoutSeconds": 170 }.
testvibe generate "Login Functionality" --watch --timeout 3600
--watch re-arms this wait until the generation is terminal, bounded by --timeout (default 5400 s). It exits 0 only when the generation actually succeeded — 1 if it failed or was cancelled, 2 if it parked to ask you a question, 3 if the ceiling elapsed first. See the CLI wait contract.
Result
The same payload as get_generation_status, taken when isTerminal becomes true, a question requires an answer (awaitingInput: true), or the timeout expires.
Timing out cancels nothing. If isTerminal is false and awaitingInput is false, keep monitoring. If input is required, answer the question before waiting again. Generations regularly outlast a single 170 s wait.
monitoringInterrupted: true means a transient status read failed; it is not a completed result. Retry monitoring the same operation instead of dispatching it again. A wait can finish before the operation, so always check isTerminal on the returned payload.