MCP Goes Stateless: Reading the 2026-07-28 Spec Before Your Next Agent Ships

AGNTCon + MCPCon Europe ran in Amsterdam on September 17-18, 2026. It matters to developers because it is the first flagship gathering for the agent stack since the Model Context Protocol moved under foundation governance - the first place where spec evolution and production practice share a stage. And it arrived two months after the largest MCP spec change so far: on 2026-07-28, the protocol's core went stateless. This post is about one thing: the parts of that spec that will actually break your integration.

A stateless core moves MCP closer to ordinary web infrastructure

1. Start With Governance, Because It Defines 'Stable'

Per the Linux Foundation's April 2, 2026 press release, the Agentic AI Foundation (AAIF) is the neutral home for open standards powering agentic AI, with founding projects including Model Context Protocol, goose and AGENTS.md, and Mazin Gilbert as Executive Director. The 2026 program is anchored by AGNTCon + MCPCon Europe on September 17-18 in Amsterdam and AGNTCon + MCPCon North America on October 22-23 in San Jose, supported by a global MCP Dev Summit series: New York (April 2-3), Bengaluru (June 9-10), Mumbai (June 14-15), Seoul (August 13-14), Shanghai (September 6-7), Tokyo (September 10-11), Toronto (October 5-6) and Nairobi (November 19-20). The protocol is no longer steered by a single vendor, which changes what stability means for your roadmap.

# 1. The governance picture as of late September 2026
AAIF = {
    "name": "Agentic AI Foundation",
    "host": "The Linux Foundation",
    "founding_projects": ["Model Context Protocol (MCP)", "goose", "AGENTS.md"],
    "executive_director": "Mazin Gilbert",
    "flagship_events_2026": {
        "AGNTCon_MCPCon_Europe": "Sept. 17-18, Amsterdam",
        "AGNTCon_MCPCon_North_America": "Oct. 22-23, San Jose, California",
    },
    "dev_summit_series": [
        "New York, Apr. 2-3", "Bengaluru, Jun. 9-10", "Mumbai, Jun. 14-15",
        "Seoul, Aug. 13-14", "Shanghai, Sept. 6-7", "Tokyo, Sept. 10-11",
        "Toronto, Oct. 5-6", "Nairobi, Nov. 19-20",
    ],
}
# The protocol is now governed by a foundation, not by a single vendor.
# That changes what "stable" means for your integration roadmap.

2. The Headline Change: The Protocol Is Stateless

The MCP blog post for the 2026-07-28 specification states the highlight plainly: a stateless protocol core, transforming MCP from a bidirectional stateful protocol into a request/response stateless one. Concretely, the initialize / initialized exchange is retired, along with the Mcp-Session-Id header. Every request now carries its own protocol version, client identity and client capabilities in _meta. A new server/discover RPC lets clients learn capabilities up front, but it is optional. The payoff: any request can land on any server instance behind a plain round-robin load balancer, with no shared storage required. The spec also notes that dropping protocol-level sessions does not force your application to be stateless. The recommended pattern is to mint an explicit handle from a tool and have the model pass it back as an argument, because state the model can see works better than state hidden in the transport.

# 2. The headline change: the protocol is stateless
OLD_MODEL = {
    "handshake": "initialize / initialized exchange",
    "session": "Mcp-Session-Id header",
    "transport": "bidirectional, stateful stream",
    "consequence": "requests are sticky to the instance that holds the session",
}

NEW_MODEL = {
    "handshake": "none required; optional server/discover RPC for capability lookup",
    "session": "removed from the protocol",
    "per_request_meta": [
        "protocol version",
        "client identity",
        "client capabilities",
    ],
    "consequence": "any request can land on any instance behind a round-robin load balancer",
}

# Dropping protocol-level sessions does not force your app to be stateless.
# The recommended pattern: mint an explicit handle from a tool and have the
# model pass it back as an argument. State the model can see beats state hidden
# in the transport.

Header-based routing puts gateways, rate limits and auth back where they belong

3. Routing and Caching Move to the HTTP Layer

Two changes affect how you deploy. First, header-based routing: streamable HTTP requests must now include Mcp-Method and Mcp-Name, so a gateway, rate limiter or WAF can route and meter on headers instead of parsing JSON bodies. Second, list results are cacheable: responses from tools/list, prompts/list, resources/list and resources/read carry ttlMs and cacheScope, with deterministic ordering. That lets clients cache tool catalogues and keeps upstream prompt caches stable across reconnects. The spec's own example puts these together: POST /mcp, with MCP-Protocol-Version, Mcp-Method and Mcp-Name in the headers, and client identity carried in _meta.

