MCP 2026-07-28 Stateless Spec: What Every Agentic AI Architect Must Know

On July 28, 2026, the Model Context Protocol shipped its largest revision since Anthropic first open-sourced it in November 2024. The headline: MCP is now stateless at the protocol layer. The initialize/initialized handshake is gone. The Mcp-Session-Id header is gone. Sticky sessions, shared session stores, and the deep packet inspection that horizontal deployments required — all gone.

If you run MCP servers in production, this is not a minor version bump. It is a foundational architectural shift that changes how you deploy, scale, secure, and migrate every server in your fleet. If you are building agentic AI systems that rely on MCP for tool integration — and by mid-2026, 41% of surveyed software organizations are running MCP servers in limited or broad production — you need to understand what changed, what breaks, and what gets dramatically easier.

This guide breaks down every major change in the 2026-07-28 specification, walks through the migration path with concrete code examples, addresses the security landscape that the stateless shift exposes, and lays out what this means for the broader agentic AI infrastructure stack.

Table of Contents

• Why MCP Went Stateless
• What Changed: The Six Core Shifts
• MCP Apps: Server-Rendered UIs in the Conversation
• The Tasks Extension: Long-Running Work Without Sessions
• Authorization Hardening: OAuth 2.1 Alignment
• What Is Deprecated (and the 12-Month Runway)
• Migration Guide: From 2025-11-25 to 2026-07-28
• The Security Landscape: 12,000 Servers Scanned
• Ecosystem by the Numbers: Mid-2026 Snapshot
• What This Means for Agentic AI Architects
• FAQ
• Key Takeaways
• References

Why MCP Went Stateless

The original MCP design, finalized in the 2025-11-25 specification, required a stateful session lifecycle. Every client had to call initialize before doing anything else. The server responded with an Mcp-Session-Id, and every subsequent request — tools/call, resources/read, prompts/get — had to carry that session ID in a header. This design worked well for local, single-instance deployments: a Claude Desktop talking to a single MCP server process on the same machine.

It did not work well for production. The moment you put an MCP server behind a load balancer — the standard pattern for any enterprise deployment — you needed sticky sessions to route each client back to the exact instance that issued its session ID. You needed a shared session store (Redis, DynamoDB, a database) so that if the original instance died, another could resume the conversation. You needed deep packet inspection at the gateway layer to read the Mcp-Session-Id header and make routing decisions. For organizations already running dozens of AI agents, each connecting to multiple MCP servers, the infrastructure overhead was significant.

The MCP maintainers flagged this problem as early as December 2025 in their blog post “The Future of MCP Transports.” Six Specification Enhancement Proposals (SEPs) were filed, debated through Working Groups, and merged over the following months. The result is a protocol that, as lead maintainers David Soria Parra and Den Delimarsky wrote in the release candidate announcement, “runs statelessly on commodity HTTP infrastructure.”

The practical effect is immediate: a remote MCP server that previously needed sticky sessions, a shared session store, and gateway-level packet inspection can now run behind a plain round-robin load balancer, route traffic on an Mcp-Method header, and let clients cache tools/list responses for as long as the server’s ttlMs permits.

What Changed: The Six Core Shifts

The 2026-07-28 specification is not a single change — it is six interlocking SEPs that together eliminate protocol-level state. Understanding them individually is the key to a clean migration.

More Read

Building with Google Agent Studio: The Complete Guide to Gemini Enterprise Agent Platform

Prompts vs. Context vs. Loops: The 2026 AI Engineering Map

Top 8 Trending Open-Source Agentic AI Repos Worth Starring in 2026

1. The Handshake Is Gone (SEP-2575)

The initialize/initialized two-step handshake is removed entirely. In the old spec, every MCP conversation began with a mandatory round trip:

// OLD: 2025-11-25 — Two requests before you can call a tool
POST /mcp
{"jsonrpc":"2.0","id":1,"method":"initialize",
 "params":{"protocolVersion":"2025-11-25",
           "capabilities":{},
           "clientInfo":{"name":"my-app","version":"1.0"}}}

