MCP 2026-07-28 Spec Is Final: What MCP Apps + Tasks Mean for Your Servers

MCP 2026-07-28 spec final — stateless HTTP, MCP Apps, Tasks extension, OAuth-aligned auth

Quick answer: The MCP 2026-07-28 specification is final on 28 July 2026 (release candidate is out now). Four headline changes: stateless HTTP core (no more initialize handshake), MCP Apps (server-rendered UIs), Tasks extension (long-running work), OAuth/OIDC-aligned auth. Beta SDKs for Python, TypeScript, Go, and C# are already available.

This is the largest revision of MCP since launch. Servers built on the 2025-11-05 spec will still work (formal 12-month deprecation), but the new architecture is meaningfully simpler and more powerful — worth planning a migration.

---

The four headline changes

1. Stateless HTTP — no more sticky sessions

Under the old spec, every remote MCP server carried session state. Clients had to:

Send an initialize request
Wait for the initialized response
Include Mcp-Session-Id on every subsequent request
Handle session expiration + reconnection

That forced infrastructure most teams hated: sticky-session load balancers, Redis for session storage, complex reconnection logic in clients.

The 2026-07-28 spec removes all of it. Client metadata now travels in a `_meta` field on every request rather than being negotiated once. The result:

Round-robin load balancer works. Every request is fully self-contained.
Client can cache aggressively. tools/list responses carry ttlMs and cacheScope — clients know exactly how long to cache and whether the response is safe to share across users.
Routing headers land in HTTP. Mcp-Method and Mcp-Name let gateways route on the operation without parsing the body.

For anyone running remote MCP on Vercel, Cloudflare Workers, or a bare Kubernetes cluster: your infrastructure just got simpler by a whole order of magnitude.

2. MCP Apps — server-rendered UIs in a sandboxed iframe

Before 2026-07-28: if your tool needed a complex input (multi-step config, file picker, calendar UI, etc.), you had two bad options: (a) accept a huge JSON schema and hope the client renders it usably, or (b) ship your own web app and awkwardly link out.

MCP Apps changes this. Servers ship interactive HTML UIs, and hosts (Claude Desktop, Cursor, ChatGPT Search) render them in a sandboxed iframe. Tools declare their UI template ahead of time, so the host can:

Prefetch the UI bundle before the tool is called
Cache it aggressively (with the same ttlMs + cacheScope model)
Security-review it (CSP validation, sandbox flags, permission scopes) before anything runs

This unlocks tools that couldn't exist before:

A GitHub PR viewer with syntax-highlighted diffs, inline comments, and review buttons
A calendar-picker for a scheduling MCP that supports timezones properly
A configuration wizard for a database migration tool with a visual schema diff
A live-updating dashboard for a monitoring MCP with charts

Security is opt-in per host. Claude Desktop's initial rollout will only render MCP Apps from servers on an approved list. This is analogous to how Chrome extensions work today.

3. Tasks extension — first-class long-running work

The old MCP had a hard problem with any tool that took longer than ~30 seconds. Video encoding, batch exports, large SQL queries, LLM call chains — none fit the request/response model well. Servers hacked around it with "check my status" second tools, polling loops, or webhooks.

The Tasks extension makes it native:

Client: tools/call { name: "generate_video", args: {...} }
Server: tools/call/result { task: { id: "task_abc", status: "pending" } }
Client: tasks/get { id: "task_abc" }
Server: task { id: "task_abc", status: "running", progress: 0.34 }
Client: tasks/get { id: "task_abc" }
Server: task { id: "task_abc", status: "complete", result: {...} }

Server-directed task creation. The server decides whether a given call is sync or async based on estimated duration. Clients handle both uniformly — the wire format is a discriminated union: tools/call returns either an immediate result OR a task handle.

Cancellation is first-class. tasks/cancel sends a Meta-defined cooperative-cancel signal. Servers should stop work and release resources when it arrives.

Progress reporting is optional but native. No more per-server bespoke progress protocols.

4. OAuth 2.1 / OIDC-aligned authorization

The old MCP auth was flexible — which meant every server team invented their own. Some used API keys, some used OAuth, some used custom bearer schemes with no discovery.

The 2026-07-28 spec aligns explicitly with OAuth 2.1 and OpenID Connect. Servers publish a discovery endpoint at /.well-known/oauth-authorization-server, clients handle the standard OAuth 2.1 flows (PKCE required, refresh tokens rotate, scopes are strings), and OIDC ID tokens can carry per-user context.

What this means for you:

If you already use OAuth 2.1 (Auth0, WorkOS, Clerk, Supabase Auth), your existing auth infrastructure works
If you were rolling your own bearer scheme, you have a documented target to migrate to
Clients don't need per-server auth code anymore — everyone speaks OAuth 2.1

---

The migration reality

