A pull request against the official Model Context Protocol Python SDK was merged at 14:54 UTC on 28 August, changing two defaults that govern how long MCP servers hold connections and how many they will accept.
The two defaults
Session idle timeout moves from unset to 1,800 seconds, so a session with no activity for thirty minutes is reclaimed. Maximum concurrent sessions moves from unlimited to 10,000; past that, a server answers with HTTP 503 and JSON-RPC error code -32603. Both are defensible defaults — unbounded session tables are a denial-of-service surface, and an unbounded idle timeout is a resource leak.
What the common framing gets wrong
The metadata says this is safe to take, and the body says it is not. The pull request carries its own "Breaking Changes" section, while the submission checklist leaves the breaking-change box unticked and ticks two boxes asserting the opposite. That mismatch is what propagates: release tooling, changelog generators and semantic-version decisions read the checklist, not the prose. A maintainer scanning the metadata concludes a minor bump is appropriate, and downstream operators upgrade without reading the section that tells them their long-lived sessions now expire.
Who this actually breaks
Any deployment that keeps MCP sessions open across long human-in-the-loop gaps — an agent waiting on a review, an assistant idle between a morning and an afternoon — will start seeing sessions vanish at the half-hour mark. The failure is silent from the client's perspective until the next call. Deployments above ten thousand concurrent sessions will start refusing connections with a code that most MCP clients do not distinguish from a server fault.
Where this stands
The change is merged to the main branch and not yet in a release, so nothing has shipped to anyone upgrading through a package manager today. That is precisely the window in which the checklist can still be corrected and the version bump chosen deliberately.