// Server responds with Mcp-Session-Id header
// THEN you can call tools:
POST /mcp
Mcp-Session-Id: 1868a90c-3a3f-4f5b
{"jsonrpc":"2.0","id":2,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"}}}

In the new spec, a tool call is a single self-contained request:

// NEW: 2026-07-28 — One request, any server instance can handle it
POST /mcp
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
           "_meta":{"io.modelcontextprotocol/clientInfo":
                    {"name":"my-app","version":"1.0"}}}}

The protocol version, client info, and client capabilities that used to travel once during initialization now ride in _meta on every request. A new server/discover method lets clients fetch server capabilities when they need them upfront — but it is optional, not mandatory.

2. Sessions Are Gone (SEP-2567)

The Mcp-Session-Id header and the protocol-level session concept are removed. Any MCP request can now land on any server instance. This is the change that eliminates sticky routing and shared session stores.

But stateless protocol does not mean stateless applications. The spec explicitly documents the explicit-handle pattern: if your server needs to carry state across calls — a shopping basket, a browser session, a multi-step workflow — you mint an identifier from a tool call and have the model pass it back as an ordinary argument on later calls. Think basket_id, browser_id, or workflow_run_id.

The maintainers note that this pattern is often more powerful than protocol-level sessions because the model can reason about handles, compose them across tools, and hand them off between steps — things that session state hidden in transport metadata never allowed.

3. Server-to-Client Requests Restructured (SEP-2260, SEP-2322)

In the old spec, a server could push prompts to the client over a long-lived Server-Sent Events (SSE) stream — useful for elicitation (asking the user a question mid-tool-call) but fundamentally incompatible with stateless HTTP.

The new spec replaces this with Multi Round-Trip Requests. When a server needs user input, it returns an InputRequiredResult:

{
  "resultType": "input_required",
  "inputRequests": {
    "confirm": {
      "type": "elicitation",
      "message": "Delete 3 files?",
      "schema": { "type": "boolean" }
    }
  },
  "requestState": "eyJzdGVwIjoxLC..."
}

The client gathers the answer, then re-issues the original request with inputResponses and the echoed requestState. Any server instance can pick up the retry because everything it needs is in the payload. Server-initiated requests are now required to only happen while the server is actively processing a client request — no more unsolicited prompts.

4. Routable, Cacheable, Traceable Headers (SEP-2243, SEP-2549, SEP-414)

Three smaller but operationally critical changes:

For teams already invested in observability — and if you are running AI agents in production, you should be — the W3C Trace Context standardization alone is worth the migration. Before this, several SDKs were already propagating trace headers, but the key names were inconsistent. Now they are fixed in the spec.

5. Full JSON Schema 2020-12 for Tools (SEP-2106)

Tool inputSchema and outputSchema are upgraded from a restricted subset to full JSON Schema 2020-12. Input schemas keep the type: "object" root constraint but now support composition (oneOf, anyOf, allOf), conditionals, and references ($ref, $defs). Output schemas are unrestricted, and structuredContent can now be any JSON value rather than only an object.

This is a significant upgrade for complex tools. A deployment tool that previously needed a flat parameter list can now express conditional schemas — selecting “production” reveals security parameters, selecting “staging” shows different defaults — all validated before the tool runs.

6. Extensions Framework (SEP-2133)

Extensions existed informally in 2025-11-25 but had no formal governance. The new spec adds a full lifecycle: extensions are identified by reverse-DNS IDs, negotiated through an extensions map on client and server capabilities, live in their own ext-* repositories with delegated maintainers, and version independently of the specification. A new Extensions Track in the SEP process gives them a path from experimental to official.

This is how the protocol plans to evolve without breaking things going forward. New capabilities ship as opt-in extensions, stabilize there, and only move into the core spec if warranted. Two official extensions ship with this release: MCP Apps and Tasks.

