mcp 2.1.0

Version 2 of the official MCP Python SDK is a major architectural rework, not an incremental release. It targets the 2026-07-28 MCP specification while remaining backward-compatible with every earlier revision, and it explicitly acknowledges that v1 carried long-standing structural problems that this release fixes rather than papers over.

The design philosophy is worth examining directly. A working server requires 15 lines of Python. A working client requires 10. Neither example involves writing JSON Schema by hand, parsing raw requests, or touching protocol machinery. Python type hints on function parameters are the schema — a: int, b: int gets translated automatically. That's a meaningful ergonomic commitment, not a demo trick; it means the SDK is doing real inference work at decoration time rather than pushing that burden onto the caller.

The transport story has also matured. Three transports are supported natively: stdio for local subprocess use, Streamable HTTP for deployed services, and SSE. The client-side Client class dispatches on what it receives — pass a URL and it assumes Streamable HTTP; pass nothing and it can launch a local server as a subprocess. That kind of transport polymorphism matters when you're building agents that need to talk to both local tools and remote services without maintaining separate client code paths.

The versioning situation deserves honest attention. A plain pip install mcp now delivers 2.x, which breaks any code written against v1. The SDK maintainers have kept v1.x alive on a separate branch with security patches and critical bug fixes, and they're explicit about the pin you need — mcp>=1.28,<2 — if you're not ready to migrate. That's responsible, but it also means anyone who hasn't pinned carefully may have already broken their environment without noticing.

The CLI extras (mcp dev, mcp run, mcp install) are optional, installed via the cli extra. The mcp dev command opens a server directly in the MCP Inspector, which is a genuinely useful tight loop for iterating on tool definitions without standing up a full host application.

What the README doesn't cover is anything about authentication, authorization, or how the protocol handles capability negotiation between client and server — those details live in the specification and the full docs, not here. For someone evaluating whether to build on this SDK, the surface area shown is compelling, but the production concerns are deliberately out of frame.