Do you need to migrate immediately? No. The 2025-11-05 spec is still supported for at least 12 months per Anthropic's new formal deprecation policy. Existing MCP servers keep working.

Should you migrate soon? For most teams, yes. The three biggest reasons:

Stateless architecture is a scaling superpower. If you're planning to grow your MCP server past a handful of users, staying on session-based auth will cost you more infrastructure and maintenance every quarter.
MCP Apps enables new UX you literally cannot build otherwise. If your tool has any complex input, this alone justifies the migration.
OAuth alignment simplifies your auth story. If you're maintaining bespoke auth code, migration deletes it.

Migration effort:

Server size	Typical migration effort
Small (1-5 tools, no session state)	1-2 days
Medium (5-15 tools, some session state)	3-5 days
Large (15+ tools, heavy session state, custom auth)	1-2 weeks
Enterprise (multi-tenant, custom identity)	3-4 weeks

The Beta SDKs handle the wire-format change transparently. Where you need work is: (a) refactoring your session storage to work statelessly, (b) migrating your auth to OAuth 2.1 discovery, (c) declaring your UI templates if you want MCP Apps.

---

Where StackPicks Connect sits

Our **StackPicks Connect** platform ships the 2026-07-28 spec on our gateway on the day the final spec drops (28 July 2026). Existing customers on the 2025-11-05 wire format keep working — we run both spec versions in parallel through July 2027, so you migrate on your schedule.

The MCP Apps support in Connect is the piece we're most excited about. It means every MCP server in our directory can eventually ship a proper UI without each maintainer having to build one from scratch. We're publishing a template library in August.

---

What to read next

**The full 2026 MCP roadmap** (context on where the spec is going): modelcontextprotocol.io/development/roadmap
**Beta SDK announcement post** (with install commands): blog.modelcontextprotocol.io — SDK Betas 2026-07-28
**The June 2026 MCP servers leaderboard** — needs a refresh after the spec drop, but the current top 20 is still valid: **/blog/top-20-mcp-servers-ranked-q2-2026-velocity**
**MCP server security checklist** — a lot of this remains critical under the new spec: **/blog/mcp-server-security-checklist-2026**

---

**Sources:** Model Context Protocol Blog — 2026-07-28 Release Candidate, Model Context Protocol Blog — Beta SDKs for 2026-07-28, Stacktree — What changed in the 2026-07 MCP specification, The New Stack — MCP roadmap 2026, Agentic AI Foundation — MCP Is Growing Up.

We'll refresh this post on 28 July 2026 when the spec goes final + when the stable SDK versions ship.

Frequently asked questions

What is the biggest change in the 2026-07-28 MCP spec?+

Statelessness. The old protocol required an initialize / initialized handshake and every subsequent request had to carry an Mcp-Session-Id header. That forced remote MCP servers into sticky-session load balancers. The 2026-07-28 spec removes both — client metadata now travels in a _meta field on every request, and any round-robin load balancer works. This is the single biggest architectural change since MCP launched, and it makes deploying an MCP server on Vercel, Cloudflare Workers, or a bare Kubernetes cluster trivial.

What are MCP Apps?+

MCP Apps let servers ship interactive HTML UIs that MCP hosts (Claude Desktop, Cursor, ChatGPT Search) render in a sandboxed iframe. Tools declare their UI template ahead of time so the host can prefetch, cache, and security-review them before the tool runs. This finally solves the "how do I show a complex configuration form to the user" problem that pushed people toward hacky JSON-schema-to-form generators. Servers can now ship real UIs with proper design.

What is the Tasks extension for?+

Long-running work. Previously, if your MCP tool took 30+ seconds (batch export, video rendering, big query, LLM call chain), you had to hack around it with polling or a "check my status" second tool. The Tasks extension makes it native: server answers tools/call with a task handle instead of a result, and the client drives it with tasks/get, tasks/update, and tasks/cancel. Server-directed task creation means the server decides when a call becomes async — clients handle both cases uniformly.

Do I need to migrate my existing MCP server to the 2026-07-28 spec now?+

Not immediately. The 2025-11-05 spec is still supported and will be for at least 12 months per Anthropic's new formal deprecation policy. But three reasons to migrate soon: (1) stateless architecture removes your biggest scaling headache; (2) MCP Apps enables new UX you literally cannot build under the old spec; (3) OAuth alignment means fewer bespoke auth flows to maintain. Migration typically takes 1-2 days for a small server; larger servers with heavy session state need more work to refactor. The Beta SDKs handle the wire-format change transparently.

When can I use it in production?+

Beta SDKs are shipping now (Python, TypeScript, Go, C#). The Beta status means the wire format is stable but corner-case behaviors may still change before 28 July final. For production use: (a) if you're building new MCP servers, start on the 2026-07-28 SDK today — the wire format won't break; (b) if you're running existing servers, wait for 28 July final and the corresponding SDK stable release. Migration guides are being published on the MCP blog through July.