MCP Apps: Server-Rendered UIs in the Conversation

MCP Apps (SEP-1865) is the more radical of the two official extensions. It lets MCP servers ship interactive HTML interfaces that host clients render in a sandboxed iframe — directly inside the conversation.

Think about what this unlocks: a sales analytics tool that returns an interactive dashboard where users filter by region and drill into accounts without leaving the chat. A deployment tool that presents a multi-step configuration wizard with dependent form fields. A monitoring server that streams live log output with filtering and search. These are not mockups — the ext-apps repository ships ready-to-run examples including 3D visualizations, cohort heatmaps, customer segmentation explorers, budget allocators, and PDF viewers.

The architecture is security-conscious. Tools declare their UI templates ahead of time so hosts can prefetch, cache, and security-review them before anything runs. The rendered UI communicates back to the host over the same JSON-RPC protocol used everywhere else in MCP, so every UI-initiated action goes through the same audit and consent path as a direct tool call.

As of the final specification, six host clients support MCP Apps: Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, and Archestra.AI. Google’s Developers Blog has already documented how their A2UI framework combines with MCP Apps for hybrid declarative-and-custom agentic UIs.

For RPA and automation architects, MCP Apps represents a potential paradigm shift: instead of building separate web dashboards for human-in-the-loop steps, you embed them directly in the agent conversation. An approval workflow that currently requires a user to switch to a separate application can now render its form, collect the decision, and continue execution — all within the same interface where the agent operates. If you are building AI agent control planes for enterprise governance, MCP Apps gives you a new surface for human oversight without breaking the agent’s flow.

The Tasks Extension: Long-Running Work Without Sessions

Tasks shipped as an experimental core feature in 2025-11-25. Production usage surfaced enough design problems that the feature was pulled out of core and reshaped as an extension.

The core problem: the original Tasks API was session-bound. A client created a task, polled it, and cancelled it — all scoped to the session that created it. With sessions gone, that model breaks entirely.

The new Tasks extension reshapes the lifecycle around the stateless model:

1. A server answers tools/call with a task handle instead of an immediate result
2. The client drives the task with tasks/get, tasks/update, and tasks/cancel
3. Task creation is server-directed: the client advertises support for the extension, and the server decides when a call should run as a task
4. tasks/list is removed because it cannot be scoped safely without sessions

This design is particularly important for agentic AI workloads where tool calls take minutes or hours — web scraping jobs, data pipeline executions, CI/CD deployments, or complex multi-step agent workflows like those in AWS Bedrock AgentCore. The agent fires the call, gets a handle, and can do other work while periodically checking status. Any server instance can respond to the status check because the task handle, not the session, is the identifier.

If you shipped against the 2025-11-25 experimental Tasks API, you will need to migrate to this new lifecycle. The task handle pattern and the removal of tasks/list are the biggest changes.

Authorization Hardening: OAuth 2.1 Alignment

Six SEPs harden the authorization specification to align with how OAuth 2.0 and OpenID Connect are actually deployed in enterprise environments. For agentic AI architects dealing with production security, these are the critical changes:

The iss validation requirement (SEP-2468) deserves special attention. In MCP’s typical deployment pattern, a single AI agent connects to many tool servers — each potentially with its own authorization server. Without iss validation, a malicious tool server could redirect the agent to a legitimate authorization server, intercept the response, and impersonate the agent to a different tool server. This class of mix-up attack is well-documented in OAuth security research and is more likely in MCP’s architecture than in traditional web applications.

What Is Deprecated (and the 12-Month Runway)

Three core features are deprecated under a new formal feature lifecycle policy (SEP-2577):

The lifecycle policy guarantees at least 12 months between deprecation and the earliest possible removal. The methods, types, and capability flags continue to work in this release and in every specification version published within that window. Removing any of them will require a separate SEP.