// 3. Routing and caching move to the HTTP layer where gateways live
const requestEnvelope = {
  method: "POST",
  path: "/mcp",
  headers: {
    "MCP-Protocol-Version": "2026-07-28",
    "Mcp-Method": "tools/call",
    "Mcp-Name": "search",
  },
  body: {
    jsonrpc: "2.0",
    id: 1,
    method: "tools/call",
    params: {
      name: "search",
      arguments: { q: "otters" },
      _meta: { "io.modelcontextprotocol/clientInfo": { name: "my-app", version: "1.0" } },
    },
  },
};

const cacheableLists = {
  appliesTo: ["tools/list", "prompts/list", "resources/list", "resources/read"],
  fields: ["ttlMs", "cacheScope"],
  why: [
    "clients can cache tool catalogues",
    "deterministic ordering keeps upstream prompt caches stable across reconnects",
  ],
};

4. Authorization, Lifecycle and the Extensions Framework

Authorization is, by the maintainers' own account, where implementers spend most of their integration time, and this revision tightens it. Authorization servers should return the iss parameter per RFC 9207 and clients must validate it before redeeming a code, closing an authorization-server mix-up hole. Clients should set application_type during registration so localhost redirects for desktop and CLI apps stop being rejected. Client credentials are bound to the issuer that minted them and cannot be reused across authorization servers. Dynamic Client Registration is formally deprecated in favour of Client ID Metadata Documents (CIMD), continuing to work for backward compatibility but slated for removal. On lifecycle, the spec sets a formal deprecation policy with a twelve-month minimum window; Roots, Sampling, Logging and the legacy HTTP+SSE transport are marked deprecated. Tasks moves out of the experimental core into the io.modelcontextprotocol/tasks extension with a poll-based tasks/get and a new tasks/update, while change notifications consolidate into a single subscriptions/listen stream.

# 4. Authorization, lifecycle and the extensions framework
AUTH = {
    "issuer_validation": "authorization servers should return iss per RFC 9207; "
                         "clients must validate it before redeeming a code",
    "client_registration": "Dynamic Client Registration is deprecated in favour "
                           "of Client ID Metadata Documents (CIMD)",
    "credential_binding": "client credentials are bound to the issuing authorization server",
    "desktop_cli": "set application_type during registration so localhost "
                   "redirects stop being rejected",
}

LIFECYCLE = {
    "deprecation_policy": "formal, with a twelve-month minimum window",
    "deprecated_now": ["Roots", "Sampling", "Logging", "legacy HTTP+SSE transport"],
    "tasks": "moved to the io.modelcontextprotocol/tasks extension, with "
             "poll-based tasks/get and a new tasks/update",
    "notifications": "a single subscriptions/listen stream, opted in per type",
}

A twelve-month deprecation window is there so you can schedule the work

5. Your Migration Checklist

Turn the above into work items. Upgrade to a Tier 1 SDK that speaks 2026-07-28 - TypeScript, Python, Go and C# shipped on day one, with Rust in beta. Remove reliance on Mcp-Session-Id, and return an explicit handle if you need continuity. Emit Mcp-Method and Mcp-Name on every streamable HTTP request. Publish ttlMs and cacheScope on list and read responses. Validate iss, move from DCR toward CIMD, and scope credentials to a single issuer. Migrate off Roots, Sampling, Logging and HTTP+SSE inside the twelve-month window. If you run long jobs, adopt the tasks extension rather than holding a stream open. The scale figures explain the urgency: close to half a billion downloads a month across the Tier 1 SDKs, with the TypeScript and Python SDKs both past one billion total downloads.

{
  "migration_checklist_mcp_server": {
    "sdk": "upgrade to a Tier 1 SDK that speaks 2026-07-28 (TypeScript, Python, Go, C#); Rust is in beta",
    "sessions": "remove reliance on Mcp-Session-Id; if you need continuity, return an explicit handle",
    "headers": "emit Mcp-Method and Mcp-Name on every streamable HTTP request so gateways can route",
    "caching": "publish ttlMs and cacheScope on list and read responses",
    "auth": "validate iss, move off DCR towards CIMD, scope credentials to one issuer",
    "deprecated_surfaces": "migrate off Roots, Sampling, Logging and HTTP+SSE inside the twelve-month window",
    "tasks": "if you run long jobs, adopt the tasks extension instead of holding a stream open"
  },
  "why_now": "SDK downloads are running at roughly half a billion per month; the ecosystem is already moving"
}