Skip to main content
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 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:
While the job asks, next also has answer_url and expires_at. See 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.
  • 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.