Your Deploy MCP Server Still Polls in a Loop. The August MCP Roadmap Wants to End That

Picture deploy-from-chat working exactly as advertised. You tell your agent "ship the api service," it calls your MCP server's deploy tool, and the build starts. Nine minutes later the rollout finishes. The tool call itself returned in two seconds — so how did the agent learn the outcome?

Today, the standard answer is embarrassing: it asked again. And again. Your agent polls tasks/get in a loop, burning a full tool call — and a slice of context window — on every "still running?" until the answer finally flips to done. The Model Context Protocol's own roadmap, published August 22, 2026, calls this what it is: "expensive client-side polling." Its number-one priority for the next spec cycle is to end it, with servers that push instead of only responding.

Here is the shape of the change, up front:

The rest of this post fills in that table: what MCP gives you today, what Priority 1 actually promises, what the deploy flow looks like before and after, and the build-now-or-wait decision every deploy-MCP-server owner faces this fall.

What MCP gives you today: the complete inventory​

To see why polling won, inventory every async primitive in the current stable release (2026-07-28). There are four, and none of them is server-initiated push.

Tasks: the durable handle you poll. The Tasks extension (io.modelcontextprotocol/tasks, SEP-2663) is the official answer to long-running operations. A server responds to tools/call with a task handle (resultType: "task") instead of a final result, and the client polls with tasks/get, supplies mid-flight input with tasks/update, and stops work with tasks/cancel until the task reaches completed, failed, or cancelled. This is a genuine improvement over blocking a tool call for nine minutes — the handle survives reconnects, and cancellation is explicit. But the retrieval model is still polling. The spec says so plainly: clients "poll for progress and retrieve the result when ready."

Subscriptions/listen: push-shaped, but for resources. MCP's subscriptions/listen mechanism lets a client subscribe to resource changes — a file updated, a document revised. It was never designed as a general event bus for "your build finished," and stretching it into one means shoehorning deployment lifecycle into resource semantics it doesn't have.

Progress notifications: signals during the call, not after it. Progress notifications let a server report progress/total while a request is still open. Useful for a long generation streaming inside one call; useless once the call has returned and the build runs for eight more minutes.

Multi Round-Trip Requests: server-initiated, but mid-call. SEP-2322 (MRTR) lets a server initiate patterns like elicitation without holding a deprecated SSE connection open. It covers the conversational case — the server needs input before it can finish answering — not the fire-and-forget case where the answer arrives long after the response.

So a deploy-from-chat server today has exactly the three options CData's Joe Karlsson enumerated in his September 14 enterprise read of the roadmap: "polling, a held SSE connection, or a hand-rolled webhook." Polling is the only one that works with every client. The held connection fights the protocol's direction (SSE is deprecated; Streamable HTTP is the remote standard since July). And the hand-rolled webhook works — until you want a second client to consume it, at which point you've invented a private event protocol.

What Priority 1 actually promises​

The August 22 roadmap's first priority area, Agentic Messaging Primitives, exists because the maintainers see the same gap. Led by core maintainers Caitie McCaffrey, Clare Liguori, and Peter Alexander, it starts from an unusually candid diagnosis: MCP has grown Tasks, subscriptions/listen, and progress notifications across multiple Working Groups, and the risk is "three answers to 'the server isn't done yet' that don't share a lifecycle, a cancellation model, or an error surface. We want them to compose."

Two deliverables are scoped for this roadmap period:

Server-initiated events, owned by the Triggers & Events Working Group. Channels and subscriptions for push delivery, including webhooks. The roadmap's stated goal is extensions "that let servers tell clients when work has finished, without relying purely on expensive client-side polling." Read that sentence twice: the maintainers named polling as the cost to kill.

A composition review across the Agents, Transports, and Triggers & Events Working Groups. Tasks and Triggers are being designed in parallel, and the review's job is to make them "compose cleanly with each other and fit concrete use cases" — one lifecycle, one cancellation model, one error surface, instead of three.

Beyond those, the roadmap expects continued work on Tasks (SEP-2663) "toward eventual inclusion of the extension in the core protocol" — poll-based retrieval graduating from extension to core even as push arrives alongside it. Note the framing: push doesn't replace Tasks; it composes with it. The task handle stays the durable record of the work; the event becomes how you learn it finished.

Two things the roadmap does not give you: dates and version numbers. CData's read is blunt on this point — "No target dates or version numbers are given for any of them" — and it shapes the only decision that matters this fall, which we'll get to shortly.

