8/8/2026↻ Updated 8/8/2026

MCP 2026–07–28: why a remote MCP server needs more than an SDK upgrade

Vývojář kontroluje architekturu nástrojového serveru a síťové požadavky MCP

The 2026-07-28 Model Context Protocol revision is more consequential than its date-like name suggests. MCP originated at Anthropic and is now developed as an open project. This is not simply a new Claude connector: it changes how remote clients and servers establish a connection, carry metadata and manage longer interactions.

If you only consume packaged MCP servers in Claude, Codex or ChatGPT, do not rush to change anything. Implementations should negotiate the highest mutually supported version and legacy protocol versions remain available. If you run a remote MCP server over your CRM, ERP, documents or internal tools, audit the architecture now.

What changes

Discovery replaces initialize

The older protocol begins with an initialize handshake and server-held session state. The new revision uses server/discover: a client learns supported versions and capabilities first. Protocol version, client information and capabilities travel in _meta on every request.

This helps horizontal scaling because the next request need not hit the same process or pod. It also means that authentication, authorization and audit cannot live vaguely “in the session”.

Stateless HTTP is not a cosmetic change

Streamable HTTP can operate without sessions. A production endpoint becomes easier to load-balance and retry through an ordinary gateway, but each request must now carry a traceable identity, tenant, scope and correlation ID.

A minimal internal MCP-server design:

  • the gateway validates an OAuth token or service identity;
  • authorization maps identity to a tenant and allowed tools;
  • the server receives request context with a correlation ID;
  • every tool call writes an audit record: who, tool, business object and result;
  • idempotent or multi-step operations store state in a database or queue, never only process memory.

Multi-round-trip requests

New multi-round-trip requests replace older server-initiated behavior. Long or interactive work becomes an explicit sequence of request/response steps: ask the user to choose an account before issuing an invoice, continue an export after a batch finishes, or collect a confirmation before an action. Every step needs a timeout, retry limit and recoverable state.

Extensions and deprecated capabilities

The revision formalizes an extensions layer and deprecates some older capabilities, including Roots, Sampling and Logging. Do not disable servers wholesale. Separate your actual API contract from client-specific convenience, then replace legacy dependencies with explicit audit or configuration mechanisms.

A migration without downtime

  1. Inventory clients and SDKs. Identify callers, negotiated versions and support for 2026-07-28.
  2. Keep compatibility. A new implementation should fall back to 2025-11-25; legacy clients should retain their old handshake.
  3. Remove session dependencies. Move import state, confirmations and rate-limit state into durable storage. Never derive authorization from a random session ID.
  4. Test through the gateway. Exercise retries on another pod, expired tokens, tenant changes, parallel requests and client disconnection during a multi-step operation.
  5. Measure migration—not only HTTP 200. Track new-version adoption, failed discovery, legacy fallbacks, authorization denials and unfinished requests.

Do this this week

List your custom remote MCP endpoints and ask: does the server hold anything important only in RAM? Is every tool call auditable from identity to specific business object? Does a retry work when it reaches another server?

Start with one representative read-only tool, such as invoice lookup or CRM lookup: make it stateless, gateway-authorized and auditable. Then migrate action tools with a human approval gate and an idempotency key.

Sources