The next revision of the Model Context Protocol, the draft dated 2026-07-28, is the most significant rewrite MCP has had since it appeared, and it lands on the 28th. In one breath: the protocol is going stateless. The initialize handshake is gone. Sessions are gone. Servers can no longer send requests back to clients. Every tool call is now a self-contained HTTP request that carries its own protocol version, identity, and capabilities.

This is a great direction. A stateless protocol is easier to scale, easier to load-balance, and easier to reason about. What changes is the job of the MCP client, the component inside your harness that actually speaks the protocol. A lot of what used to live implicitly in a warm connection now has to be handled explicitly on every request. So if you build a client or a harness, or if you depend on one, this is a good moment to check what “supports the 2026-07-28 spec” actually requires.

Below is that checklist. Arcade.dev will be compatible with the new spec on day one, so you can read this two ways: as a punch list if you’re building the client yourself, or as a set of things to demand from whatever runtime you build on. If you want the full wire-level walkthrough, with every payload that crosses the wire, there’s a companion deconstruction by Arcade’s Mateo Torres: An MCP Tool Call, Deconstructed.

The release in one line

Every tools/call now stands entirely on its own (SEP-2575). No handshake, no session to join, no back-channel for the server to reach you on. Any replica of a server can answer any request, because none of them need to remember anything between calls. That is the whole point, and everything on this list follows from it: if the connection remembers nothing, the client has to carry what matters, explicitly, in every message.

What this unlocks: two workflows that get better

Before the checklist, it’s worth being concrete about why this matters, because the release quietly fixes some of the most annoying failure modes in real tool-using agents. Two examples.

A scheduling agent that waits on a human. “Book the team offsite and put it on everyone’s calendar” touches Google Calendar and needs a person to confirm and pay somewhere in the middle. Under the current protocol, that pause is awkward: the booking holds an open connection while the server reaches back up the wire to ask for confirmation, and a timeout or a reconnect can wreck the whole thing. In the new release, the server ends the call with an input_required result, hands your client a small piece of state to hold, and the booking resumes as a durable task, even if the harness restarts while the user is still on the payment page. The workflow now survives the human taking ten minutes to click “pay.” That’s Multi-Round-Trip Requests (MRTR) and the tasks extension doing real work.

A cross-service ops agent acting as a real person. “Pull the failing PR from GitHub and post a summary to the on-call Slack channel” spans two services, and it should run as the engineer who triggered it, not as one shared bot account with keys to everything. Every request carries its own per-user token, so the agent can act as the real user on each call, and an expired token just refreshes silently instead of derailing the run.

Neither workflow is new. What’s new is that the protocol stops making the hard parts (human-in-the-loop pauses and per-user identity across services) fight you.

The day-one checklist

1. Speak the self-contained request shape

A tools/call is now fully self-describing. The protocol version, client identity, and client capabilities ride in _meta on the request itself, and the method and tool name are mirrored into HTTP headers so intermediaries can route without parsing the JSON body (SEP-2243).

POST /mcp HTTP/1.1
Host: cabins.example.com
Authorization: Bearer eyJhbGciOiJFUzI1NiIs...
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: book_cabin

The Accept header lists both content types because the server chooses which one to answer with: a single JSON response, or an SSE stream when it wants to send progress notifications before the result.

Your client needs to build this on every call, and it must keep the headers and body in agreement, because the server is required to reject them if they disagree. The details are in the Streamable HTTP transport section.

2. Discover, don’t handshake

There’s exactly one discovery RPC now, and it’s new: server/discover (SEP-2575). Every server implements it, and a client can call it before anything else to learn supported protocol versions and capabilities up front. It doubles as a backward-compatibility probe: a server that chokes on it is speaking an older, handshake-era MCP, which is how your client tells the two worlds apart on day one.

3. Register by publishing, not by POSTing

