MCP's July 2026 Revision Redesigns the Minutes-Long Tool Call: Tasks, MRTR, and server/discover Explained

On July 28, 2026, the Model Context Protocol shipped its largest revision since launch — and buried in the changelog is a redesign of the exact interaction a deploy tool lives or dies by: the tool call that takes minutes, not milliseconds. Experimental tasks graduated into the official io.modelcontextprotocol/tasks extension, server-initiated requests were replaced by the Multi Round-Trip Request pattern, and a mandatory server/discover RPC now handles version negotiation up front. If you operate an MCP server with a deploy, rollback, or migrate tool, this revision rewrites your run lifecycle end to end.

Here is the whole redesign in one table — the details, and what each row means for a minutes-long deploy run, follow below.

Why deploy tools are the stress case​

Most MCP tools answer in under a second. A deploy tool does not: it queues a build, waits for the image push, rolls out across nodes, then watches health checks converge — five to twenty minutes of wall-clock time in which anything can happen to the connection between agent and server.

Under the old model, that duration was a liability in three concrete ways:

• Blocking waits. Experimental core tasks used a blocking tasks/result call: the client held a request open until the run finished, so any proxy, load balancer, or client-side timeout could sever visibility into a deploy that was still happily proceeding.
• Server callbacks. Elicitation for approvals, sampling for model calls, and roots for filesystem context all required the server to push JSON-RPC requests back down the client's stream — per-connection state on the server, and a stream the client had to keep alive for the whole run.
• Session affinity. The initialize handshake plus Mcp-Session-Id pinned every client to stateful session handling from the first message, so scaling the MCP endpoint horizontally meant solving stickiness before anything else.

The July revision attacks all three at once. The unifying idea: every request is self-describing, every long run is a pollable handle, and the server never needs to call the client back.

Tasks graduate: poll a handle, don't hold a stream​

The biggest structural change is where tasks live. SEP-2663 moves them out of the protocol core and into the official io.modelcontextprotocol/tasks extension, and redesigns the mechanics around it. The blocking tasks/result method is gone, replaced by polling via tasks/get; a new tasks/update method carries client-to-server input mid-task; tasks/list is removed entirely; and servers may return task handles unsolicited, without the client opting in per request.

Concretely, a deploy run now looks like this:

agent -> server: tools/call deploy production build #482
server -> agent: task handle (task_9f3a), accepted
agent -> server: tasks/get task_9f3a            ... every N seconds
server -> agent: running (build 3/8 steps done)
agent -> server: tasks/get task_9f3a
server -> agent: running (rollout 2/6 nodes)
agent -> server: tasks/get task_9f3a
server -> agent: complete (healthy, 6/6 nodes)

Two details matter for operators. First, creation is server-directed: the client declares the extension in per-request _meta, and tools advertise task support so surfaces like the MCP Inspector can offer a "Run as Task" path — but the server decides when a call becomes a task, including returning a handle for a call the client made as an ordinary synchronous request. A deploy tool can therefore start every run as a task unconditionally, and the agent just polls.

Second, this is the one wire-incompatible migration in the whole revision. The team shipping v2.0 of the official MCP C# SDK put it plainly: Tasks is "exactly one place where v2 is not wire-compatible with v1," and anyone who adopted the experimental preview has a real migration to plan — the redesigned extension is incompatible at both API and protocol level. If your deploy tooling already speaks experimental tasks, budget that migration first; everything else in the revision degrades more gracefully.

MRTR: mid-run input without server callbacks​

The second redesign kills an entire category of connection state. Previously, when a server needed something mid-execution — human approval via elicitation/create, a model judgment via sampling/createMessage, filesystem context via roots/list — it sent a server-initiated request back to the client. That required a live, bidirectional channel for the duration of the run: exactly what a minutes-long deploy cannot guarantee.

SEP-2322 replaces all of it with Multi Round-Trip Requests (MRTR). The server never pushes. Instead it returns an InputRequiredResult: a result with resultType: "input_required", an inputRequests map describing what it needs, and an opaque requestState token. The client gathers the answers and retries the original request carrying inputResponses. Round trips continue until the server returns resultType: "complete".

