MCP 2026-07-28 Stateless Agents

MCP has removed its protocol-level sessions and startup handshake. Production agent platforms now need explicit state, restart-safe tasks and a tested migration path across clients, gateways and tool servers.

An MCP server that keeps everything in process memory can work perfectly until a load balancer sends the next call to another instance.

That failure is easy to miss in a developer test because one client talks to one server for a short session. Production looks different. Instances restart, traffic moves, users arrive through several front ends and long-running tool calls outlive the process that accepted them.

The stable Model Context Protocol revision dated 28 July 2026 addresses that fault line directly. MCP is now stateless at protocol level. The initial handshake has gone, each request identifies its protocol version and capabilities, and clients can ask a server what it supports through server/discover. Notifications, multi-step input and long-running tasks also follow new patterns.

Private-agent teams should not read this as a routine SDK update. It changes where state lives, how services scale and what a migration test must prove.

The Short Answer

Move towards the new MCP revision when your agent platform needs horizontal scaling, replaceable server instances or cleaner service boundaries. Do not migrate production by changing a version string and hoping negotiation hides the differences.

Inventory every current dependency first:

session identifiers and in-memory conversation state;
use of initialize, roots, sampling or protocol logging;
HTTP GET or SSE notification behaviour;
server-initiated requests such as elicitation;
long-running jobs tied to a connection;
client and server SDK versions.

Then build a compatibility test around real tools. A stateless protocol can make the transport easier to scale, but the application still needs durable state for jobs, approvals, credentials, files and audit records.

Teams planning an owned agent platform can compare that migration work with the GPUMachines Private Agent Fleet solution. Hardware comes after the trust boundary and service design are clear.

What Reached Stable Release

The official MCP GitHub release marks 2026-07-28 as stable. The authoritative specification describes self-contained requests, per-request capability negotiation and a server discovery method. It still uses JSON-RPC 2.0, but several assumptions around the transport and connection lifecycle have changed.

The official changelog is the document to read before touching a production deployment. Major changes include:

removing protocol-level sessions and the Mcp-Session-Id header;
removing the initialize and notifications/initialized handshake;
adding server/discover;
replacing several notification paths with subscriptions/listen;
replacing server-initiated requests with Multi Round-Trip Requests;
moving tasks out of the core protocol into an official extension;
adding required result types and cache metadata;
deprecating roots, sampling, logging, HTTP+SSE and Dynamic Client Registration.

Some SDKs will support the revision before others. The official Go SDK release notes show one implementation route and retain negotiation with older versions. That is useful evidence of migration intent, but it does not prove that every client, proxy and server in your stack has caught up.

Stateless Protocol Does Not Mean Stateless Work

This is the distinction most likely to cause trouble.

A protocol request can carry everything needed to understand its version and capabilities without relying on a connection session. The tool behind that request may still create a job that runs for an hour, waits for approval, writes files or needs a result collected tomorrow.

That state must live somewhere explicit:

a database record for job identity and status;
object or file storage for inputs and outputs;
a queue for work that survives process restarts;
a secret broker for short-lived credentials;
an audit system that records who asked for what;
a policy service that decides which actions remain allowed.

If that information stays in a server's memory, the protocol has become stateless while the deployment has not. Horizontal scaling will still fail whenever a request lands on the wrong replica.

The useful design test is brutal: terminate any MCP server instance between two related calls. If the client cannot continue safely through another instance, hidden state remains.

Why `server/discover` Changes Startup

Older MCP flows used an initial exchange to establish protocol version and capabilities. The new revision makes server/discover the up-front way to learn what the server supports, while each ordinary request carries the client's version and capabilities in _meta.

This supports replaceable server instances because a connection no longer owns the negotiated relationship. It also makes gateways more important. A gateway can inspect method and version information on each request, route to a compatible backend and reject unsupported combinations before a tool runs.

But discovery creates its own operational questions:

Is the discovery response identical across every replica?
How quickly does it change after a deployment?
Can a cached response outlive the backend version it describes?
Does the gateway route old and new protocol traffic to separate pools?
What happens during a rolling update when replicas advertise different capabilities?

