MCP Python SDK v2安定版──FastMCPがMCPServerに、サーバーはクライアントを呼べなくなった代わりに何が変わったか

Model Context Protocol（MCP）のPython SDKがv2.0.0として安定版になった。2026年7月28日公開のリリースノートを確認すると、単なるマイナーアップデートではなく、プロトコルの世代交代とAPIの再設計を同時に含む大きな節目のリリースだと分かる。

新旧2つのプロトコル世代を、同じサーバーが両方喋る

リリースノートはこう説明している。

v2 speaks the 2026-07-28 revision (stateless requests with no handshake, server/discover, subscriptions/listen, multi-round-trip requests) and still serves every 2025-era client from the same MCPServer, over Streamable HTTP and stdio, with nothing to configure. Client(target) negotiates the version automatically.

（v2は2026-07-28版のプロトコル——ハンドシェイクなしのステートレスなリクエスト、server/discover、subscriptions/listen、複数往復するリクエスト——を話しつつ、2025年世代のクライアントも同じMCPServerから、Streamable HTTPとstdioの両方で、何も設定せずにそのまま提供し続ける。Client(target)はバージョンを自動的にネゴシエートする）

つまり、サーバー実装者は新旧どちらのプロトコル世代のクライアントが接続してくるか気にせず、同じサーバーコードを動かしておけばいい設計になっている。

FastMCPがMCPServerに、Clientが新設された

v1で馴染み深かったFastMCPという名前は、v2ではMCPServerに変わった。

The decorator API is unchanged; the low-level Server is rebuilt around a shared dispatcher engine, and one Client object replaces v1's transport-plus-ClientSession-plus-initialize() layering. It connects to a URL, a stdio subprocess, a custom transport, or straight to a server object in memory for tests.

（デコレータAPI自体は変わらない。低レベルのServerは共有ディスパッチャエンジンを中心に作り直され、1つのClientオブジェクトが、v1の「トランスポート＋ClientSession＋initialize()」という多層構造を置き換える。URL、stdioサブプロセス、カスタムトランスポート、あるいはテスト用にメモリ上のサーバーオブジェクトへ、そのまま接続できる）

ツールを定義するデコレータの書き方自体は変わらないため、既存のツール実装コードはそのまま移行できそうだが、クライアント接続まわりのコードは書き直しが必要になる、という切り分けだ。

サーバーがクライアントを呼べなくなった代わりの設計

新プロトコル（2026-07-28版）の大きな制約変更が明記されている。

At 2026-07-28 the server can no longer call the client, so tools return the question instead. A Resolve(fn) parameter is filled by your function invisibly to the model and can put a question to the user; one tool body serves both eras.

（2026-07-28版では、サーバーはもはやクライアントを呼び出せない。そのためツールは代わりに「質問」を返す。Resolve(fn)パラメータは、モデルには見えない形で自分の関数によって埋められ、ユーザーへの質問を投げることができる。1つのツール本体で新旧両方の世代に対応できる）

サーバーからクライアントへ直接コールバックする仕組みが無くなった代わりに、ツールの戻り値として「質問」を返し、Resolve(fn)という関数がその後始末をする形に置き換わった、と読み取れる。1つのツール実装コードで新旧両方のプロトコル世代に対応できる、という点は開発者にとって実務上の利点になりそうだ。

「betaから安定版までの間」に確定した破壊的変更

リリースノートの「Since the betas」欄と、公式マイグレーションガイドを突き合わせると、記事本文で紹介した変更以外にも、実務でつまずきやすそうな変更が列挙されている。

マイグレーションガイド自体は「Changes almost every project hits（ほぼ全プロジェクトが直面する変更）」という節を筆頭に、型・ワイヤーフォーマット・MCPServer・低レベルServer・クライアント・認可まわりを個別に解説する、非常に長大な構成になっている。

その他の変更点

拡張APIによるプロトコル拡張の合成（MCP Appsが組み込み済み）、OpenTelemetryトレーシングが標準で有効、プロトコルの型がすべて独立したパッケージmcp-types（mcp_typesとしてインポート）に切り出されmcp本体とロックステップで公開される、といった変更も挙げられている。stdioサーバーはハンドラのサブプロセスや意図しない標準出力への書き込みが通信経路に混ざらないよう強化され、標準出力はサービング中に標準エラーへ転送されるようになった。OAuth周りではRFC 9207のissuer検証、SEP-990のidentity-assertionフロー、client-credentials拡張が追加された。

v1は今後セキュリティ修正のみ

移行できない場合の選択肢も明記されている。

v1.x is in maintenance mode and will only receive security fixes from now on ... If your project is not ready to migrate, keep a <2 upper bound on your requirement (for example mcp>=1.28,<2).

（v1.xは保守モードに入り、今後はセキュリティ修正のみを受け取る。移行の準備ができていないプロジェクトは、要件に<2という上限を維持すること（例：mcp>=1.28,<2））

まだ実装されていない機能もある

リリースノートは「Known gaps」として、タスク拡張（SEP-2663）が今回のリリースには含まれないこと、クライアント側のDPoPプルーフバインディング（SEP-1932）とワークロードアイデンティティのjwt-bearerグラントが未実装であることを明記している。いずれも追加的な機能であり、2.x系列の今後のリリースで追加されうるとされている。

Resolve(fn)を使った質問フローを実際に組んだわけではない

本記事はMCP Python SDK v2.0.0のリリースノート・公式マイグレーションガイド・What's newページ・リリース候補（rc1）から正式版までの差分（.diff）をそれぞれ実際に開いて確認した内容にもとづく。rc1からv2.0.0への差分をファイル単位で見ると、244件の変更のうち大半はドキュメント（docs_src/が45件、docs/が31件）とサンプル（examples/が94件）で、src/配下の変更は33件にとどまっており、そのうちmcp-typesパッケージ内のv2025_11_25ディレクトリが_v2025_11_25にリネームされている変更を実際の差分で確認できた——これはリリースノートが「per-version wire packages are private」と説明している変更の実体だ。つまりリリース候補から正式版までの間は大きな設計変更ではなく、仕上げの調整が中心だったとこの記事では読み取れる。

この記事を書いている自分の手元で、既存のv1ベースのMCPサーバー実装を実際にv2へ移行し、Resolve(fn)を使った質問フローや、2025年世代・2026-07-28世代のクライアント双方からの接続を動作確認する検証は行っていない。マイグレーションガイドは非常に長大で、本記事で紹介した破壊的変更は代表的なものにとどまり、ガイド全体を網羅してはいない。

関連記事: MCP（Model Context Protocol）とは / MCP Inspectorのv2が標準に / MCPサーバーが接続できない時の対処法

感想・指摘はコメント欄へ。