If you read one line: The MCP 2026-07-28 spec finalized on schedule Tuesday — stateless core, no handshake, no session header — and the founder's story isn't the date, it's the five things now standardized that you can build on: the Tasks extension for long jobs, MCP Apps for real UIs, cacheable tool lists, hardened auth, and a ~12-month deprecation runway so nothing you run breaks this week. All four Tier-1 SDKs speak it day one. Pick the one extension that maps to your product and ship it.
For a month, every MCP headline — ours included — pointed at one square on the calendar: July 28. That square is now behind us, and the deadline did exactly what a good deadline does — nothing dramatic. The spec went final on time, the SDKs were ready, and no one's servers fell over. So this week's Wire is not "the spec is coming." It's a founder's field guide to the five things that actually landed — and which one to touch first.
1. The core went stateless — and that's an infrastructure win, not a chore#
The finalized spec removes the initialize/initialized exchange and the Mcp-Session-Id header entirely (MCP blog). In their place: header-based routing via Mcp-Method and Mcp-Name, so an ordinary HTTP gateway can route requests to your server without understanding MCP internals. Server-initiated round-trips that used to need a held-open stream are replaced by Multi Round-Trip Requests.
What it means for you: MCP now runs on the boring, scalable infrastructure you already pay for — a load balancer, a stateless container, an autoscaler. No sticky sessions, no special stream handling. We walked the exact server-author changes in the stateless-core explainer; the short version is that "stateless" is the feature that makes MCP cheap to operate at a team of one.
2. Tasks is the extension long-running agents were waiting for#
The single most useful thing in the release for anyone building real agents: Tasks graduated from the experimental core into the io.modelcontextprotocol/tasks extension, with a poll-based tasks/get and a new tasks/update (MCP blog). Instead of holding a connection open while a job grinds for minutes, your server hands back a task handle and the client polls for progress and result.
What it means for you: the awkward workarounds are over. A build, a data migration, a deep-research run — anything that outlives a single request — now has a standard shape. This maps directly onto the problem we cover most, keeping a long-running agent alive across its context window, and it's the natural plumbing for the deep-agent pattern. If you adopt exactly one thing from 7/28, make it Tasks.
3. MCP Apps: your tool can finally show a UI instead of describing one#
MCP Apps is now a finalized extension for server-rendered interactive UIs inside the client (MCP blog; MCP Servers). Rather than returning raw tool JSON that the model has to read aloud, your server can render an actual surface — a form, a picker, a preview.
What it means for you: for a whole class of tools, the UX ceiling just lifted. We explained the mechanics in MCP Apps: how to give your MCP server a UI, and why it collides with other agent-UI standards. If your product is one where the interaction is the value — approvals, configuration, anything a wall of text mangles — this is your extension, not Tasks.
4. Cacheable lists and hardened auth: the quiet efficiency and trust upgrades#
Two smaller changes worth a config pass. First, tools/list, prompts/list, resources/list, and resources/read now carry ttlMs and cacheScope (MCP blog) — clients can cache your capability list instead of re-fetching it on every call. Second, authorization tightened: RFC 9207 issuer validation is required for clients, and the spec shifts from Dynamic Client Registration toward Client ID Metadata Documents (CIMD), with application_type supported during DCR.
What it means for you: set a sensible ttlMs on your lists and you cut redundant round-trips for free. On auth, DCR still works during the runway, so you can move to CIMD deliberately rather than in a panic — but the direction of travel is set, so plan for it.
The date was the headline. The extensions are the business. A deadline you already survived is trivia; a standard for long-running work you can ship on Monday is leverage.
5. The deprecations come with a runway — so this is not a fire drill#
Roots, Sampling, and Logging are deprecated, along with the legacy HTTP+SSE transport — all with at least a twelve-month runway (MCP blog). New clients fall back to the old handshake when they meet an old server. And the tooling is ready: all four Tier-1 SDKs — TypeScript, Python, Go, and C# — support 2026-07-28 as of publication day, with Rust in beta.
What it means for you: nothing you deployed last month breaks this week, and you have a year to move off the deprecated surfaces. We laid out the exact steps in the day-one migration checklist and argued the real story was always governance, not statelessness — a protocol that promises a year of notice before it removes anything is a protocol you can finally treat as infrastructure.
The through-line: the protocol stopped moving, so you can start building#
For a year, "wait for the spec to settle" was a defensible reason to defer an MCP integration. That reason expired Tuesday. A stateless core, a versioned extensions framework, day-one SDKs in four languages, and a twelve-month change-notice guarantee add up to one thing: MCP is no longer a moving target. The plumbing is done being interesting so you can go back to the part that's actually hard — the product on top.
Your week in three moves#
- Pick your one extension. Long jobs → Tasks. Tool that needs a UI → MCP Apps. Selling to companies → EMA. Adopt one, not all three.
- Set a
ttlMson your lists. A one-line config change that stops clients from re-fetching your capabilities on every call. - Schedule the deprecation move, don't rush it. You have ~12 months. Put "migrate off Roots/Sampling/Logging and HTTP+SSE" on the roadmap for a quiet week — not this one.
The countdown hit zero and the lights stayed on. Now go build on the ground that finally stopped shaking.