The new specification adds cache hints to several results. Operators should use those deliberately. A stale tool list can be a correctness or security problem if a removed tool continues to appear available.

Version negotiation belongs in monitoring. Record the requested version, selected backend and rejection reason so support teams can distinguish an incompatible client from a failed tool.

Per-Request Metadata Improves Scaling and Raises the Validation Burden

Each request now carries protocol version and client capabilities. Clients should identify themselves; servers should return identity information in result metadata.

That removes dependence on a prior handshake, which suits load-balanced services. It also means the server must validate every call rather than trusting a connection that was checked once.

Do not treat _meta as trusted merely because the client supplied it in the expected shape. Validate supported versions and capabilities, enforce method-level policy and bind identity to real authentication. A client claim is not proof that the caller may use a tool.

Gateways should cap metadata size and reject malformed fields before forwarding. Logs need enough information for diagnosis without copying secrets or sensitive prompts. The protocol makes requests self-contained; it does not require careless duplication of private data across every telemetry system.

For multi-tenant agents, keep authentication and capability negotiation separate. Authentication answers who the caller is. Authorisation answers which resources and tools that identity may use. MCP capability fields describe protocol behaviour, not business permission.

Notification Handling Has Moved

The revision replaces the old HTTP GET endpoint and several free-standing resource notification methods with subscriptions/listen, a long-lived POST-response stream. Clients choose the classes of change they want to receive, and the server tags notifications with a subscription identifier.

Request-scoped progress remains attached to the response stream for that request. This separation is sensible, though it changes proxies and timeout behaviour.

A normal API gateway may buffer long responses, terminate quiet connections or impose a maximum request duration. Those defaults can break subscriptions even when the MCP implementation is correct. Test the complete path through CDN, proxy, ingress controller and service mesh.

The new transport also removes SSE resumability and message redelivery. When a response stream breaks, the client needs to issue a new request with a new request ID. That puts idempotency in plain view. A retry must not submit the same purchase, delete the same record twice or launch another expensive compute job.

Every tool with side effects needs an explicit retry policy. Read-only calls are easier. Mutating calls may need idempotency keys stored with durable results.

Multi Round-Trip Requests Replace Server-Initiated Calls

MCP previously allowed server-initiated requests for features such as sampling, roots and elicitation. The 2026-07-28 revision introduces Multi Round-Trip Requests, often shortened to MRTR.

Instead of opening a reverse request from server to client, the server returns an input_required result with details of what it needs. The client obtains the missing information or approval, then retries the original request with an inputResponses field.

This fits ordinary request-response infrastructure better. It also gives the client a clearer place to show a user what is being requested.

The security benefit depends on implementation. A client must bind the follow-up to the correct original operation, prevent tampering with request state and show enough context for meaningful consent. “Allow?” is not a useful approval prompt if the user cannot see which tool, file, destination and consequence sit behind it.

Keep the policy engine outside the model's writable state. An agent should not approve its own request by manufacturing an input response.

Tasks Are Now an Extension

Long-running operations have moved from the core protocol into the official tasks extension. The redesign uses durable task handles, polling through tasks/get and client input through tasks/update.

That is a better match for jobs such as model conversion, data indexing, research runs, code analysis or remote deployment. The task can outlive one HTTP stream and one server process.

It also exposes the part many pilots skip: a task service needs retention, access control and recovery rules. Who can query a handle? How long does it remain valid? Can one tenant guess another tenant's task identifier? What happens when a worker dies after making an external change but before recording completion?

A production task record should usually contain:

1. an opaque identifier with tenant ownership; 2. the accepted tool and normalised arguments; 3. idempotency information; 4. state transitions and timestamps; 5. references to input and output objects; 6. approval and cancellation history; 7. the software or worker version that ran it; 8. an expiry or retention policy.

Do not put large artefacts directly into the control record. Store them in a suitable data service and keep permission-checked references.

Deprecations Need an Owner

