MCP server notify when work finished: Sume webhooks vs jobs_wait

Today an agent on Sume's MCP server learns a job finished by calling jobs_wait again, not by a server push. Webhooks exist, but they belong to the REST job path and send terminal events only. The MCP roadmap lists push delivery as planned work, not as something Sume's docs say it ships.

The roadmap line is from the MCP roadmap, read 2026-09-30. Sume's side is from Jobs and results and Webhooks.

What does the MCP roadmap say about push delivery?

The roadmap, last updated 2026-08-22, has a "Server-initiated events" item from the Triggers & Events working group: channels and subscriptions for push delivery, including webhooks, so servers can tell clients when work has finished without relying purely on expensive client-side polling. It is a work item, so what the extension will look like is not settled by that page.

How does an agent wait on Sume over MCP today?

With jobs_wait. On remote MCP, timeout_seconds defaults to 50 and is capped at 55, and a wait returns as soon as its job is terminal. When a slice ends without a result, the response says wait_slice_expired; call jobs_wait again with the same ids. Never resubmit the paid create. Batch waits take 1 to 20 ids.

There is no SSE or WebSocket transport on the Developer API; GET /v1/jobs/:id/events is a pull snapshot, not a stream.

Where do Sume webhooks fit?

A webhook is one of four communication modes on the REST path. Sume posts job.completed, job.failed or job.canceled to a public HTTPS URL, with no progress or partial events. Deliveries are signed with HMAC when signing is configured. That suits a backend service that submits via REST. It does not give an MCP chat session a callback.

What should I do until push exists?

Store the job id from submit, loop on jobs_wait, and keep status polling as the fallback. The webhook docs say delivery is an optimization, never the only recovery path. For the related Tasks question see MCP Tasks and long Sume jobs.