LLMアプリケーションにツールを接続する仕組みとして、MCPという仕様が急速に広がっています。Anthropic発のこのプロトコルには複数言語の実装がありますが、Pythonの公式SDKは今年v2への大きな改修を経て、インターフェースとアーキテクチャの両面が書き直されました。このリポジトリを実際に触ってみると、「なぜこれだけ短いコードでサーバーが動くのか」という問いが自然に浮かびます。今回はそこを起点に、紹介と設計の読み解きを両方やってみます。
どんなライブラリか
MCP Python SDKは、Model Context Protocol（MCP）のサーバーとクライアントをPythonで実装するための公式ライブラリです。PyPIパッケージ名は mcp で、スター数は24,000を超えています。対応するトランスポートはstdio、Streamable HTTP、SSEの3種類で、LLMホストとのやり取りをプロトコルレベルで抽象化してくれます。
想定ユーザーは、Claude DesktopやCursor、その他のMCP対応ホストに向けてツールやリソースを公開したい開発者です。サーバーだけでなくクライアントも同じパッケージに含まれているため、サーバーを叩くスクリプトをPythonで書きたい場合にも使えます。インストールは pip install "mcp[cli]" の一行で済み、CLIが不要な場合は mcp だけでも動きます。Python 3.10以上が必要です。
設計でここが上手い
型ヒントをスキーマとして使う
READMEのサンプルを見ると、@mcp.tool() デコレータを付けた関数に a: int, b: int と書くだけで、JSON Schemaが自動生成されます。通常、WebAPIを作るときは型定義とバリデーションとドキュメントを別々に管理しなければなりませんが、このSDKではPythonの型アノテーションがその三役を同時に担います。開発者が書いたdocstringがツールの説明文になり、引数の型がバリデーションルールになる。これは「Pythonらしい書き方をすれば自動的にMCP準拠になる」という設計方針で、慣れた人ほど余計なことを書かずに済む作りになっています。
サーバーとクライアントが同一パッケージ内に共存する
「サーバーを作る用のライブラリ」と「サーバーを呼ぶ用のライブラリ」が分かれていると、バージョン管理が煩雑になります。このSDKはサーバーとクライアントを同じパッケージにまとめているため、「サーバーを立ててからクライアントで叩いてテストする」という開発サイクルを1つの依存関係で完結させられます。ローカル開発でサブプロセスとしてサーバーを起動するパターンも Client がネイティブに対応しており、本番はHTTPで叩くが開発中はstdioで繋ぐ、という切り替えも設定だけで済みます。
v1からの移行を丁寧に用意している
v2はメジャーバージョンアップのため破壊的変更が入っています。それに対して、v1.xブランチを存続させつつ <2 のバージョン制約で旧バージョンに留まる方法をREADMEで明示しています。既存プロジェクトを抱えている場合でも「いつ移行するか」を自分のタイミングで決められる余地が残されていて、急かされる感がないのは好感が持てます。移行ガイドも公式ドキュメントに独立したページとして用意されており、何が変わったのかを追いやすい構成です。
こういう人に向くかも
MCPサーバーをゼロから書いてみたい、あるいはClaude DesktopやCursorに自分のツールを繋いでみたいと考えているPythonエンジニアには、現時点で最も素直な選択肢です。特に、Pydanticや型アノテーションに慣れている人は違和感なく使い始めることができます。
一方で、すでにLangChainやLlamaIndexなどのフレームワークを使っているチームは、それぞれのMCP統合アダプタが用意されているケースもあるため、直接このSDKを使う必要があるかどうかを先に確認するのが良いかなと思います。また、非同期処理（asyncio）が前提になっているため、同期コードを主体に書いているコードベースへの組み込みには多少の注意が必要です。
設計の良し悪しをどこで見るか
機能の単一性
このSDKの役割は「MCPプロトコルのPython実装を提供すること」に絞られており、LLM呼び出しそのものや、チェーン構築のような高レベルな抽象は含まれていません。これは意図的な分離で、SDKがプロトコルの翻訳層に徹することで、上位ライブラリとの組み合わせの自由度を残しています。チームで使うときも「MCPの部分はこのSDKに任せる」という役割分担が明確にでき、責任境界がぼやけにくい構造です。
ドキュメントの深度
公式ドキュメントが https://py.sdk.modelcontextprotocol.io/ に独立したサイトとして用意されており、READMEとドキュメントサイトで内容が重複していません。READMEは「15行のサーバー」と「10行のクライアント」という最小例の提示にとどめ、詳細はドキュメントに委ねる構成になっています。この分割は理にかなっていて、READMEを読んだだけで動かせる一方、深い使い方を調べたい人もドキュメントで迷わず続きを読めます。APIリファレンスも含まれているので、型定義まで追いたいときも同じ場所で完結します。
トークン経済性
デコレータベースの書き方は、サーバーのコードをそのままプロンプトに貼って「このサーバーは何ができますか?」と聞く場面でも有効です。コードが短くなるほどコンテキストを消費しません。実際にチームで使うと、サーバーの仕様をコードで読み共有できるため、長大な仕様書を別途管理する手間が減ります。もちろん、それはコードが正しく動いている前提の話ですが、型ヒントとdocstringが仕様を兼ねる構造は、コードと仕様の乖離を物理的に起きにくくしています。
想定外の使われ方への備え
トランスポートを3種類サポートしているのは手厚い反面、HTTPとstdioで設定や挙動が異なる部分があります。特にクライアント側でURLを渡すとStreamable HTTP、プロセスを渡すとstdioになるというパターンマッチ的な挙動は、初見で動作を予測しにくいかもしれません。ドキュメントで各トランスポートのサンプルが揃っていれば問題は小さいですが、ここは実際に動かしながら確認するのが安全です。
自分が書くなら、どこを変えるか
いくつか気になる点として、エラーハンドリングの公開インターフェースがどこまで整備されているかは触ってみないと分からないところがあります。ツールが例外を投げたとき、クライアント側でどんな情報が返ってくるのかは、本番運用に持ち込む前に確認しておきたい部分です。
もう一点は、非同期が前提という設計についてです。asyncioを使った経験が少ないチームだと、サーバーとクライアントを両方書くとき、イベントループの扱いで詰まるケースがあります。同期的なラッパーが標準で用意されているといくらか敷居が下がるかもしれませんが、MCPプロトコルがそもそも非同期前提である以上、ここは「仕様の都合」の部分も大きく、SDKの設計だけで解決できる問題でもないかなとは思います。むしろ、入門ドキュメントの中でasyncioの基本を補足するページがあると、Pythonの型ヒントには慣れているがasyncioは初めてという層の受け皿になりそうです。
導入を検討するときのチェック観点
以下の点を自分のプロジェクトに照らし合わせてみると、導入後の齟齬が減るかもしれません。
- Python 3.10以上を使っているか（それ以下のバージョンでは動きません）
- asyncioを含むコードベースに組み込む準備があるか
- 接続先のMCPホスト（Claude Desktop等）が対応しているトランスポートを確認したか
- 既存フレームワーク（LangChain等）にMCP統合アダプタがないかを先に調べたか
- v1系からの移行を検討している場合、移行ガイドで破壊的変更を確認したか
- サーバーをHTTPで公開する場合、認証・認可をどこで担保するかを決めているか
- チームがPythonの型アノテーションとdocstringを書く文化があるか（そこが仕様になります）
手を動かす出発点
このSDKは、MCPという仕様をPythonらしく書けるように翻訳した実装です。デコレータと型ヒントを使いこなしている人であれば、最初のサーバーを動かすまでの壁はかなり低いと感じるはずです。一方で、v2で大きくリファクタリングされたこともあり、ネット上に残っているv1のサンプルをそのまま動かそうとすると動かないケースがあります。まずは公式ドキュメントの「Get started」ページを起点にして、最小のサーバーとクライアントをローカルで動かすところから入ると、混乱が少ないかなと思います。MCPエコシステムそのものが活発に動いているタイミングなので、仕様の変化にどうついていくかという視点も、長く付き合うなら持っておきたいところです。