Roots, sampling and logging remain in the specification for a deprecation window, but new implementations should not add them. HTTP+SSE also moves further towards removal, and the specification prefers Streamable HTTP.

The worst migration plan is to leave each application team to discover these changes independently. Assign an owner for the shared MCP gateway, SDK policy and compatibility matrix.

Roots need special attention because they often carried local directory context. The new guidance points teams towards tool parameters, resource URIs or server configuration. That can improve clarity, yet passing filesystem paths through tool arguments creates validation work. Canonicalise paths, enforce allowed roots at the server and prevent traversal beyond the authorised workspace.

Sampling deprecation means an MCP server should not assume the client will call a model on its behalf. If the service needs model inference, integrate with an approved provider or internal model endpoint under its own policy. That changes credentials, billing and data-flow review.

Protocol logging should move towards normal service logging and OpenTelemetry. Avoid mixing application logs with model-facing messages.

A Production Topology for the New Revision

The new protocol suits a layered deployment.

At the front, an authenticated gateway terminates transport, validates request size and version, applies rate limits and sends traffic to compatible MCP server pools. Server replicas remain disposable; they read durable state through approved services rather than local memory.

Behind them, a queue and task store coordinate long work. Tool workers run in isolated environments with bounded network access and short-lived credentials. File or object storage holds inputs and results. Audit events move to a separate system that the agent cannot edit.

Subscriptions may use a dedicated service or pool because long-lived response streams behave differently from short tool calls. Separating them prevents thousands of quiet listeners from consuming all ordinary request capacity.

Model serving can remain another tier. A small MCP tool server does not need a GPU merely because an AI agent calls it. GPUs belong where the model or accelerated tool uses them; the protocol gateway, policy service and task database may run efficiently on CPU systems.

That separation saves money and makes failures easier to contain.

Hardware Implications Are Indirect but Real

MCP itself is a protocol, so the revision does not mandate a GPU model, network speed or server chassis. The application around it can change the infrastructure brief.

Stateless replicas favour horizontal CPU capacity and dependable load balancing. Long-running tool workers may need GPU servers for code execution, simulation, image work or private inference. Durable tasks add database and storage traffic. Subscriptions add concurrent connections. Audit and tracing add write volume.

An agent fleet that uses a private LLM also needs model-serving capacity sized from actual traffic: model size, precision, context length, concurrent sessions, agent turns and tool-call frequency. Repeated agent context can put pressure on KV cache and scheduler design, as covered in the GPUMachines article on agentic AI serving and KV-cache scheduling.

Do not place every service on the GPU hosts by default. Keep scarce accelerator memory and CPU headroom available for work that needs them. A separate control-plane server may be cheaper and easier to patch.

Migration Plan Without a Flag Day

A mixed-version period is safer than changing every client and server at once.

Map the current behaviour

Record methods, transports, client libraries, server libraries, authentication, session assumptions and all side effects. Capture production traces with sensitive values removed. Unknown usage blocks a safe migration.

Add contract tests

Test discovery, version mismatch, capability changes, idempotent retries, broken streams, task recovery, cancellation and authorisation. Include an instance restart between related calls.

Stand up a new pool

Route a small set of compatible clients to a 2026-07-28 server pool. Keep older traffic on the existing path. Compare errors, latency and tool results rather than only request counts.

Move state out of processes

Durable jobs, approvals and file references need an external store before replicas become disposable. Do not use sticky sessions as a permanent disguise for hidden state.

Exercise rolling updates

Run mixed server versions behind the gateway and confirm discovery reflects the selected pool. Drain subscriptions deliberately. Test a rollback.

Remove deprecated dependencies

Migrate roots, sampling, logging and old notification patterns under an owned schedule. Publish the cut-off date to internal client teams.

Audit the public boundary

Recheck tool descriptions, schemas, credentials, allowed destinations and consent prompts. A protocol migration is a good time to remove tools that should never have been exposed.

Who Should Migrate Soon

