{"slug": "the-2026-07-28-mcp-spec-a-server-readiness-checklist", "title": "The 2026-07-28 MCP Spec: A Server Readiness Checklist", "summary": "The upcoming MCP 2026-07-28 specification introduces breaking changes including a stateless protocol, removal of the initialize handshake, new transport headers, and stricter security requirements. Server operators must migrate to stateless operation, implement server/discover, enforce header-body agreement, and integrity-protect requestState tokens. The changes address request routing integrity, cross-user cache scope, and schema-driven fetch behavior.", "body_md": "The next Model Context Protocol specification, `2026-07-28`\n\n, is the largest revision since the protocol launched. The release candidate locked on May 21, 2026, and the final spec publishes on July 28. It contains breaking changes to transport, authorization, and how tool schemas are handled.\n\nA server that is correct against `2025-11-25`\n\ntoday is not broken. Nothing here is a present-tense vulnerability. But several of these changes are security properties, not just compatibility ones — request routing integrity, cross-user cache scope, and schema-driven fetch behavior all move under this revision. This checklist walks the changes a server operator needs to handle before July 28, and calls out the security implication wherever there is one.\n\nEverything below describes the release candidate. Treat specifics as subject to change until the July 28 final, and validate against the official spec before shipping.\n\nThis is the headline change. MCP becomes stateless at the protocol layer, and most of the migration work lives here.\n\nThe `initialize`\n\n/`initialized`\n\nhandshake is removed (SEP-2575). Protocol version, client info, and client capabilities no longer get exchanged once at connection time — they travel in `_meta`\n\non every request. The same SEP adds `server/discover`\n\nas the new discovery anchor: servers must implement it, and clients fetch server capabilities from it when they need them up front. Once the handshake is gone, a server that can't answer `server/discover`\n\ncan't be negotiated with.\n\nThe `Mcp-Session-Id`\n\nheader and the protocol-level session it carried are also removed (SEP-2567). Any request can now land on any server instance. The sticky routing and shared session stores that horizontal deployments relied on are no longer required at the protocol layer.\n\nIf a server needs state across calls, mint an explicit handle from a tool — a `basket_id`\n\n, a `browser_id`\n\n— and have the model pass it back as an ordinary argument. The state becomes a visible tool input rather than something hidden in transport metadata.\n\nThe Streamable HTTP transport now requires `Mcp-Method`\n\nand `Mcp-Name`\n\nheaders (SEP-2243), so load balancers, gateways, and rate-limiters can route on the operation without reading the body. Requests also carry `MCP-Protocol-Version`\n\n.\n\nServers must reject requests where the headers and the body disagree. This is a request-integrity check, not just a convenience: a mismatch between the routing header and the actual method in the body is exactly the kind of ambiguity that smuggling and confused-routing attacks exploit. Enforce the agreement; don't route on the header and execute the body.\n\n`_meta`\n\n`server/discover`\n\nfor capability negotiation`Mcp-Session-Id`\n\nand stop requiring sticky sessions`Mcp-Method`\n\nand `Mcp-Name`\n\n, and reject header/body mismatchesA stateless protocol still needs a way for a server to ask the client for something mid-call. Two changes rebuild that flow without a persistent connection.\n\nServer-initiated requests may now only be issued while the server is actively processing a client request (SEP-2260). Earlier versions recommended this; it is now required.\n\nThe security value is concrete. A user is never prompted out of nowhere, and every elicitation traces back to an action they or their agent started. An unsolicited server-initiated prompt is now a spec violation, which makes a whole class of social-engineering-via-prompt behavior detectable rather than ambiguous.\n\nInstead of holding a Server-Sent Events stream open, the server returns an `InputRequiredResult`\n\ncarrying an opaque `requestState`\n\n(SEP-2322). The client gathers answers and re-issues the original call with `inputResponses`\n\nand the echoed `requestState`\n\n, and any instance can pick the retry up.\n\nTreat `requestState`\n\nas untrusted on the way back in. It leaves the server, sits client-side, and returns. Integrity-protect it — sign or encrypt it — so a modified `requestState`\n\ncan't replay or escalate a half-finished operation. Don't deserialize it into trusted server state without verification.\n\n`InputRequiredResult`\n\nrather than holding an SSE stream open`requestState`\n\nand verify it on retryThree smaller changes make the resulting traffic easier to operate — and two of them carry data across boundaries that deserve attention.\n\nList and resource-read results now carry `ttlMs`\n\nand `cacheScope`\n\n, modeled on HTTP `Cache-Control`\n\n(SEP-2549). Clients learn exactly how long a `tools/list`\n\nresponse stays fresh and whether it is safe to share across users.\n\n`cacheScope`\n\nis where this becomes a security decision. If a server exposes a per-user or per-tenant tool surface but marks the result shareable, a client may serve one user's tool list to another. Set `cacheScope`\n\nto match the actual sensitivity of what the response reveals, and default to the narrower scope when unsure.\n\nW3C Trace Context propagation in `_meta`\n\nis now documented, fixing the `traceparent`\n\n, `tracestate`\n\n, and `baggage`\n\nkey names (SEP-414). A trace can follow a call through the client SDK, the server, and whatever the server calls downstream, and show up as one span tree in an OpenTelemetry-compatible backend.\n\n`baggage`\n\nis the field to watch. It propagates arbitrary key-value data downstream by design, which is useful and also a path for sensitive values to cross into systems that shouldn't see them. Decide deliberately what goes into `baggage`\n\n, and strip or scrub it at trust boundaries rather than forwarding everything.\n\n`ttlMs`\n\non list and resource-read results`cacheScope`\n\nto match per-user or per-tenant sensitivity`baggage`\n\ncarries across boundariesSix SEPs align the authorization spec more closely with how OAuth 2.0 and OpenID Connect are deployed. These matter most to operators who run their own authorization server or broker auth in front of a server.\n\nAuthorization servers should supply the `iss`\n\nparameter on authorization responses per RFC 9207 (SEP-2468). Clients are now expected to validate it, and in a future version they will reject responses that omit it. This is a low-cost mitigation for a mix-up attack that is more likely in MCP's single-client, many-server pattern — so begin supplying `iss`\n\nnow if you don't already.\n\nThe remaining changes are smaller but worth handling together: support the OpenID Connect `application_type`\n\nduring Dynamic Client Registration so desktop and CLI clients aren't defaulted to `\"web\"`\n\nand rejected (SEP-837); bind registered credentials to the issuing authorization server's `issuer`\n\nand re-register when a resource migrates (SEP-2352); document how to request refresh tokens from OIDC-style servers (SEP-2207); and follow the clarified scope-accumulation and `.well-known`\n\ndiscovery rules (SEP-2350, SEP-2351).\n\n`iss`\n\non authorization responses`application_type`\n\nin Dynamic Client RegistrationTool `inputSchema`\n\nand `outputSchema`\n\nare lifted to full JSON Schema 2020-12 (SEP-2106). Input schemas keep the `type: \"object\"`\n\nroot but now allow composition (`oneOf`\n\n, `anyOf`\n\n, `allOf`\n\n), conditionals, and references (`$ref`\n\n, `$defs`\n\n). Output schemas are unrestricted, and `structuredContent`\n\ncan be any JSON value rather than only an object.\n\nTwo constraints in this change are security constraints, and the spec states them as requirements. Implementations must not auto-dereference external `$ref`\n\nURIs — a schema that points `$ref`\n\nat an external URL is an SSRF and unbounded-fetch vector if you follow it. And implementations should bound schema depth and validation time, because a deeply nested or recursive schema is a denial-of-service input. If your server validates against client-supplied or third-party schemas, enforce both.\n\nSeparately, the error code for a missing resource changes from the MCP-custom `-32002`\n\nto the JSON-RPC standard `-32602`\n\nInvalid Params (SEP-2164). If any code matches on the literal `-32002`\n\n, update it.\n\n`$ref`\n\nURIs`-32602`\n\nfor missing resources, and update any matching on `-32002`\n\nRoots, Sampling, and Logging are deprecated under the new feature lifecycle policy (SEP-2577). These are annotation-only deprecations: they keep working in this release and in every spec version published within a year, and removal requires a separate SEP. There is no forced cutover on July 28 — but plan the replacements now.\n\nThe documented replacements are tool parameters, resource URIs, or server configuration in place of Roots; direct integration with an LLM provider API in place of Sampling; and `stderr`\n\n(for stdio transports) or OpenTelemetry in place of Logging.\n\nExtensions are now first-class (SEP-2133). They are identified by reverse-DNS IDs, negotiated through an `extensions`\n\nmap on client and server capabilities, and versioned independently of the specification.\n\nTwo official extensions ship with this release. Tasks graduates from an experimental core feature to an extension with a redesigned, stateless lifecycle: a server answers `tools/call`\n\nwith a task handle, and the client drives it with `tasks/get`\n\n, `tasks/update`\n\n, and `tasks/cancel`\n\n. `tasks/list`\n\nis removed (SEP-2663) because it can't be scoped safely without sessions. Anyone who built against the `2025-11-25`\n\nexperimental Tasks API needs to migrate.\n\nMCP Apps (SEP-1865) lets servers ship interactive HTML interfaces that hosts render in a sandboxed iframe. Tools declare their UI templates ahead of time so hosts can prefetch, cache, and security-review them before anything runs, and every UI-initiated action goes through the same audit and consent path as a direct tool call.\n\n`extensions`\n\ncapability mapThe ten-week window between the May 21 lock and the July 28 final exists for exactly this: validate the changes against real workloads before they become normative. Start a migration branch if you operate a remote MCP server, run your own authorization, or build against the experimental Tasks API. The transport rework is the largest piece; the auth and schema constraints are the ones with security teeth.\n\nMost of these are checkable from outside the server — the routing-header enforcement, the cache scope on list responses, the `$ref`\n\nhandling, the `iss`\n\nparameter. Gated inspects deployed MCP servers against these and the rest of [its check library](https://dev.to/docs/catalog), mapping each to the [conformance](https://dev.to/docs/catalog/conformance) and [security](https://dev.to/docs/catalog/security) families with a reproduction for every finding — including private and internal servers [reached from inside your network](https://dev.to/security). If a security team wants the posture of a server in writing before July 28, that's the kind of thing it produces.\n\n— Gustavo, Gated", "url": "https://wpnews.pro/news/the-2026-07-28-mcp-spec-a-server-readiness-checklist", "canonical_source": "https://dev.to/gustavo_gated/the-2026-07-28-mcp-spec-a-server-readiness-checklist-14nf", "published_at": "2026-06-19 15:15:56+00:00", "updated_at": "2026-06-19 15:37:08.185537+00:00", "lang": "en", "topics": ["ai-infrastructure", "developer-tools", "ai-safety", "ai-policy", "ai-research"], "entities": ["Model Context Protocol", "SEP-2575", "SEP-2567", "SEP-2243", "SEP-2260", "SEP-2322", "Streamable HTTP", "InputRequiredResult"], "alternates": {"html": "https://wpnews.pro/news/the-2026-07-28-mcp-spec-a-server-readiness-checklist", "markdown": "https://wpnews.pro/news/the-2026-07-28-mcp-spec-a-server-readiness-checklist.md", "text": "https://wpnews.pro/news/the-2026-07-28-mcp-spec-a-server-readiness-checklist.txt", "jsonld": "https://wpnews.pro/news/the-2026-07-28-mcp-spec-a-server-readiness-checklist.jsonld"}}