What’s New in MCP 2025: Streamable HTTP, OAuth2.1, JSON‑RPC Batch & Annotations

1. Streamable HTTP Transport Mode

The new MCP version replaces the previous HTTP+SSE remote transport with a Streamable HTTP mechanism while keeping the local stdio mode unchanged. The old approach required two separate endpoints, long‑lived SSE connections, and strict reliability, which caused scalability and flexibility issues.

Key changes include:

Server exposes a single unified HTTP endpoint (e.g., /messages) for all communication.

Clients can interact statelessly via standard RESTful POST requests, receiving a JSON response when streaming is not required.

When streaming is needed, the server can return Content‑Type: text/event-stream and send one or more JSON‑RPC messages over an SSE‑like stream.

Session management is enhanced: the server returns an Mcp-Session-Id on initialization, and the client must include this header in subsequent requests. The session ID can be used to terminate a session or to associate multiple interactions.

These improvements allow stateless server deployment, better scalability, and optional SSE streams for long‑running tasks that need progress notifications.

2. OAuth 2.1 Authorization Framework

The specification adds an OAuth 2.1 based authorization flow for remote MCP services, providing a standardized security layer for HTTP‑based interactions. It does not affect the local stdio mode.

Roles defined in the flow:

Browser : used by the user to grant consent.

MCP client (e.g., a chatbot): initiates requests to the MCP server.

MCP server : acts both as the protected resource and as the OAuth authorization server.

Typical flow steps:

Client discovers the server’s metadata (optional .well‑known/oauth-authorization-server endpoint).

Dynamic client registration may be performed to obtain client_id and client_secret (optional).

Client prepares an authorization request with PKCE parameters ( code_verifier and code_challenge).

Browser is opened to the server’s authorization endpoint; the user consents.

Server validates the request and issues an authorization code.

Authorization code is redirected back to the client’s redirect_uri.

Client exchanges the code (and code_verifier) for an access token.

Client includes Authorization: Bearer {access_token} in subsequent MCP calls.

Example request for a JSON‑RPC call:

POST /mcp HTTP/1.1
Host: mcp.example.com
Accept: application/json, text/event-stream
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}

Example to open an SSE stream:

GET /mcp HTTP/1.1
Host: mcp.example.com
Accept: text/event-stream

Example to call a protected endpoint with a token:

POST /mcp
Authorization: Bearer {access_token}
Content-Type: application/json

{...}

3. Impact and Application

The new transport and authorization mechanisms are optional for backward compatibility. Legacy MCP clients that do not implement OAuth can still communicate with servers that do not enforce authentication. However, when a server requires OAuth, clients must upgrade to follow the flow.

In secure deployment scenarios, the Streamable HTTP mode provides stateless, scalable endpoints, while optional SSE streams preserve the ability to push progress updates. The added session ID enables precise control over multi‑request interactions and graceful termination.

The article notes that the next installment will cover the remaining two upgrades: JSON‑RPC batch processing and enhanced tool annotations.