# MCP Release Overview: Stateless and the Big Changes in the New Spec

## Executive summary

The latest MCP specification introduces a major architectural shift toward statelessness, fundamentally changing how clients and servers interact. This transition addresses scalability issues inherent in previous stateful designs by ensuring every client request contains all necessary information for the server instance to process it independently. Key updates include Multi Roundtrip Requests (MRTR) for complex flows, formalizing extensions (like MCP Apps and Tasks), and enhancing authorization adherence.

## Key takeaways

- Transition to Stateless Architecture: MCP is moving from a stateful model that relied on session IDs and retained server-side state (requiring an `initialize` call) to a fully stateless design. This eliminates the need for complex shared session stores or sticky load balancing, enabling easier horizontal scaling across multiple server instances.
- Multi Roundtrip Requests (MRTR): MRTR simplifies complex tool calls by breaking them into multiple, discrete requests rather than relying on open streams and waiting for responses. This significantly reduces architectural overhead when deploying services behind load balancers.
- Formalized Extensions: The protocol now supports formal extensions, allowing developers to add specialized functionality without modifying the core spec. Key examples include MCP Apps (for delivering rendered UI) and Tasks (for modeling long-running processes like database migrations or human-in-the-loop workflows).
- Authorization Improvements: The specification enhances adherence to OAuth standards, requiring authorization servers to return the `iss` parameter. Clients must validate this before redeeming a code.

## Technical details

- Statelessness and Scaling: In previous versions, state was maintained via an initial `initialize` call, creating challenges for horizontal scaling (load balancing) because session state was not retained when requests were routed to different server instances. The new spec ensures every request is self-contained.
- Multi Roundtrip Requests (MRTR): MRTR allows a single logical operation (like a tool call requiring elicitation) to be completed across multiple, independent client requests. This replaces the old pattern of keeping an open stream and waiting for a response from a specific server instance.
- MCP Apps Extension: This extension allows developers to deliver fully rendered UI (HTML, JavaScript, CSS) directly through the MCP protocol, improving client capabilities across supported clients like Goose. This is now formally recognized as the first official extension.
- Tasks Extension: The Tasks extension models asynchronous or long-running processes. A server initiates a task and returns a Task ID; the client can then poll for status updates, receiving either an input requirement state or the final result upon completion.

## Practical implications

- Developers should prioritize using the official language SDKs (e.g., Rust SDK v3.0.0) to minimize manual message construction and simplify updates to the new protocol.
- Architectures must be designed for statelessness, ensuring that no critical session state is assumed or stored locally on a single server instance.
- Leveraging extensions like Tasks allows complex, multi-day processes (e.g., database migrations) to be modeled within the MCP framework.
- Adopting the latest SDKs will significantly reduce development effort when adapting existing applications to the new protocol version.

## Topics

MCP Protocol, Stateless Architecture, Agentic AI, Protocol Design, API Development, Goose, Agentic AI Foundation (AAIF), Rust SDK for MCP

Source: https://www.youtube.com/watch?v=-uvKf47fbbY