The deploy notification flow, before and after​

Make it concrete. A deploy-from-chat MCP server exposes deploy(service, ref). The build and rollout take nine minutes. Here is the agent side today, in sketch form:

handle = tools.call("deploy", {service: "api", ref: "a1b2c3"})
# -> { resultType: "task", taskId: "t-9182", status: "running" }
 
loop every 30 seconds:
    task = tasks.get("t-9182")
    if task.status in ("completed", "failed", "cancelled"):
        break
result = task.result  # final result rides on the polled Task

Eighteen polls for one deploy, each one a JSON-RPC round trip whose response the model must read, classify as "not done," and discard — while the meter runs. Tune the interval down and you hammer the server; tune it up and your "deploy finished" message lags reality by minutes. Every deploy-MCP-server operator has this loop somewhere, and every one of them has argued about the interval.

Now the same flow under standard server-initiated events, sketched against the roadmap's direction (channel names and payload shapes are illustrative — the Working Groups haven't finalized them):

handle = tools.call("deploy", {service: "api", ref: "a1b2c3"})
# -> { resultType: "task", taskId: "t-9182", status: "running" }
 
events.subscribe("tasks/t-9182", channel: "webhook",
                 deliver_to: "https://agent.example/hooks/mcp")
# agent does other work; zero polls
 
# minutes later, one push:
# { event: "task.completed", taskId: "t-9182" }
result = tasks.get("t-9182").result

The structure to notice: Tasks doesn't go away. The handle is still the durable record; tasks/get is still how you fetch the payload. What changes is purely the wake-up — from "ask eighteen times" to "be told once." That is what the composition review is for: the event references the task, the task carries the result, and cancellation and errors mean the same thing in both.

The honest caveat is the "after" column's one unfilled row: missed-delivery and replay semantics. Polling is dumb but self-healing — a dropped poll is just a late answer. Push needs answers to "what if the webhook delivery fails?" and "what if the agent restarts mid-build?" before it's production-grade. Those answers are exactly what the Triggers & Events WG is designing now, which is why the sketch above is direction, not API.

Build now or wait? The honest decision table​

This is where CData's September 14 analysis earns its keep. Karlsson ranks all five roadmap priorities by migration cost and urgency, and puts agentic messaging in the low-cost "watch" zone: "Nothing to migrate. The design decision is whether to build a non-standard event delivery layer now or wait for the spec to land. My answer is wait." His full guidance draws the line precisely:

"If you're building internal tooling that only your clients will ever use, do whatever works. If you're building anything you expect to be client-agnostic, wait for the Working Groups to finalize the design before committing to a non-standard event delivery layer. The migration cost if you don't wait could be real."

Apply that to a deploy-from-chat server with a decision table:

The third row is the move most teams should actually make. Don't scatter tasks/get loops through every agent workflow; centralize "tell me when the deploy finishes" behind a single notification interface your server team owns. When standard channels land, you reimplement one seam — subscribe instead of poll — rather than rewriting every consumer. Polling contained in one module is a placeholder; polling copy-pasted across ten workflows is architecture.

One more consideration for the "wait" camp: waiting doesn't mean idle. The composition review is explicitly asking for concrete use cases, and "a nine-minute deploy whose agent needs exactly one wake-up" is among the most concrete there is. If your team has opinions about replay semantics or webhook payload shape, the Triggers & Events WG is where they compound right now.

What this means for self-hosted deploy infrastructure​

Step back from the protocol mechanics and the pattern is familiar to anyone who runs their own PaaS: the expensive thing was never the build — it was the coordination around the build. Polling a deploy status is the agent-era version of a human hitting refresh on a CI dashboard, except the human doesn't pay per refresh in tokens. Standard push collapses that coordination cost to near zero, and it does it in the open: channels and webhooks any client can implement, not a proprietary event bus you rent from a dashboard vendor.

That openness is what makes the roadmap's direction good news for owned infrastructure specifically. A self-hosted deploy MCP server that speaks standard Tasks today and standard events tomorrow is interoperable with any agent client by construction — no per-client integration work, no hosted event router in the middle. The polling loop was always a tax on the teams without a vendor running the event layer for them. The roadmap proposes to repeal it.

Watch the Triggers & Events WG, keep your polling behind a seam, and design your deploy events as if every client in the world will consume them — because if the standard lands, they can.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.