The recommended way for a client and a server that have never met to establish identity is now Client ID Metadata Documents (CIMD). Your client_id becomes an HTTPS URL pointing at a JSON document you (or the client maintainer) host about yourself, and the authorization server fetches it on demand. Dynamic Client Registration, the old POST-to-register dance, is deprecated. If your client still relies on DCR, today is the day to publish a client-metadata.json instead.

4. Own the token lifecycle, per user and per issuer

The draft tightens the guidance around how a client holds credentials, and it’s explicit about the shape: tokens are stored keyed by the authorization server’s issuer identifier, and that binding is a hard requirement (SEP-2352). Your client needs to:

  • Store an access token and a refresh token per user, per issuer, encrypted at rest.
  • Attach the right token to every request.
  • Refresh silently on expiry, and re-run the first-contact OAuth flow on a 401.
  • Validate the iss parameter on the authorization callback, byte-for-byte, against the issuer it recorded during discovery. This closes a mix-up attack where a malicious authorization server tricks the client into sending a code to the wrong endpoint (SEP-2468).
  • Keep the token out of the model entirely. It should never enter a prompt, a context window, or a model response.

5. Carry Multi-Round-Trip state

This is the change that may surprise people most. Servers can no longer call clients back, so when a server needs input mid-call, it doesn’t send you a request, it ends the call with an interim result (SEP-2322):

{
  "resultType": "input_required",
  "inputRequests": { "...": "what the server needs from the user" },
  "requestState": "v1.gcm.9yKX0jPmYQ4kFhk3...hT2w"
}

That requestState blob is the server’s encrypted memory of a half-finished operation, handed to your client for safekeeping. You gather the user’s input, then retry the original tools/call with a new id, the answers keyed exactly as the server asked, and the requestState echoed back untouched. Your client must not peek inside it, must not lose it, and must be able to resume the operation on a different server replica than the one that issued it. In practice that means durably parking in-flight work, which is a genuinely new responsibility for a client. The full pattern is in Multi-Round-Trip Requests.

6. Poll tasks instead of blocking

Long-running work moved out of the core protocol into a tasks extension (SEP-2663). The old blocking tasks/result is gone. Your client declares the tasks capability, receives a durable task handle, and polls tasks/get at the interval the server suggests, resuming with the same handle if the harness crashes and restarts. One more loop to run, one more handle to persist.

7. Broker third-party auth mid-flight

Here’s the one that matters most in production, because it’s where all of the above shows up at once. Say your agent needs to put an event on a user’s Google Calendar. That means calling Google on behalf of that specific user, with a delegated OAuth token, requested in the middle of a tool call, for a service that isn’t the MCP server your client is talking to.

The protocol shape is clean: the server ends the call with input_required and a URL for the user to complete Google’s OAuth out of band, plus a requestState blob; the user authorizes on Google’s own pages so their credentials never touch your client or the model; you retry with the answer. What your client owns is everything that makes it safe: obtaining and storing a per-user Google token (not a shared service account that would hand every user the keys to every other user’s calendar), scoping it minimally, refreshing it weeks later, and doing this for every third-party service every one of your tools might reach.

None of statelessness changes the host’s core security duties: users must explicitly consent before any tool runs, and tool descriptions are untrusted input unless they come from a trusted server. If your client pre-approves read-only tools, that’s a policy decision that lives in the harness, never in the protocol.

Build it, or demand it

Read that list back and it’s clear how much of it is auth and lifecycle: per-user tokens, issuer keying, silent refresh, mix-up defense, third-party OAuth, and keeping every credential away from the model. The stateless parts (self-contained requests, discovery, MRTR, tasks) are mechanical and well-scoped. The auth parts are where the real engineering (and the real security surface) lives.

If you’re building a client, this is your punch list for the 28th. If you’re building on a client or a runtime, this is what to demand from it, because “we support MCP 2026-07-28” should mean all of it, not just the easy half.

Arcade is compatible on day one

This is the seam Arcade was built for, so I’ll be direct about where it fits and then get out of the way.