The deploy-shaped example is a production approval gate. The agent calls deploy; the rollout reaches the production stage and needs a human sign-off:

agent -> server: tools/call deploy production build #482
server -> agent: resultType "input_required"
                 inputRequests: { approval: "Promote build #482 to production?" }
                 requestState: "opaque-token"
... human approves in chat ...
agent -> server: tools/call deploy production build #482
                 inputResponses: { approval: "approved" }
server -> agent: resultType "complete" (rollout finished, 6/6 healthy)

Note what survived a dropped connection here: everything. Each leg is a plain request/response pair, so the agent can poll the task, go away for ten minutes, come back, answer the approval, and retry — no held stream, no session to reattach. One compatibility rule to carry into your client code: every result now carries a required resultType of "complete" or "input_required", but clients MUST treat a missing field as "complete" — that is how results from pre-revision servers keep working. Old servers stay readable; only the new pattern needs the new field.

There is also a clock running. Server-initiated requests are deprecated under SEP-2577 with a 12-month offramp — the old server-to-client request form keeps working while clients migrate, then goes away. If your deploy tool uses elicitation for approvals today, that is your migration deadline.

server/discover and the stateless core​

The third change is the one that makes the other two deployable behind ordinary infrastructure. SEP-2575 removes the initialize / notifications/initialized handshake; SEP-2567 removes protocol sessions and the Mcp-Session-Id header alongside it. In their place, every request carries its protocol version and client capabilities in _meta (io.modelcontextprotocol/protocolVersion, clientCapabilities, clientInfo), and servers identify themselves in each result's _meta. As the AWS architecture review of the revision put it: a client's first message can be the actual tool call, and any server instance can respond to it.

server/discover is the mandatory replacement for the handshake's negotiation half. Every server MUST implement it; it advertises supported protocol versions, capabilities, and identity, and its result is cacheable. A new agent probes discovery once, picks the newest version both sides speak, and stamps that version on every request's _meta from then on. A legacy client that never calls discovery just keeps speaking 2025-11-25 — and the server knows which era each request belongs to from the request itself, not from connection state.

That per-request self-description is what lets one governed endpoint serve both eras side by side during the transition year. There is no session to pin, no handshake to version-gate: a 2026 agent polling tasks/get and a 2025 client holding a blocking call can hit the same URL, even the same load-balanced pool, and each gets the behavior its _meta asks for.

Two operational footnotes come with the stateless core. Streamable HTTP now requires Mcp-Method (plus Mcp-Name on tool, prompt, and resource calls) and MCP-Protocol-Version headers that mirror the body's method and _meta version, so intermediaries can route without parsing JSON — a missing or contradicting header is rejected with HeaderMismatch before your handler ever runs. And the old GET event stream is gone, replaced by subscriptions/listen, a long-lived POST whose SSE response carries only opted-in notifications.

Migration checklist for deploy-tool operators​

If you run a deploy, rollback, or migration tool over MCP today, here is the revision mapped to your backlog, in dependency order:

The good news is the ordering is forgiving. Items 4 through 6 are additive — a server can implement discovery, stamp versions, and emit resultType while still serving old clients — and only item 1 demands a flag day for anyone on experimental tasks. Start from the bottom of the table if your deploy tool never adopted the preview; start from the top if it did.

What this unlocks for agent-operated platforms​

Step back and the direction is unmistakable: MCP is converging on the shape of boring, scalable HTTP. Stateless requests behind a plain load balancer. Long work as pollable handles. Mid-run interaction as retries, not callbacks. Version coexistence negotiated per request, not per connection. Every one of those is a property a platform team already knows how to operate, monitor, and rate-limit — which is precisely the point. The less exotic the protocol surface, the sooner "deploy from chat" stops being a demo with a human watching the stream and becomes a governed operation: scoped credentials, an audit trail of task handles and approval round trips, and a deploy endpoint that scales like any other API.

That is also why the deploy tool is the right lens for this revision rather than a footnote to it. The spec's hardest problems — runs that outlive connections, approvals that need humans, fleets of agents on mixed versions — are a deploy tool's Tuesday. If your platform's agent story survives those three, it survives everything else the revision throws at it.

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.