Why MCP’s Return to HTTP Highlights Architecture and Engineering as Scarce Resources

Higress, which was the first in China to support MCP Server, is adding support for the newest MCP version and will release it this week. Earlier milestones include the open‑source Remote MCP Server hosting solution (March 2025) and bulk conversion of existing OpenAPI definitions to MCP Server (April 2025), as well as a comparative analysis of Streamable HTTP versus HTTP+SSE.

The core change in the latest version is the shift from a stateful protocol that relied on an initialize/initialized handshake and a Mcp-Session-Id to a completely stateless request/response model. This returns MCP to the well‑tested HTTP paradigm, where each request carries its own protocol version, client identity, and capabilities.

In the previous stateful design, a single session had to be bound to the same server instance. For example, an Amap MCP Server handling a user query about nearby charging stations must invoke three tools—geocoding, POI search, and route planning—within the same session, requiring session affinity. When traffic grows and multiple instances are deployed, load balancers must preserve this affinity, adding architectural overhead.

The new version retires the handshake and session identifier (SEP‑2575, SEP‑2567). Requests are self‑describing, allowing ordinary round‑robin load balancing without shared storage. New mandatory headers Mcp-Method and Mcp-Name (SEP‑2243) let gateways and rate limiters route and meter traffic directly.

Despite these improvements, the community’s main complaints—context crowding and high cost—remain largely unaddressed. Context crowding stems from pre‑loading all tool definitions, which consumes a significant portion of the token window. The update adds ttlMs and cacheScope to tools/list, prompts/list, and resources/list (SEP‑2549), enabling caching of tool catalogs, but it does not reduce the per‑turn token usage of tool definitions.

Adopting the stateless model also introduces migration overhead. Implementations that depended on session identifiers must be refactored, and several features are deprecated: Dynamic Client Registration (moved to CIMD), Roots, Sampling, Logging, and the legacy HTTP+SSE transport are all slated for removal.

In summary, the upgrade does not introduce novel mechanisms; it re‑applies mature web‑architecture techniques to meet scaling and operational demands. The real challenge lies in delivering a scalable, low‑cost experience, which requires solid architectural design and extensive engineering practice—resources that are increasingly scarce in the AI era.