A migration worksheet for MCP’s stateless 2026-07-28 wire model

The 2026-07-28 MCP revision changes the wire contract at the places platform teams tend to discover late: session assumptions, request metadata, and HTTP routing. The authoritative MCP specification documents a stateless protocol model, per-request metadata, and standardized transport requirements. Microsoft’s official C# SDK v2.0 announcement describes those revision elements as stateless-by-default HTTP, standardized routing headers, and Multi Round-Trip Requests, with ASP.NET Core support for routing, middleware, load balancing, and horizontal scale.

That evidence establishes what the documents specify and announce. It does not establish that a particular deployment already behaves correctly after an upgrade. Treat the worksheet below as an SGL implementation and test prescription derived from those documented contract changes.

Inventory the old contract before changing code

Record where the current server or client assumes a protocol session exists:

• session identifiers stored in process memory, caches, or databases;
• initialization state that is expected to survive across requests;
• middleware that derives authorization or routing context from a session;
• tests that send a sequence of requests but do not test independent requests.

For each assumption, mark its owner, storage location, expiration behavior, and failure response. A stateless target makes these assumptions visible; it does not by itself tell you how your application should replace them.

Make request metadata explicit

Create a request-metadata table with four columns: field, producer, consumer, and test. Include authentication or routing metadata only where your application actually uses it. Then test that each request carries the metadata needed to process it without relying on hidden session state.

The specification documents per-request metadata, while the SDK announcement names standardized routing headers. The exact fields and semantics remain the specification and SDK documentation’s domain; do not infer additional headers from the announcement alone.

Test HTTP routing at the boundary

Exercise the deployed HTTP path through the same intermediaries that production traffic will use. A useful worksheet row includes:

1. incoming method and path;
2. routing or forwarding headers;
3. middleware transformations;
4. selected handler or tool endpoint;
5. response status and metadata;
6. evidence retained for review.

The C# SDK announcement explicitly describes ASP.NET Core support for routing and middleware, plus load balancing and horizontal scale. That documents an integration path, not proof of scale behavior in your environment. Add tests for direct access and for each proxy or load-balancer path you operate.

Check SDK compatibility as an evidence question

Pin the SDK version and the MCP revision in the worksheet. For every adapter, record whether it supports the stateless HTTP mode, routing headers, and Multi Round-Trip Requests described in the v2.0 announcement. Separate “the SDK exposes this capability” from “our server passes the corresponding end-to-end test.”

A minimal compatibility record can contain:

• protocol revision;
• SDK and runtime versions;
• transport mode;
• routing configuration;
• metadata fixtures;
• independent-request test result;
• multi-round-trip test result;
• unresolved deviations and owner.

Run migration tests that expose hidden coupling

Use tests that deliberately remove continuity between requests. Restart a worker between related requests, route successive requests to different instances, and clear process-local state. These are proposed failure-injection techniques for validating a stateless design, not behaviors claimed by either supplied source.

Retain the request and response metadata needed to explain each failure. If a test passes only when requests reach the same worker, the worksheet should flag a remaining session dependency rather than treating the result as compatible.

The operator decision

Approve the upgrade when every identified session assumption has a replacement or an explicit disposition, request metadata is tested at the boundary, routing behavior is evidenced through your intermediaries, and SDK capability checks are paired with end-to-end results. The supplied sources document the protocol revision and an SDK implementation path; your test record supplies the deployment-specific evidence they cannot.

Use the SGL Build workspace to turn this worksheet into a versioned migration checklist and attach the resulting test evidence to the release decision.