Max Isbey
d99b1400c6
The twelve v1 @server.* decorator kinds are gone on v2. Their sites now become add_request_handler / add_notification_handler calls at the decorator's exact source position (registration there is when the v1 decorator ran, so execution order is preserved and the deprecated capabilities land on the warning-free path), wired through generated adapters that reproduce the v1 wrapper semantics: bare-list wrapping, call_tool's any-exception-to-isError contract with jsonschema input and output validation (tool lookup through the registered tools/list handler, v1's own cache mechanism, so cross-module list_tools works), read_resource content conversion, and the completion None-mapping. Handler bodies are never touched. Shapes the adapter cannot serve honestly -- a stacked decorator, an attribute receiver, a non-v1 signature, a non-literal decorator argument, a taken name -- are marked with the reason. The suite migrates a six-registration server and serves it to a v1-shaped ClientSession over the legacy protocol; the templates are pinned against the installed v2 (method strings register, params models exist, imports resolve, no 2026-era surface is emitted). Also on the client surface: inline timedelta session timeouts convert to float seconds and non-provable values are marked (the mismatch only fails on the first request); cursor= on session list_* methods wraps into params=PaginatedRequestParams(...); pydantic URL wrappers around resource URIs are dropped where the target provably takes v2's plain str and marked elsewhere; constructions of and pydantic method calls on the v1 RootModel wrappers that became plain union aliases are marked with the TypeAdapter fix; ._mcp_server and the type-keyed handler dicts are marked with their v2 homes. Adapters honor an explicit `uri: str` annotation and keep v1's AnyUrl otherwise, and keep the emitted code insensitive to user return annotations so a wrong annotation cannot manufacture type errors inside generated code. Batch harness: seven more pinned repositories (two seven-decorator servers, a multi-package lowlevel server, the method-local-server marker path, two client libraries including a positional timedelta timeout and the old streamablehttp spelling, and an exact ==1.6.0 pin). Markers now cover the full statement they precede rather than a fixed radius, Unknown-typed errors in files that carry markers classify as cascade of a marked break, and the work directory is a dot-directory so pytest never collects the cloned repositories' own suites. All eleven repositories audit at zero uncovered errors. An adversarial review round over the full change confirmed ten defects, all fixed with regression tests: adapter imports now inject at the top of the module (a mid-file import as the anchor left registration code running before its imports bound); the rewrite gates now also block a handler named like a template local, and any module-level non-import binding of a name the adapter references (both were silent runtime breaks past the gates); import injection dedup now reads the updated module's top-level import binds, so conditional or function-local imports no longer suppress a needed injection; list_* adapters pass a returned full result model through instead of double-wrapping (v1's runtime behavior); the blocked-progress marker names add_notification_handler (a request-handler registration would never fire); the timeout transform skips already-v2 shapes so re-runs stay no-ops; the emitted name scheme is defined once and shared between templates and gates; and the harness classifier no longer lets a marker cover a whole def/class body or write off arbitrary Unknown-typed errors (header-only spans; cascade restricted to propagation rules and never detonators).
MCP Python SDK
Python implementation of the Model Context Protocol (MCP)
Caution
This README documents v2 of the MCP Python SDK — a pre-release (alpha/beta) line under active development. Do not use v2 in production. Pre-releases are published to PyPI as
2.0.0aN/2.0.0bN, and each pre-release may contain breaking changes from the previous one. Pin an exact version and expect to update your code when you bump the pin.v1.x is the only stable release line and remains recommended for production. It lives on the
v1.xbranch and continues to receive critical bug fixes and security patches; see the v1.x README for its documentation.pipanduvdon't select a pre-release unless you explicitly request one, so existing installs are unaffected. If your package depends onmcp, add a<2upper bound to your version constraint (for examplemcp>=1.27,<2) before the stable release lands.v2 is a major rework of the SDK, both to support the 2026-07-28 MCP specification release and to fix long-standing architectural issues. See the migration guide for what's changed;
uvx mcp-codemod v1-to-v2 ./srcautomates the mechanical half of it and marks the rest with# mcp-codemod:comments. Stable v2 is targeted for 2026-07-27, alongside the spec release. Try the pre-releases and tell us what breaks — or discuss in #python-sdk-dev on the MCP Contributors Discord.
Documentation
The documentation lives at https://py.sdk.modelcontextprotocol.io/v2/.
It has the full tutorial, the API reference, and the migration guide.
What is MCP?
The Model Context Protocol lets you build servers that expose data and functionality to LLM applications in a secure, standardized way. Think of it like a web API, but designed for LLM interactions. With this SDK you can:
- Build MCP servers that expose tools, resources, and prompts to any MCP host
- Build MCP clients that connect to any MCP server
- Speak every standard transport: stdio, Streamable HTTP, and SSE
Requirements
Python 3.10+.
Installation
uv add "mcp[cli]==2.0.0b1" # or: pip install "mcp[cli]==2.0.0b1"
The pin matters while v2 is in pre-release: an unpinned install resolves to the latest stable v1.x, which this README does not describe. Check PyPI for the newest pre-release, and use uv run --with "mcp==2.0.0b1" for one-off commands.
A server in 15 lines
Create a server.py:
from mcp.server import MCPServer
mcp = MCPServer("Demo")
@mcp.tool()
def add(a: int, b: int) -> int:
"""Add two numbers."""
return a + b
@mcp.resource("greeting://{name}")
def greeting(name: str) -> str:
"""Greet someone by name."""
return f"Hello, {name}!"
Full example: docs_src/index/tutorial001.py
That's a complete MCP server: one tool, one templated resource. Open it in the MCP Inspector:
uv run mcp dev server.py
Call add with a=1, b=2 and you get 3 back.
Notice what you did not write: no JSON Schema (a: int, b: int is the schema), no request parsing, no validation code, no protocol handling. Two type-hinted Python functions and a docstring.
The tutorial takes it from here.
A client in 10 lines
The same package is a full MCP client. Client connects to a URL, a stdio subprocess, a custom transport, or (for tests) straight to a server object in memory with no transport at all:
import asyncio
from mcp import Client
from server import mcp
async def main() -> None:
async with Client(mcp) as client:
result = await client.call_tool("add", {"a": 1, "b": 2})
print(result.structured_content) # {'result': 3}
asyncio.run(main())
Swap mcp for "http://localhost:8000/mcp" and the exact same code talks to a remote server.
Contributing
We are passionate about supporting contributors of all levels of experience and would love to see you get involved in the project. See the contributing guide to get started.
License
This project is licensed under the MIT License. See the LICENSE file for details.