The Logging deprecation is particularly notable for RPA practitioners. If you have been using MCP’s built-in logging to capture tool execution details, you need to plan a migration to OpenTelemetry. The upside is that OpenTelemetry integration — combined with the new W3C Trace Context propagation — gives you dramatically better observability than MCP’s proprietary logging ever did. A trace that starts in your agent framework (LangGraph, CrewAI, Amazon Bedrock with LangGraph) can now follow through the MCP client SDK, the server, and downstream services as a single span tree.

Migration Guide: From 2025-11-25 to 2026-07-28

SDK Betas Are Available Now

Beta releases of all four official SDKs support the new spec:

Critically, backward compatibility is maintained. Clients that speak 2026-07-28 fall back to the initialize handshake when they reach a server on 2025-11-25 or earlier. Old servers and new clients keep interoperating. This means you can migrate clients and servers independently — you do not need a big-bang cutover.

Step-by-Step Migration Checklist

1. Remove session management code. If your server stores session state, refactor to the explicit-handle pattern. Mint identifiers from tool calls and accept them as arguments on subsequent calls. If you are using a session store (Redis, DynamoDB), you can repurpose it as a handle store — but the protocol no longer manages the lifecycle for you.

2. Remove the initialize handler. Your server no longer needs to respond to initialize requests. The information that used to travel in the handshake now arrives in _meta on every request. If you need to inspect client capabilities upfront, expose a server/discover endpoint.

3. Add the required headers. Every response should include MCP-Protocol-Version: 2026-07-28. Every incoming request will carry Mcp-Method and Mcp-Name headers — validate that they match the JSON-RPC body.

4. Implement caching metadata. Add ttlMs and cacheScope to your tools/list and resources/list responses. Clients will use these to avoid unnecessary re-fetching.

5. Replace SSE-based elicitation with Multi Round-Trip Requests. If your server uses server-initiated requests (elicitation prompts), refactor to return InputRequiredResult with requestState. Serialize any state the server needs to resume into the opaque requestState field.

6. Update the error code for missing resources. Change from MCP-custom -32002 to JSON-RPC standard -32602 (Invalid Params).

7. Plan deprecation migrations. If you use Roots, Sampling, or Logging, begin migrating to their replacements. You have at least 12 months, but the replacements (tool parameters, direct LLM API integration, OpenTelemetry) are available now and are strictly better.

8. Update your load balancer configuration. Remove sticky session rules. Configure round-robin routing. Optionally, use the Mcp-Method header for content-based routing (e.g., route tools/call to GPU-backed instances, resources/read to lightweight instances).

The Security Landscape: 12,000 Servers Scanned

The stateless shift makes MCP servers easier to deploy — but it does not make them automatically secure. And the current security landscape is concerning.

BlueRock Security’s analysis of 12,000+ public MCP servers found:

• 6% have critical vulnerabilities
• 42% have command injection flaws
• 33% are vulnerable to SSRF (Server-Side Request Forgery)
• 41% require no authentication at all

A separate analysis of 2,614 MCP implementations by CloudSEK found that 82% use file system operations prone to path traversal (CWE-22), 67% use APIs related to code injection (CWE-94), and 34% are susceptible to command injection (CWE-78).

The SSRF risk is especially acute. MCP servers sit inside corporate networks where they can reach internal databases, file systems, and cloud infrastructure. In BlueRock’s proof-of-concept against Microsoft’s MarkItDown MCP server, researchers retrieved AWS IAM API keys, secret keys, and SSH keys directly from the EC2 instance metadata endpoint.

The 2026-07-28 spec’s authorization hardening helps — the OAuth 2.1 alignment and iss validation close specific attack vectors. But the spec cannot fix servers that were written without input validation, that accept arbitrary URLs for resource fetching, or that run with root-level filesystem access. Between January and February 2026 alone, over 30 CVEs targeting MCP servers, clients, and infrastructure were filed.

Security Checklist for MCP Server Operators

Whether you are building new servers or migrating existing ones to 2026-07-28, these are non-negotiable:

1. Validate all input — tool arguments, resource URIs, and any user-supplied data. Never pass raw input to shell commands, file paths, or URL fetchers.
2. Implement authentication — the spec now provides a clear OAuth 2.1 path. Use it. The 41% of servers running without auth are a liability.
3. Block SSRF vectors — if your server fetches URLs, maintain a strict allowlist. Block access to cloud metadata endpoints (169.254.169.254), internal network ranges, and localhost.
4. Run with least privilege — your MCP server does not need root filesystem access. Containerize it. Limit network egress to known endpoints.
5. Validate the iss parameter — now required by the spec. If your client SDK does not do this yet, upgrade to the beta.
6. Use OpenTelemetry for audit logging — with Logging deprecated, this is both the recommended path and the one that gives you the best visibility into what your servers are doing.

Ecosystem by the Numbers: Mid-2026 Snapshot

The MCP ecosystem has grown explosively since launch. Here is where things stand:

The quality problem is real: users report 30-50% installation failure rates on community servers, and over 50% of listed servers are considered inactive or low-quality. The open-source agentic AI ecosystem is growing faster than quality controls can keep up. The new SDK tier system — which requires Tier 1 SDKs to pass a conformance suite — is an attempt to raise the floor.

Remote MCP servers are now the 2026 default. GitHub, Vercel, Linear, Notion, Supabase, Stripe, and Figma publish OAuth-secured hosted endpoints. The stateless specification makes this architecture dramatically simpler to operate.

What This Means for Agentic AI Architects

For RPA Teams Integrating AI Agents

If you are building or extending MCP servers to connect AI agents to enterprise tools, the stateless specification removes the biggest operational barrier to scaling. Your MCP servers can now sit behind the same load balancers, use the same deployment patterns, and follow the same operational playbooks as your REST APIs. The infrastructure team does not need to learn a new session management paradigm.

MCP Apps opens a particularly interesting possibility for human-in-the-loop RPA workflows. Instead of building a separate dashboard for approvals and exceptions, you can embed interactive forms directly in the agent conversation. A document processing pipeline that flags an invoice for manual review can render the invoice, the extracted data, and an approval form — all inside the interface where the operator is already working.

For Agent Framework Developers

If you are building on LangGraph, CrewAI, AG2, or Microsoft’s Agent Framework, the stateless spec simplifies your MCP client integration. You no longer need to manage session lifecycles, handle session expiration, or implement reconnection logic. Your client sends a request, gets a response, and moves on. The ttlMs caching metadata lets you avoid re-fetching tool lists on every agent turn — a meaningful performance improvement for agents that make dozens of tool calls per task.

The Tasks extension is critical for agent workloads. Long-running tool calls — data pipeline executions, complex reasoning chains in Gemini, multi-step browser automation — can now run asynchronously via task handles. Your agent loop can fire a tool call, get a handle, process other tasks, and poll for completion. This is the pattern that production agent systems have been implementing ad-hoc; now it is standardized.

For Enterprise Platform Teams

The authorization hardening closes real attack vectors. If you are deploying MCP servers inside a corporate network where agents connect to multiple tool servers — each with its own auth provider — the iss validation, credential binding, and OIDC alignment protect against the mix-up and impersonation attacks that the old spec was vulnerable to.

The W3C Trace Context standardization means you can trace an agent’s decision from the initial prompt through every MCP tool call through every downstream API call — in a single span tree in your existing observability stack (Datadog, Grafana, Honeycomb, or any OTel-compatible backend). For compliance and audit, this is a significant step forward from the fragmented logging that the old spec provided.

Frequently Asked Questions

Do I have to migrate to 2026-07-28 immediately?

No. The SDK betas maintain backward compatibility — new clients fall back to the old handshake when talking to old servers. But the deprecated features (Roots, Sampling, Logging) have a 12-month removal window starting now. Plan your migration, but you are not forced into a big-bang cutover.

Will my existing MCP servers stop working?

Not immediately. Updated clients will detect your server’s protocol version and use the appropriate handshake. However, you will not benefit from the stateless infrastructure improvements, caching, or the new extensions until you migrate.

What replaces Mcp-Session-Id for servers that need state?

The explicit-handle pattern. Your tool mints an identifier (e.g., workflow_id), returns it to the model, and the model passes it back as an argument on subsequent calls. The state lives in your application’s data store, not in the protocol.

Is MCP Apps production-ready?

It ships as an official extension with the final spec and is supported by six host clients including Claude Desktop and VS Code. The security model — sandboxed iframes, prefetchable templates, JSON-RPC communication channel — is designed for production. Start with low-risk use cases (dashboards, read-only visualizations) and expand from there.

How do I secure my MCP server against SSRF?

Maintain a strict URL allowlist for any resource-fetching functionality. Block cloud metadata endpoints (169.254.169.254), internal network ranges, and localhost. Validate all tool arguments. Run in a container with restricted network egress. The spec’s OAuth 2.1 alignment helps with authentication, but input validation is your responsibility.

Key Takeaways

• MCP 2026-07-28 is the largest protocol revision since launch — a stateless core that eliminates sticky sessions, shared session stores, and complex gateway configurations for horizontal deployments.
• The initialize handshake and Mcp-Session-Id are gone. Every request is self-contained and any server instance can handle it.
• MCP Apps lets servers render interactive HTML UIs inside the conversation — a new surface for human-in-the-loop agent workflows.
• The Tasks extension standardizes asynchronous, long-running tool calls via task handles — critical for production agent workloads.
• Six authorization SEPs harden OAuth/OIDC alignment, closing real attack vectors in MCP’s many-server deployment pattern.
• Roots, Sampling, and Logging are deprecated with a 12-month minimum removal window. OpenTelemetry replaces MCP’s proprietary logging.
• SDK betas for Python, TypeScript, Go, and C# are available now with backward compatibility to older servers.
• The security landscape is concerning: 42% of scanned servers have command injection flaws, 33% are SSRF-vulnerable, and 41% lack authentication.
• Migration can be incremental — clients and servers can be updated independently. Start with removing session management and adding the required headers.

References

1. Soria Parra, D. & Delimarsky, D. (2026). “The 2026-07-28 MCP Specification Release Candidate.” Model Context Protocol Blog.
2. Model Context Protocol Blog. (2026). “Beta SDKs for the 2026-07-28 MCP Spec Release Candidate Are Here.”
3. Model Context Protocol Blog. (2026). “The 2026-07-28 Specification.”
4. SecurityWeek. (2026). “New Enterprise-Ready MCP Specification Brings New Security Challenges.”
5. BlueRock Security. (2026). “MCP fURI: SSRF Vulnerability in Microsoft MarkItDown MCP.”
6. CloudSEK. (2026). “How an Unauthenticated MCP Server Led to SSRF, LFI, and AWS Credential Theft.”
7. Practical DevSecOps. (2026). “MCP Security Statistics 2026: CVEs, Vulnerabilities & Breach Data.”
8. Digital Applied. (2026). “MCP Adoption Statistics 2026: Model Context Protocol.”
9. Stacktree. (2026). “MCP 2026-07-28 spec: what changed, what breaks.”
10. WorkOS. (2026). “The biggest MCP spec update ships July 28: What changes for AI agent authentication.”
11. Developers Digest. (2026). “The MCP 2026-07-28 Rewrite: What Breaks and How to Migrate.”
12. Google Developers Blog. (2026). “A2UI + MCP Apps: Combining the best of declarative and custom agentic UIs.”
13. HackerNoon. (2026). “MCP’s 2026 Update Makes Remote Servers Easier to Scale.”
14. Agentic AI Foundation. (2026). “MCP 2026-07-28: From Local Tool to Distributed Protocol.”