Why the Roadmap Is Targeting Polling Now
The new MCP roadmap, published August 22, 2026, put "agentic messaging primitives" first among five priority areas. Until now, MCP clients have tracked long-running work by polling the handles that the Tasks extension (SEP-2663) hands back. The roadmap names webhooks and channels — servers notifying clients of state changes instead of clients asking — as the next specification priority, and pins the goal down as "a standardized callback mechanism with defined ordering guarantees that hold across all transports."
Since the March roadmap, real progress has already landed: a stateless protocol core (SEP-2575, SEP-2567), Multi Round-Trip Requests (SEP-2322), and Enterprise-Managed Authorization have all reached stabilization. With server-initiated events named as the next stage in the August roadmap, teams running Tasks on polling today gain by lining up their readiness items ahead of the actual cutover.
Don't Skim Past the "Exploratory" Label
The real work on server-initiated events is happening in the incubation repository for the "MCP Triggers & Events Working Group." The repo states plainly that it is "exploratory and does not represent official MCP specifications or recommendations" — it names webhooks as the leading candidate but has not yet documented concrete technical specifics. Its leads are Clare Liguori (AWS) and Peter Alexander (Anthropic), its scope is limited to SEP documents, reference implementations, and cross-transport coordination, and wire-format changes or general-purpose pub/sub infrastructure are explicitly out of scope.
That distinction matters for where you invest first. Build against an unfinalized wire format and you'll rewrite code with every spec revision; the receiving-side operating principles — idempotency, order correction, failure fallback — survive spec changes unchanged. What a team should prepare for right now isn't a specific webhook implementation, but these three principles.
Before You Move to Webhooks: Design for Order, Duplicates, and Outages First
Start the migration plan with numbers. Reasonable pilot targets: a 90%+ drop in API calls versus polling, p95 latency under 3 seconds from event receipt to processing complete, and a reprocessing rate from duplicate events under 1%. Fix those three figures in code before the pilot starts, so the outcome is a pass/fail call instead of a "feels better" impression.
The first trap is assuming ordering is guaranteed. The Triggers & Events working group's own charter still lists "ordering guarantees that hold across all transports" as an unsolved goal, so in deployments mixing stdio and HTTP transports, events can arrive out of the order they occurred. Attach a sequence number to every event and keep a short reorder buffer on the client side, so a late-arriving predecessor doesn't drive the state machine into an invalid transition.
The second trap is assuming exactly-once delivery. Webhooks retry by nature, so the same event can be sent more than once; handle that naively and a notification fires twice or state gets updated twice. Storing the event ID as an idempotency key and filtering duplicate receipts within a short window (say, 10 minutes) server-side should be the default for any webhook receiver.
The third trap is designing as if the receiving endpoint never fails. When a webhook URL is briefly down, events sent during that window are lost the moment the sender's retries are exhausted. Run webhooks and polling side by side during the early transition, and add a circuit that automatically tightens the polling interval when webhook failure rates cross a threshold, closing the gap.
Pre-launch scenario tests should cover at least three cases: forcing the receiving endpoint down for 30 seconds to confirm retries actually arrive, sending the same event three times in a row to confirm duplicate filtering works, and sending two events with swapped sequence to confirm the reorder buffer catches it. Log standard fields — event ID, sequence number, receipt timestamp, transport (webhook/SSE/stdio), retry count — and verify signatures (HMAC) with a timestamp window check by default to block forged event injection.
Since the spec is still at the incubation stage, the weekly task isn't glamorous. Check the working group's SEP progress on a weekly cadence, and keep a running tally of the failure types your pilot hits — reordering, duplication, loss — so that when the spec finalizes, you already know which principle to promote into production code first.
Takeaways at a Glance
The server-initiated events the MCP roadmap has flagged are still at an incubation stage where even the wire format isn't fixed. That's no reason to delay preparation. Set targets of a 90% drop in calls versus polling, p95 latency under 3 seconds, and a sub-1% reprocessing rate, and implement sequence reordering, idempotency keys, and dual-path fallback against the three failure patterns — reordering, duplicate delivery, endpoint outages — before the spec lands. Once it does, swapping in webhooks becomes a transport-layer change, not a rewrite.