Teams already fighting sticky sessions, uneven replicas or restart-sensitive tools have a direct reason to adopt the new model. Platforms preparing a new production MCP gateway should build against the stable revision rather than adding fresh dependencies on deprecated features.

Private-agent services with several clients also benefit from explicit discovery and version routing. The same applies to hosted MCP providers that need to upgrade customer tenants at different times.

But “soon” still means after SDK and integration tests. A stable specification does not make every library stable on the same day.

Who Should Wait

A small internal pilot on one machine may gain little from an immediate migration, particularly if its chosen SDK has not shipped stable support. Keep the pilot isolated, record its deprecated dependencies and avoid expanding it into production unchanged.

Do not migrate during a business-critical release merely to claim the latest protocol. The old revision can remain behind a controlled compatibility gateway while the new path is tested.

Teams with tools that make irreversible external changes should wait until they have idempotency and audit controls. Stateless retries increase the chance that weak side-effect handling becomes visible.

What to Test Before Buying More Agent Hardware

Protocol work can expose whether the current bottleneck is compute at all.

Measure gateway CPU, request rates, concurrent subscriptions, queue depth, task duration, model latency, storage I/O and tool-worker utilisation. If GPUs spend time waiting for approvals or external APIs, buying more accelerators will not solve the delay.

For private model serving, capture model memory, context, concurrency and session shape. For tool workers, separate CPU-only tools from GPU-dependent work. Put code execution and untrusted artefacts in isolated workers rather than beside the model endpoint.

The GPUMachines guide to configuring Hermes Agent on compact AI systems covers a smaller local route. It suits a contained pilot; it is not a substitute for the distributed controls described here.

Buying Through GPUMachines

GPUMachines can help turn an agent workload into a hardware and deployment brief. That may involve an SFF or tower system for development, a PCIe GPU server for isolated workers, an HGX platform for larger private models, or a hosted fleet with separate control-plane services.

The review should start with boundaries: where prompts and files may travel, which tools execute code, how tasks survive restarts, how many agents run at once and who operates the service. Only then should the buyer select GPUs, RAM, NVMe and networking.

For organisations that want owned equipment without building the facility layer, Buy & Host can provide a deployment route. Software architecture, security policy and operational responsibility still need named owners.

Questions from Agent Platform Teams

Does stateless MCP remove the need for a database?

No. It removes protocol-level connection state. Applications still need durable storage for jobs, approvals, outputs, credentials, tenant policy and audit records.

Will old MCP clients continue to work?

Compatibility depends on the client, server and SDK. The protocol supports version negotiation, and some SDKs preserve older revisions, but you must test the exact combination.

Is `server/discover` an authentication method?

No. It reports supported versions, capabilities and identity information. Authentication and authorisation still require their own controls.

Do stateless servers need sticky sessions?

They should not depend on them for protocol operation. A service may still choose affinity for performance, but correctness should survive routing to another compatible replica.

Does the new task extension require GPUs?

No. A task may run on CPU, GPU or an external service. Select worker hardware from the tool's actual workload.

What breaks if a subscription connection drops?

The client reconnects using the supported subscription flow. In-flight ordinary requests may need to be issued again with a new request ID, so side-effecting tools need idempotency protection.

Should every MCP server run behind one gateway?

Not necessarily. A shared gateway can centralise version checks and policy, but high-risk or regulated tools may need a separate boundary. Avoid one unrestricted gateway that can reach everything.

Sources and Further Reading

Verdict

MCP's stateless revision removes connection assumptions that made production scaling awkward. It does not remove the hard state in an agent system; it forces teams to put that state somewhere visible and operable.

That is healthy. Durable task records, explicit version routing, permission-checked tools and restart-safe workers are easier to inspect than a session living inside one lucky process.

GPUMachines buyers should use the migration to separate protocol services from model serving and tool compute. Measure each tier, then buy the hardware its work actually requires.

Discuss a private, hosted agent platform with GPUMachines through the Buy & Host route.

MCP 2026-07-28 Is Stateless: What Private AI Agent Teams Need to Change