MCP SDK for Python 1

Apply the Python 3 baseline first. These rules cover the mcp package on its 1.x maintenance line: FastMCP and low-level servers, the stdio, SSE, and Streamable HTTP transports, OAuth resource-server authentication, tools, resources, elicitation, and client-side process spawning.

Version scope and protocol negotiation

• Constrain mcp to the 1.x maintenance line with an upper bound such as <2 and let the lock file record the exact release, so a resolve never moves to the 2.x line, which is a different API surface and a different protocol era. The SDK ships 1.x security fixes in new 1.x releases, sometimes only in a new minor rather than a patch to the current one, so move to the newest 1.x release when one ships and re-check these rules against it.
• Run 1.x on a security-supported CPython minor verified with the deployed SDK and integrations. requires-python >=3.10 and the 3.10 classifier describe package compatibility, not interpreter support: CPython 3.10 is end of life. 1.30.0 advertises and runs CI for 3.10 through 3.14, so use 3.11 through 3.14 within that matrix. CPython 3.15 is maintained upstream but outside it; verify that interpreter and the resolved integrations separately before deploying on it. Keep the higher Pydantic, Starlette and Windows pywin32 requirements 1.30.0 declares for Python 3.14.
• Treat 2025-11-25 as the newest revision this line negotiates and do not write handlers that depend on fields or lifecycle behavior introduced after it.
• A non-initialize Streamable HTTP request with no MCP-Protocol-Version header is treated as