The MCP 2026-07-28 release is a major update, and it ships today! The release bundles several independent changes, two of which land squarely on Alpic. One touches what we build for customers, the other what we host for them. But the good news? We’re making this change seamless for Alpic customers whether you’re using our build service, our cloud platform or Skybridge.

Extensions grow up, and in-conversation UIs get official status

Extensions existed in the previous release, but with no formal process behind them. 2026-07-28 gives them one (SEP-2133). Each extension now carries a reverse-DNS identifier, negotiates through an extensions capability map, lives in its own repository with its own maintainers, and versions independently of the specification, with a dedicated Extensions Track to move a proposal from experimental to official.

Two extensions ship as official with this release: MCP Tasks (SEP-1686), which handle long-running work, and MCP apps (SEP-1865), which lets a server ship interactive HTML that the host renders in a sandboxed iframe.

Both extensions were already first class citizens on Alpic Cloud, and this as soon as SEP landed. Moving apps from a good idea to an official protocol extension confirms the direction we were already building toward. Agents that render a genuine interface instead of returning a wall of text now have formal standing in the spec's extension model. The apps run no differently. Underneath them, the interface layer is now a maintained, independently versioned extension that hosts adopt on a shared spec, so apps should keep working and carry across the clients that support it.

Alpic is already supporting the next in-line extension SEP-2640 Skills over MCP. Give it a try in Alpic playground!

On the hosting side, nothing to migrate

The other change is at the transport layer. 2026-07-28 makes the protocol stateless, retiring the initialize handshake and the Mcp-Session-Id session so every request stands on its own. A shift like that normally means new transport code, a migration plan, and a coordinated redeploy. For servers hosted on Alpic, it means none of those.

That holds because of where Alpic sits. When a client connects to a server you host with us, Alpic is the layer in between. It answers the client as an MCP server, then makes its own call to your server as an MCP client. Because it handles those two hops separately, the two sides don't have to run the same protocol version. A client on the new stateless protocol can reach a server still running the old one, because Alpic speaks both. Your server keeps its URL, needs no redeploy, and new clients get the stateless protocol as it lands. Full support tracks the final specification and a stable v2 of the official SDK.

One thing does improve for builders directly. With no hidden session, state now travels as an explicit handle the model passes from one call to the next, which tends to make agent behavior easier to compose and reason about than state buried in transport metadata.

Skybridge takes the change

Skybridge, Alpic's framework for building MCP apps, will move to the stateless core as well. The work is early, but the direction is set, and the goal is that upgrading will cost nothing in your own code:

• On the stateless model, a server built with Skybridge will run across instances without sticky sessions, so scaling and deploys stay simple.

• The HTTP layer is being rebuilt on modern Fetch underneath, while the one-line Express setup stays identical.

• Tool definitions are moving to Standard Schema, so existing Zod definitions keep working unchanged.

• The logic mirrors the hosting side. Alpic absorbs the breaking protocol change so developers keep the code they already have.

You can give stateless Alpic a try by downloading our alpha v2 on npmjs: npm create skybridge@alpha

What changes on our side

Two things shift for us. Statelessness removes the session ID Alpic used to stitch a caller's requests into a journey, so cross-call analytics are being rebuilt around explicit conversation handles, while per-request metrics (latency, errors, tokens, payloads) are unaffected. Those handles come from the client, not from us. OpenAI already passes one through its clients, and broader coverage depends on other hosts, Claude among them, choosing to share the same kind of context. We think that sharing should be designed to serve app builders and the ecosystem, not only the platforms, and we will push for it to work that way.

The second shift is scaling. Statelessness bakes horizontal scaling into the protocol itself. Any request can now land on any instance. We had already built that by hand, re-priming transport and connection on each request to emulate sticky sessions. Having it standardized validates the approach and frees us to spend that effort on the layers above it (authorization, analytics, and keeping both protocol eras live on one URL).

Here’s a look at what changes: