The Stateless Evolution of the Model Context Protocol (MCP 2026-07-28)

Why I Preferred Agent Skills and CLI Tools

In early implementations of Model Context Protocol workflows, I routinely opted for local agent skills by coupling LLMs directly with local CLI executables and targeted REST endpoints rather than spinning up dedicated MCP servers. The reasoning came down to two practical developer realities:

• Token Efficiency: Injecting heavy, rigid protocol definitions and session state headers into every context window consumed valuable prompt tokens. Direct CLI function signatures and specialized skills allowed for far tighter, token-frugal prompts.
• Workflow Management & Visibility: Running CLI tools locally made execution transparent, easy to debug, and simple to version-control alongside application code without maintaining long-running connection daemons.

The Maintenance Tension: Server vs. Client

However, agent skills carry a hidden operational tax over time: script sprawl across local developer environments. As client workflows evolve, updating a tool means deploying updates across every machine or agent runner.

Centralized servers naturally solve this. Storing tool functionality on a server means logic, authentication, and security updates happen in one place. Yet under earlier stateful MCP iterations, running an MCP server meant maintaining persistent SSE/WebSocket connections, tracking session handshakes (Mcp-Session-Id), and managing stateful server memory across reboots.

What Changed in the MCP 2026-07-28 Architecture

The MCP 2026-07-28 Architecture specification completely removes the stateful burden from the protocol layer:

1. Elimination of Stateful Session Handshakes

The protocol no longer requires an initial stateful handshake (initialize / initialized) or persistent session identifiers. Every request is now completely self-contained, carrying required capabilities and protocol metadata inside an inline _meta payload field.

// 2026-07-28 Stateless Request Structure (Self-Contained)
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "query_database",
    "arguments": { "sql": "SELECT * FROM orders WHERE status = 'pending';" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28"
    }
  }
}

2. Serverless & Edge-Native Deployment

Because connection state is no longer held in server memory, MCP servers now behave like standard HTTP workloads. You can deploy an MCP server to Cloudflare Workers, AWS Lambda, or Vercel edge functions where it can scale horizontally and spin down to zero when idle without dropping client state.

3. Multi Round-Trip Requests (MRTR)

To handle human-in-the-loop approvals, OAuth prompts, or missing parameters without holding an active socket open, the 2026-07-28 spec introduced Multi Round-Trip Requests (MRTR). The server can request mid-call input via structured response payloads while remaining entirely stateless between turns.

4. Header-Based Proxy Routing & Catalog Caching

Standardized HTTP headers (Mcp-Method and Mcp-Name) let reverse proxies and load balancers inspect and route requests without parsing JSON-RPC bodies. Meanwhile, responses include explicit cache scopes (ttlMs), allowing clients to cache tool list definitions instead of re-fetching catalogs on every interaction.

The Takeaway for Builders

Local agent skills and CLI wrappers remain ideal for tight, token-optimized local tasks. But by stripping away stateful session mechanics, the 2026-07-28 spec makes MCP server implementations dramatically simpler to write, deploy, and maintain. For team-wide tools, shared database connectors, and cloud workflows, a stateless MCP server on serverless infrastructure is now an incredibly compelling architecture.