MCP（Model Context Protocol）が登場し、MCPサーバをまとめて配布できる MCP Bundle（MCPB）/ Desctop Extention(DXT) という仕組みがAnthropicから提唱されました。これを使うと、

Node.js で MCP サーバを書いて DXT にパック
ZIP で配れば、クライアントがそのまま実行

という軽快さを実現でき、かなり魅力的です。

しかし Python で MCPB/DXT を利用しようとすると、途端に「扱いづらさ」が出てきます。

ランタイムと ABI の整合性問題
wheel（ネイティブ拡張）の ABI タグ
server/lib / server/venv の前提と限界
ホスト側（MCPクライアント）が何を保証すべきか不明瞭

など、Python 特有の難しさを DXT が十分吸収できていないためです。

本記事では、「なぜ Python サーバだけがこんなに扱いづらいのか？」を技術的に整理します。

1. MCPB/DXT が Python に提供している仕組み（現状）

MCPB/DXT では Python で実装されたMCPサーバ向けに以下のようなガイダンスを出しています：

依存は以下のどちらかでバンドル
- server/lib/（依存モジュールをまとめて置く）
- server/venv/（仮想環境そのものを入れる）

また、manifest.jsonの内容として以下を表現できます：

compatibility.runtimes.python で対応する Python のバージョン範囲を指定できる（例: ">=3.10,<3.13"）

一見すると十分そうですが、　重要な抜け落ち があります。

2. Python製 MCPサーバの配布の難しさ：ABI タグ問題

たとえば、今配りたいMCPサーバが、Python のネイティブ拡張に依存するライブラリ（numpy、pillow、lxml など）を使っているとします。これらの実体は、wheel ファイルとして配布されていますが、wheel には次のようなタグが付きます。

cp310-win_amd64
cp312-manylinux_x86_64
cp311-macosx_11_0_arm64

つまり、

Python バージョン（例: cp312）
OS（win / manylinux / macosx）
CPU（x86_64 / arm64）
Python ABI の互換性（ABI breakpoints）

が組み合わさった環境 “だけ” で実行できる、ということです。

ネイティブ依存を含むパッケージはこの ABI に強く縛られるため、

Python LC の実行環境が少しでもズレれば wheel は読み込めない

という性質があります。

3. spec で「できていること」と「できていないこと」

✔ できていること

→ Python バージョン互換性の表明

compatibility.runtimes.python: ">=3.10,<3.13"
これは MCPB からホストへ：

「この Python サーバは Python 3.10〜3.12 で動いて欲しい」

と伝えるための仕組みとして機能しています。

✘ できていないこと

→ ABI タグ（実行可能 wheel のプロファイル）を表現できない

compatibility.runtimes.python はあくまで「バージョン範囲」です。

しかし、本当に必要なのは：

wheel の ABI タグ（例: cp312-win_amd64）
ホストランタイムの ABI タグ
それらが一致しているかどうか

というレベルの整合性です。

現状はここが “推測” に委ねられています。

MCPB作者
→ server/lib にどの ABI の wheel を入れるべきか曖昧
ホスト側
→ 自分の Python ランタイムが 本当にその wheel と一致するのか判断できない

という構造的なギャップが残っています。

4. `server/lib` と `server/venv` の限界

■ `server/lib` の前提は「ABI の一致が当然」

server/lib に依存を詰め込む方式は一見シンプルで「できそう」ですが、

「同梱した wheel の ABI は、ホスト側のランタイムと一致しているはず」

という暗黙の前提があるだけで、specとして保証されているわけではありません。

■ `server/venv` はもっと危険

仮想環境丸ごと同梱する案もありますが、実際には：

venv 内にはベース Python のパスが埋め込まれることがある
OS や Python バージョンと密結合
再配置すると壊れるケースも多い

つまり、「動くこともあるけど本質的には壊れやすい」 のが現実です。

5. Binaryタイプは Python よりはマシ、だが万能ではない

Pythonタイプは、Binary タイプと比較すると、

OS差分は platform_overrides で宣言できる
ホストは「バイナリをそのまま実行するだけ」

という意味で、Pythonより扱いやすいのは確かです。

しかし：

OS × CPU ごとにビルドが必要
GPU/ネイティブ依存を含めばさらにマトリクスが増える
macOS コード署名・Windows SmartScreen など別の難しさもある

つまり、Binary は Python より“マシ”なだけで、本質的な問題は別レイヤーに残る のが重要な点です。結局のところ、一応使えそうなのはNode.js上で動くMCPサーバだけになります。

6. どこに設計上のギャップがあるのか？

まとめると、以下の3点です。

ギャップ1：

Python の「実行環境プロファイル」が粒度不足

現在は「バージョン範囲」しか表現できない。
本当に必要なのは ABI タグレベルのプロファイル。

ギャップ2：

ホストと MCPB 作者の責務の境界が曖昧

Binary → 責務を作者側に閉じ込められる
Python → ランタイム整合性が両者に中途半端に分散する

ギャップ3：

「薄い Python DXT」と「太い Python DXT」が同じ枠に押し込まれている

純 Python の軽量スクリプト（依存少なめ）
ネイティブ依存が多い重厚な Python サーバ

この両者に必要な仕組みは本来違うのに、spec 上は分けられていません。

7. 結論：現状の Python DXT/MCPB は「構造的に扱いづらい」

以上から、現時点の結論は次の通りです。

MCPB/DXT の Python サポートは
ランタイム・ABI 整合性まで考えると“最低限”の仕様に留まっている
server/lib / server/venv は
軽量なケースでは動くが、ネイティブ依存が増えるほど脆い
Binary タイプは Python より扱いやすいが、
OS・CPU差分という本質的なネイティブ問題は依然残る

そのため現在の実務的な落としどころは、

本格的な Python MCP サーバは Binary 形式で配布する

純 Python スクリプトに限定するなら type: "python" を使う

という方針が無難です。

おわりに

MCPB/DXT 自体は面白いと思いますが、Python の扱いに関しては、現状 spec と実用性の間にまだギャップがあります。

ABI タグを含む「実行環境プロファイル」の導入
ランタイム責務の明確化
軽量／重量 Python DXT の区別

などが今後検討されると、Python でも少しはマシに DXT/MCPB を扱えるようになるはずです。

少なくとも、現時点でPython を本番環境向けに DXT/MCPB 化したい方は、Binary ベース（PyInstaller など）への移行を検討する価値があります。Node.jsベースで作り変えるほうが、さらにマシです。