Arcade is the actions runtime for enterprise AI agents: the layer your agent calls through when it needs to actually do something in a real system. The auth-heavy half of the checklist is what the runtime already does today, and it speaks the 2026-07-28 shape on day one:

  • Isolated token lifecycle. Arcade brokers the OAuth flow and holds tokens in an encrypted, per-user vault, keeping them current through refresh, rotation, and mismatch, and injecting the credential at execution. The token is never handed to the model or the MCP client. Items 4 and part of 7 on the checklist are the runtime’s job, not your codebase’s.
  • Multi-user, post-prompt authorization. The mid-flight third-party dance from item 7 becomes a single call, scoped to the intersection of what that user is allowed to do and what the agent is allowed to do. Not a service account. Not a shared token. Evaluated per action, at runtime.

The takeaway

Stateless MCP lands on the 28th, and it’s a genuinely good release. The clients that are ready on day one will be the ones that treated auth, token lifecycle, and third-party access as first-class. Whether you build that yourself or run it on a runtime that already has it, the bar is the same.

If you want to see the whole thing move on the wire first, start with the companion deconstruction. When you’re ready to check the auth boxes without building them, the Arcade docs are the place to start.

Frequently asked questions

What does “stateless MCP” actually mean?

It means the connection no longer carries state between messages. The initialize handshake, the session, and the server’s ability to send requests back to the client are all gone (SEP-2575). Every tools/call is a self-contained HTTP request that carries its own protocol version, identity, and capabilities in _meta, so any replica of a server can answer any request without remembering anything from a previous one.

Do I have to rewrite my MCP server for the 2026-07-28 release?

Servers change too: they need to implement server/discover, return a resultType on every result, and adopt Multi-Round-Trip Requests and the tasks extension in place of server-initiated requests. But the heavier lift usually lands on the client, which is why this post is a client-side checklist. A server that still can’t answer server/discover is simply detected as an older, handshake-era server and handled on the compatibility path.

If servers can’t call clients back, how do long-running or interactive tool calls work?

Two mechanisms replace the old back-channel. For anything that needs input from the user (a confirmation, a payment, a third-party login), the server ends the call with an input_required result plus an opaque requestState blob, and the client retries once it has the answer (MRTR). For work that just takes time, the server returns a durable task handle and the client polls tasks/get on the tasks extension (SEP-2663).

Where are OAuth tokens supposed to live now?

On the client side, the same as before. Holding an access token and a refresh token per user was always the client’s job, because authorization has always traveled on every request rather than on the session. What the draft adds is a hard requirement on how they’re keyed: by the authorization server’s issuer identifier (SEP-2352). The rest of the hygiene is unchanged and still worth stating: encrypted at rest, refreshed silently, and never exposed to the model or leaked into a prompt. Arcade handles this in an encrypted, per-user vault so it never touches your application code.

Will my users have to re-authenticate when the new spec ships?

Not because of statelessness alone. Credentials are keyed by issuer, so as long as a server keeps pointing at the same authorization server, existing refresh tokens keep working. A user only needs to re-authenticate if the issuer changes, in which case the old credentials must not be reused against the new one.

Is Dynamic Client Registration really gone?

It’s deprecated, not removed, and kept for backward compatibility. The recommended path for a client and server that have never met is now a Client ID Metadata Document: your client_id is an HTTPS URL pointing at a JSON document about the client, which the authorization server fetches on demand. Registration becomes publishing a file instead of POSTing to a registration endpoint.

How does Arcade support the 2026-07-28 spec?

Arcade is an actions runtime that speaks the new stateless shape on day one and absorbs the auth-heavy half of the checklist: per-user token lifecycle, issuer keying, silent refresh, and brokering third-party OAuth mid-call. The stateless mechanics, MRTR, and tasks are handled behind the same interface, so your agent code stays the same whether the wire is the new draft or the version before it, and every action still runs as a real, audited user. See the Arcade docs to get started.

From explainers to step-by-step instructions, Arcade is your guide to the largest revision to the MCP spec since launch. Click here for all of our coverage.