MCP's 2026-07-28 revision makes every request carry what the server needs to answer it

Per-request capabilities ^[5] reach past extension support into result validation. Every result carries a resultType, and the legal set is the core values plus whatever extensions this particular client declared ^[13]. Checking what a client supports used to be a lookup a server could do once and cache. Now it runs on every call ^[5].

A laptop with one client is the one deployment where a Map keyed by connection always behaves ^[9]. Past that point, the author wrote, "Stateful leakage doesn't throw. It just quietly works in dev and then produces rare, unreproducible bugs in production once a second instance exists." ^[8]

The repo's answer is a test I would copy into any MCP server. It boots two completely separate instances and sends one multi-round-trip exchange across both: the exchange opens on the first, gets its reply on the second and closes back on the first ^[10]. The instances share no memory, only the secret key that signs continuation tokens ^[10]. If any state had leaked into instance memory, the exchange would fall apart ^[10]. "It's the one I trust most in the whole repo," the author wrote ^[11].

In my view, the routing headers are the best design in the revision. Mcp-Method and Mcp-Name let a gateway route a request without parsing the body. The spec makes disagreement between header and body an error, code -32020 ^[15]. "Implementing that mismatch rule is the whole reason the header can be trusted," the author wrote ^[18]. The smaller rules are just as exact. Reservation of _meta key names turns on the second label of a prefix, so com.mcp.tools/ is reserved for MCP and com.example.mcp/ is not ^[12]. The error-code bands include a couple of codes a server may never use ^[14].

Of the 708 tests, 140 are conformance tests named after the requirement they assert ^[4]. That is about one in five ^[1]. The author's rule was that any spec sentence containing a MUST got a test named after it ^[17]. Those 140 tests measure conformance to one reader's parse of the spec. They carry over to another implementation only if his reading of each MUST matches what the spec authors meant and what the other implementer understood.

Who has to redesign follows from one sentence of the revision. A server may not assume anything based on earlier requests on the same connection ^[2]. With initialize and Mcp-Session-Id gone ^[1], a server that keeps per-connection state has to move that state into names the client carries, or drop it ^[6]. A server that already handles each call on its own has less to change. All of this comes from one implementer's from-scratch build ^[3], and the post does not cover migrating an existing session-based server.