> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pomerado.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Wait for a result

> Follow a job until it asks a question or finishes, then read its result once.

Follow a job until it asks a question or finishes, then read its result.

## Wait over REST

The REST API answers at once. Read `GET /v1/jobs/{id}` again after the seconds in a live job's `Retry-After` header, or use [webhooks](/guides/notifications/webhooks) instead of polling.

## Wait over MCP

Run tools wait for you. They return as soon as the job asks a question or ends:

* A client that accepts server-sent events waits up to 5 minutes, with keepalives, and progress notifications when it sends a progress token.
* Any other client waits up to 50 seconds.

If the job is still running when the wait ends, follow `next` instead of running the tool again.

`get_job` with `wait_seconds` waits the same way, up to 1,800 seconds for a client that accepts server-sent events and 50 otherwise. A wait can end early, such as during a release; call again.

## Follow next

Every MCP answer with a live job carries `next`, the exact call to make next:

```json theme={null}
{
  "action": "wait",
  "call": {
    "tool": "get_job",
    "arguments": {
      "job_id": "job_0f8e2d1c4b3a49e8a7f6e5d4c3b2a190",
      "wait_seconds": 1800
    }
  },
  "why": "This job may stop to ask a question. ..."
}
```

| `action` | When |
| - | - |
| `wait` | The job is running |
| `answer` | It asks something you can answer with `answer_job` |
| `ask_user` | It asks for a secret or a login, or your client asks the user |
| `correct_login` | The website rejected the saved login; the user corrects it |

While the job asks, `next` also has `answer_url` and `expires_at`. See [answer questions](/guides/jobs/answer-questions).

## Results are read once

Pomerado doesn't keep results. A result is erased once an answer carrying it reaches you in full, whether from `GET /v1/jobs/{id}`, `get_job` or a run tool. If your connection drops first, the next read returns it. An unread result is erased 60 minutes after the job ends.

Save the result when you receive it. Afterward the job reads `result` `null` and `result_status` `delivered` or `expired`, and a retry with the same idempotency key returns the job without it. For a new result, run the tool again with a new key.

To check a job without using up its result, read its status only: `GET /v1/jobs/{id}?include_result=false`, or `get_job` with `include_result` `false`.

<Accordion title="Details">
  * With `wait_past` set to an `input_request.id` you already gave the user, a `get_job` wait holds while that question is pending.
  * A client that supports MCP elicitation is asked the job's question during a `get_job` wait: a form for plain questions, the answer page for secrets and logins.
  * A build's `example_result` follows the same read-once rule.
</Accordion>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.