Will MCP Python SDK 2.2.0 break my running server?

MCP Python SDK 2.2.0 can break two patterns. A client that holds an idle Streamable HTTP session past the new timeout has to reinitialize, and any HTTP call that redirects to a different scheme, host or port now raises an MCPError instead of following it. Servers that were relying on unlimited concurrent sessions will also start returning 503 at the ceiling.

Do I have to move to 2.x to get this hardening?

No. The maintainers shipped 1.30.0 the same day as a maintenance release on the 1.x line, carrying the same origin-constrained redirects, idle-session expiry, session ceiling and OAuth issuer validation. 2.x is the current line and the 1.x documentation lives at py.sdk.modelcontextprotocol.io/v1, so 1.30.0 lets a project stay put and still pick up the changes.

Which MCP clients are affected by the idle-session timeout?

The idle-session rule in MCP Python SDK 2.2.0 only bites connections that go quiet on Streamable HTTP. The SDK's own Client holds a GET stream open, so it stays alive. Stateless servers have no session to expire, and connections on the newer spec revision sit outside the rule as well. Custom clients that poll rarely are the ones that need to reinitialize.

What happens when a server hits the session ceiling?

A server running MCP Python SDK 2.2.0 answers new requests with HTTP 503 once it holds the maximum number of concurrent sessions. The release also fixes two leaks that used to keep that count high: a client DELETE now frees its session immediately, and a refused opening request no longer leaves an orphaned session behind.

Model Context Protocol · 2026-09-07 · major

MCP Python SDK 2.2.0 — idle sessions now close after 30 minutes

MCP Python SDK 2.2.0 hardens Streamable HTTP: idle sessions close on their own, a server holds at most 10,000 at once, and HTTP redirects only follow within the same origin. The same changes shipped as 1.30.0 on the 1.x line.

GitHub repository card for modelcontextprotocol/python-sdk

The official Python SDK for MCP tightens session handling and OAuth checks, with the same fixes backported to the 1.x line.

Quick facts

Version	2.2.0
Released	September 7, 2026
Also shipped	1.30.0, a maintenance release on the 1.x line
Idle session timeout	30 minutes, set with session_idle_timeout=
Session ceiling	10,000 per server, then HTTP 503
License	MIT
Requires	Python 3.10+

What is it?

Three behaviour changes land in MCP Python SDK 2.2.0. Streamable HTTP sessions now expire on their own once they sit idle, and a server refuses new sessions past a ceiling instead of growing without limit. An HTTP client also stops following any redirect that leaves the endpoint's own scheme, host and port — those now fail with an MCPError rather than quietly going somewhere else.

How does it work?

Two new server settings, `session_idle_timeout=` and `max_sessions=`, expose the Streamable HTTP limits so a deployment can tune them. The auth path changed too: the SDK now checks the authorization server's issuer on the legacy discovery route as well and rejects a mismatch with an OAuthFlowError, and a new `AuthSettings.validate_token_resource` switch makes a server accept only tokens that were issued for it.

Why does it matter?

Long-running MCP deployments feel this first. A client parked on an idle Streamable HTTP session has to reinitialize once the window passes, and anything that leaned on a redirect to another host breaks. The maintainers shipped the same hardening the same day as 1.30.0 for people still on the 1.x line, so a project does not have to take the 2.x migration to get it. Two deprecation warnings also start firing for OAuth providers declared without `issuer=`.

Who is it for?

developers running MCP servers and clients in Python

Frequently asked questions

Will MCP Python SDK 2.2.0 break my running server?: MCP Python SDK 2.2.0 can break two patterns. A client that holds an idle Streamable HTTP session past the new timeout has to reinitialize, and any HTTP call that redirects to a different scheme, host or port now raises an MCPError instead of following it. Servers that were relying on unlimited concurrent sessions will also start returning 503 at the ceiling.
Do I have to move to 2.x to get this hardening?: No. The maintainers shipped 1.30.0 the same day as a maintenance release on the 1.x line, carrying the same origin-constrained redirects, idle-session expiry, session ceiling and OAuth issuer validation. 2.x is the current line and the 1.x documentation lives at py.sdk.modelcontextprotocol.io/v1, so 1.30.0 lets a project stay put and still pick up the changes.
Which MCP clients are affected by the idle-session timeout?: The idle-session rule in MCP Python SDK 2.2.0 only bites connections that go quiet on Streamable HTTP. The SDK's own Client holds a GET stream open, so it stays alive. Stateless servers have no session to expire, and connections on the newer spec revision sit outside the rule as well. Custom clients that poll rarely are the ones that need to reinitialize.
What happens when a server hits the session ceiling?: A server running MCP Python SDK 2.2.0 answers new requests with HTTP 503 once it holds the maximum number of concurrent sessions. The release also fixes two leaks that used to keep that count high: a client DELETE now frees its session immediately, and a refused opening request no longer leaves an orphaned session behind.

Try it

pip install -U mcp