MCPプロトコルがメジャーアップデート：完全なステートレス化でHTTP通信を簡素化

コア・ポイント エムシーピー ストリーミングHTTP」トランスポート・スキームを導入することで、このプロトコルは完全なステートレス性を達成し、通信を簡素化することで、将来の幅広いアプリケーションへの基礎を築いた。

メッセージ・チャネル・プロトコル(MCP)の重要な技術的改良案が承認され、この新しいプロトコルのより広い未来が示された。このアップデートの核心は、MCPのデータ転送方法における革命で、完全にステートレス化し、通常のHTTPプロトコルとの通信を簡素化する。

背景：HTTP+SSEの限界

以前は、MCPプロトコルはHTTPとSSE（Server Sent Events）を使ってデータを転送していた。この方法にはいくつかの制限があった：

• 切断と再接続はサポートされていません
• サーバーは安定性を確保するために長い接続を維持する必要がある。
• サーバーメッセージはSSE経由でのみ送信可能

革新的なソリューション：HTTPストリーミング

これらの問題に対処するため、コミュニティは "Streaming HTTP "トランスポートスキームを提案した。このスキームには以下の重要な調整が含まれている：

• sseインターフェイスをなくす：すべてのクライアントからサーバーへのメッセージは、一律に/message（または同様の）インターフェイスを通じて送信される。
• SSEへのリクエストのエスカレーション：サーバーは、リアルタイムのプッシュ通知やデータのために、クライアントのリクエストをSSE接続にエスカレーションすることができます。
• セッションID管理: クライアントはHTTPリクエストヘッダでセッションIDを提供する。
• SSE ストリームの開始：クライアントは、/message インターフェースに空の GET 要求を送信して、SSE ストリームを確立できる。

これらの改善により、MCPサーバーは完全にステートレス化され、常時接続の必要性がなくなり、サーバーの複雑さとリソース消費を大幅に削減することができます。同時に、純粋なHTTPプロトコルを使用することで、MCPの互換性が向上し、既存のネットワークインフラやミドルウェアへの適合性が向上しました。

地域社会の前向きな反応

この強化案は広く歓迎され、MCPコミュニティから肯定的なフィードバックを受けた。 アンソロピック これにはチームをはじめ、多くの組織や個人が貢献している。

無国籍がもたらす複数のメリット

ステートレス化は、今回のMCPプロトコルのアップデートの目玉であり、MCPに複数の利点をもたらす：

• 導入とメンテナンスの簡素化：セッションデータの永続化や同期を行う必要がないため、サーバーの導入や拡張が容易になります。
• システムの安定性向上：単一サーバーの故障はシステム全体の運用に影響を及ぼさないため、高可用性を実現しやすい。
• リソース消費の削減：長い接続とセッションの状態を維持する必要がなくなり、サーバーのリソース使用量とコストを削減できます。

アプリケーション・シナリオの展望

ステートレスMCPの実装は、多くのアプリケーションシナリオに新たな可能性を開く：

• ステートレス・ツール・サーバー：完全にステートレスなMCPサーバーを構築し、状態管理を行わずに言語モデリング・ツールの機能のみを提供することで、ツールの呼び出しプロセスを簡素化できます。
• ストリーミング・レスポンスをサポートするステートレス・サーバー：ステートレス・サーバーでも、SSEを活用して、ツールの実行中に進捗情報をリアルタイムでプッシュするなど、ストリーミング・レスポンスを提供することができる。

なぜストリーミングHTTP over WebSocketなのか？

WebSocketもトランスポート・スキームの選択において検討されたが、最終的にコミュニティは以下の点を考慮して「ストリーミングHTTP」を選択した：

• RPCシナリオにおけるオーバーヘッド：単純なRPC（リモート・プロシージャ・コール）シナリオでは、WebSocketの使用を強制することは、不必要な運用とネットワークの負担をもたらします。
• ブラウザの互換性：WebSocketは、ブラウザ環境におけるHTTPリクエスト・ヘッダの設定やサードパーティ・ライブラリの実装において、SSEほど柔軟ではない。
• プロトコルのアップグレードの複雑さ：WebSocketはGETリクエストのアップグレードしかサポートしていません。
• 合理化されたプロトコル仕様：MCPのプロトコル仕様は、互換性の問題を避けるため、公式なトランスポート・プロトコルの種類を制限する傾向にある。

安全性の探求

ステートレスには多くの利点がある一方で、セキュリティ、特にセッションIDの管理と認証に関する議論も提起される。

一部の開発者は、サーバーがセッションを管理するためにMcp-Session-Idリクエス トヘッダーを使う場合、異なる認可環境でセッションIDが悪用されるのを防ぐた めに、認可環境にセッションIDをバインドすべきである、と指摘した。これは、セッションIDをグローバルに共通にするのではなく、 特定のユーザーまたはクライアントのセッションに関連付けるべきである ことを意味する。

ミニマリスト・サーバーを求める開発者にとっては、複雑な認証メカニズムは 適用できないかもしれない。ステートフル・モードでは、HTTPリクエストそのものがセッションの境界と考えることができる。しかし、ステートレスモデルでは、HTTPのみのクッキーなしでセッションを安全に管理する方法についての懸念が残っています。

クライアント・セッションを管理するためにHTTP専用のクッキーを導入し、各クライアント・セッションに一意のIDを割り当て、その下で複数のMCPセッションIDを管理することで、階層的なセッション管理を実現し、セキュリティと柔軟性のバランスをとることを提案する開発者もいます。

総括と展望

MCPプロトコルのステートレスへの進化は、実用性と使いやすさに向けた重要な一歩です。Streaming HTTP」方式の採用は、MCP導入の敷居を下げ、より多くの開発者やアプリケーションシナリオを惹きつけることが期待されます。セキュリティについてはまだ議論の余地がありますが、コミュニティが改善を続けることで、MCPプロトコルの将来が楽しみなものになると信じています。

関連提案