Stateless MCP Simplifies Agent Scaling, but Not Business State

What happened

On July 28, 2026, the Model Context Protocol project released specification revision `2026-07-28`. Its central change is a stateless protocol core: a server no longer has to maintain a protocol session across separate client requests.

The `initialize` / `initialized` exchange and the `Mcp-Session-Id` header have been removed from the new lifecycle. Every request carries the protocol version, client information and client capabilities in `_meta`. A client may call `server/discover` when it wants to learn server capabilities in advance, but a mandatory handshake no longer precedes the first business request.

This sounds like a low-level implementation detail, yet the business consequence is concrete. MCP servers become easier to place behind an ordinary load balancer, scale horizontally and replace after a failure. A request is no longer tied to a particular server instance merely because that instance started a protocol session earlier.

Two meanings of “state” must remain separate. The MCP transport is now stateless; the business process is not. Deal history, a payment draft, a paused approval and an employee's permissions still need an explicit home in CRM, ERP, an orchestration database and an identity system.

What changed on the wire

With Streamable HTTP, each JSON-RPC request is sent as its own `POST`. The version appears in the `MCP-Protocol-Version` header and must match the value in `_meta`; a mismatch must be rejected. Standard `Mcp-Method` and, for tool calls or resource reads, `Mcp-Name` headers expose routing information.

An API gateway can therefore enforce several controls without parsing the full JSON body:

• route read and write operations to different pools;
• rate-limit an individual tool;
• deny dangerous methods for selected roles;
• build metrics by tool and tenant;
• locate failures faster in request traces.

Tool, resource and prompt listings now carry cache guidance. Long-running operations can use the Tasks extension, while interactions that need additional input or approval move to a multi-round-trip request model. A permanently open bidirectional channel is no longer the protocol's foundation.

The revision contains breaking changes. The official Go SDK 1.7.0 supports the new protocol while preserving compatibility with revisions through `2025-11-25`, but individual clients and servers will upgrade at different speeds. A safe migration therefore runs two versions side by side instead of replacing the whole estate overnight.

Why this matters to Russian SMEs

MCP is no longer confined to developer experiments. Russian vendors are exposing corporate systems, analytics, meeting data and business processes through the protocol. Brand Analytics, for example, announced MCP access to monitoring data for external AI services in July. This is a vendor statement, not an independent quality assessment, but it demonstrates the market direction: a standard tool interface is becoming part of commercial products.

For a small or mid-sized business, MCP is valuable when one governed interface replaces multiple bespoke integrations between an agent and CRM, knowledge management, service desk or document workflows. The stateless model brings that interface closer to conventional HTTP infrastructure that existing IT teams already know how to operate.

Transport simplicity can still create false confidence. An independent study of 1,723 MCP applications mined from GitHub found blocking approval before tool execution in only 37.2% of the sample. Logging appeared in 90.8% and enable/disable controls in 77.2%. In other words, observing an action after execution is far more common than stopping it beforehand.

A practical five-layer architecture

The production environment should separate responsibilities clearly.

1. **Local or hosted model.** The model interprets a request and proposes a tool, but it is not the system of record for a deal and does not grant itself permissions.
2. **Agent orchestrator.** It owns the operation identifier, step state, retries and approval pauses. Every write path needs stable idempotency keys.
3. **MCP gateway.** It verifies the user, tenant, protocol version, method and tool, then applies limits and policy. MCP servers should not be exposed directly to the internet merely for agent convenience.
4. **Stateless MCP servers.** Each server validates arguments and performs a narrow function. Instances can scale independently because the protocol session no longer binds a client to one process.
5. **Systems of record and audit.** CRM, ERP, document management or a transactional database stores business state. A separate audit trail connects the user, model, prompt version, tool, parameters, approver decision and result.

This division also supports a local model and MCP servers inside a protected network. Only allow-listed dependencies leave the boundary, while credentials come from a secret store rather than a prompt or arbitrary request header.

Where human approval belongs

Approving every call is ineffective because staff will learn to click automatically. Policy should follow the consequence of the action.

• Directory lookup, document search and status retrieval can usually run automatically within the user's permissions.
• Creating a draft request or email can run automatically when the result remains a draft.
• Sending a customer message, changing a record, creating an order or starting a job should trigger review when configured values, recipients or data classes are involved.
• Payments, deletion, bulk messaging, privilege changes and irreversible operations should always require blocking approval.

The approval screen must show more than a tool name. It should display normalized arguments, the initiator, the business object and the expected consequence. After approval, the orchestrator must resume the saved operation rather than ask the model to invent the call again.

Migrating without stopping operations

A staged plan is the sensible way to adopt MCP `2026-07-28`.

• Inventory clients, servers, SDKs and legacy protocol features in use.
• Check whether any business state was accidentally stored in protocol sessions or process memory.
• Deploy a compatible gateway that serves both old and new revisions.
• Move one read-only tool and test version mismatch, duplicate requests, timeout and cancellation.
• Apply policy using `Mcp-Method` and `Mcp-Name`, while still authorizing the user, tenant and requested resource.
• Review caching: tool catalogs may be cacheable, but personal data and action results require explicit policy.
• Only then add writes, idempotency and blocking approvals.

Test mixed-version paths as well: an old client with a new server, a new client with an old server, and rollback to the previous revision. SDK support does not mean every application has enabled the new mode by default.

Economics and limitations

A stateless transport can reduce infrastructure complexity. There is less need for sticky sessions or a shared protocol-session cache, and ordinary load balancers can distribute traffic while server instances are replaced freely. It is not, however, an automatic cost-saving guarantee.

Some expenditure moves into the gateway, observability, version management and durable orchestrator state. With one agent and two internal tools, an immediate migration may not repay the engineering effort. With dozens of tools, independently developed clients and rising availability requirements, a common stateless gateway can materially simplify operations.

The specification standardizes exchange, not business authorization policy or human oversight. Compatibility with MCP therefore does not equal a safe production implementation, and vendor claims or benchmark results should not be treated as proof of governance.

A ten-day next step

Choose one process with a clear owner, such as retrieving an order status and preparing a draft customer reply. Keep the first version read-only, connect no more than five tools and collect 30–50 realistic scenarios without personal data.

Track four metrics: correct tool selection, correct arguments, policy-blocked actions and recovery time after failure. Then add one write operation that produces a draft and verify a repeated request using the same idempotency key.

If the team cannot state exactly where operation state lives, who approves a write and how a duplicate is neutralized, autonomous execution is premature. The new MCP removes part of the transport burden and makes architectural gaps easier to see. That is useful maturation, not permission to remove control.