How MCP’s Sessionless Protocol Forces a Rethink of Enterprise AI Architecture

This Upgrade Changes How MCP Works

For the past six months many teams have connected to MCP the way early APIs were used: they spin up a server for each business need and hand out a token to each Agent. This approach scales quickly at first, but when the number of servers grows from three to thirty the management overhead explodes—tool catalogs become unwieldy, permission boundaries blur, logs are scattered, and it becomes impossible to tell which Agent represents whom.

On July 28 MCP released a new version of its protocol. The most visible change is the removal of the session concept, but the deeper impact is that MCP is shifting from a developer‑connection protocol to a standard HTTP workload that can sit inside enterprise infrastructure.

What Exactly Has Changed?

The old remote MCP connection relied on an initialization handshake and a Mcp-Session-Id. Gateways had to remember which request belonged to which session, and backend instances often depended on sticky routing or shared session storage.

The new specification drops the initialize/initialized handshake and the Session ID. Each request now carries the protocol version, client information, and a capability description, allowing any backend instance to handle it independently. Clients that need to discover server capabilities can call server/discover.

According to the official MCP announcement dated 2026‑07‑28, the new remote MCP server can be placed behind a regular round‑robin load balancer because the protocol no longer ties a session to a specific instance. With Mcp-Method and Mcp-Name in the HTTP headers, gateways can perform routing, authentication, and auditing directly based on method and tool name.

In short, MCP now behaves much more like a familiar enterprise API.

Stateless Protocol ≠ Stateless Business

Although the protocol itself is stateless, business state such as long‑running task progress, approval results, Agent memory, and intermediate artifacts must still be persisted. These states should be visible, traceable, and expirably stored as business objects, not hidden inside transport sessions. Architects must decide where the state lives, who creates it, and who is authorized to use it.

Redesigning the Enterprise AI Access Layer

If the architecture continues to follow a “one Agent directly connects to many MCP servers” model, the new protocol only simplifies deployment and does not solve governance problems. A more robust structure adds a unified access layer—often called an “MCP gateway”—that fulfills four responsibilities:

Traffic Layer: Determines where requests go and how to scale; requires no sticky routing, supports timeouts, rate limiting, and circuit breaking.

Identity Layer: Clarifies who is calling and on whose behalf; enforces separation of user, Agent, and sub‑Agent identities.

Tool Layer: Manages which tools can be discovered and executed; includes tool tiering, version control, and progressive discovery.

Audit Layer: Records full‑trace logs, masks sensitive parameters, and retains result footprints.

Identity Management Challenges

The identity layer is often the most overlooked. Traditional OAuth assumes a human in a browser granting consent. In production, an Agent may act on behalf of a user, a backend service, or a delegated sub‑Agent, none of which are necessarily present to approve actions.

The MCP roadmap released on August 22 highlights Agent Identity and enterprise‑ready security as priority directions, explicitly mentioning workload identity, delegated authorization, and standard Token Exchange. This signals that enterprises can no longer rely on copying long‑lived API keys to every Agent and hoping prompt‑based constraints will suffice.

Don’t Conflate “Can Call” with “Is Authorized to Call”

A usable permission model must distinguish three aspects:

Who the caller is—an employee, a backend service, or an automated Agent.

Who the caller represents—either a user or a specific application workload, each with different data access.

What the call is allowed to do—reading a knowledge base should not share the same broad permission as deleting production data.

MCP’s authorization spec requires access tokens to be bound to target resources and forbids passing downstream tokens unchanged. In practice this means using short‑lived tokens, explicit audiences, minimal scopes, and delegating only the permissions needed for the current task.

OWASP’s MCP Top 10 lists token leakage, over‑privileged scopes, tool poisoning, shadow MCP servers, and insufficient audit as major risks. As the number of MCP integrations grows, these risks shift from isolated configuration errors to systemic vulnerabilities.

More Tools Do Not Mean Smarter Agents

Another common misconception is equating the number of exposed tools with the capability of the Agent. The official roadmap notes that when a server exposes hundreds of tools, the model must bear the context cost before the user even asks a question, and tool selection quality degrades.

To address this, MCP is advancing “Progressive Discovery”: the service first presents a narrow entry point and gradually reveals more specific tools as the task proceeds.

Enterprises should therefore avoid dumping all capabilities—database queries, approvals, deletions, notifications—into the model at once. Instead, they should narrow the catalog by domain, risk, and task stage. Read‑only tools can be auto‑discovered; write operations need stricter scopes; high‑risk actions (financial changes, production modifications, outbound messages) should require manual confirmation.

Tool catalogs should have owners, versioning, and deprecation dates. Without a responsible owner, an MCP server will eventually become a “shadow API.”

What Architects Should Focus On Now

The upgrade does not require an immediate rewrite of every MCP server. The first step is to examine whether the current integration mixes transport concerns, identity, tools, and business state.

If the gateway merely forwards traffic, relies on a single long‑lived token, exposes the full tool list, and lacks complete call records, adding more servers will only increase future refactoring costs.

Conversely, if MCP is treated as a standard HTTP workload with explicit business state storage, verifiable identity and delegation, and staged tool exposure, existing API gateways, IAM systems, observability platforms, and change‑management processes can largely be reused.

The greatest value of the new specification is not the eliminated handshake but the architectural question it forces: when Agents act on behalf of people and systems, who will identify them, limit them, and reconstruct their actions after a failure?

Original content, please do not reproduce without permission.