MCPサーバートランスポート
MCPはBob ShellとMCPサーバー間の通信のためのトランスポートメカニズムをサポートしています。
概要
MCPは異なるデプロイシナリオに適した3つのトランスポートオプションを提供しています:
- STDIOトランスポート(ローカルサーバー)
- Streamable HTTPトランスポート(リモートサーバーの現代的な標準)
- SSEトランスポート(レガシーのリモートオプション)
各トランスポートには異なる特性、利点、およびユースケースがあります。
STDIOトランスポート
STDIOトランスポートはマシン上でローカルに実行され、標準入出力ストリームを通じて通信します。
STDIOトランスポートの仕組み
- BobはMCPサーバーを子プロセスとして起動します
- 通信はプロセスストリームを通じて行われます:BobはサーバーのSTDINに書き込み、サーバーはSTDOUTに応答します
- 各メッセージは改行文字で区切られます
- メッセージはJSON-RPC 2.0形式でフォーマットされます
クライアント サーバー
| |
|---- JSONメッセージ ----->| (STDINを経由)
| | (リクエストを処理)
|<---- JSONメッセージ -----| (STDOUTを経由)
| |STDIOの特性
- ローカリティ:Bobと同じマシンで実行
- パフォーマンス:非常に低レイテンシとオーバーヘッド(ネットワークスタック不要)
- シンプルさ:ネットワーク設定なしの直接プロセス通信
- 関係性:クライアントとサーバーの一対一の関係
- セキュリティ:ネットワーク露出なしで本質的に安全
STDIOを使う場面
STDIOトランスポートは以下に最適です:
- 同じマシンで実行するローカル統合とツール
- セキュリティに敏感な操作
- 低レイテンシ要件
- シングルクライアントシナリオ(サーバーごとに1つのBobインスタンス)
- コマンドラインツールとスクリプト
STDIO実装例
const server = new Server({name: 'local-server', version: '1.0.0'});
// ツールを登録...
// STDIOトランスポートを使用
const transport = new StdioServerTransport(server);
transport.listen();Streamable HTTPトランスポート
Streamable HTTPトランスポートはリモートMCPサーバー通信の現代的な標準であり、古いHTTP+SSEトランスポートを置き換えます。HTTP/HTTPS上で動作し、より柔軟なサーバー実装を可能にします。
Streamable HTTPトランスポートの仕組み
- サーバーはPOSTとGETメソッドの両方をサポートする単一のHTTPエンドポイント(MCPエンドポイント)を提供します
- BobはHTTP POSTを使用してこのMCPエンドポイントにリクエストを送信します
- サーバーはリクエストを処理して応答を返します
- オプションとして、サーバーは同じ接続でServer-Sent Events (SSE) を使用して複数のメッセージや通知をBobにストリーミングできます
これにより、基本的なリクエスト-レスポンスのインタラクションと、より高度なストリーミングおよびサーバー起動型の通信が可能になります。
クライアント サーバー
| |
|---- HTTP POST /mcp_endpoint ---->| (クライアントリクエスト)
| | (リクエストを処理)
|<--- HTTP応答 / SSEストリーム ----| (サーバー応答 / ストリーム)
| |Streamable HTTPの特性
- 現代的な標準:新しいリモートMCPサーバー実装に推奨される方法
- リモートアクセス:Bobとは異なるマシンでホスト可能
- スケーラビリティ:複数のクライアント接続を同時に処理可能
- プロトコル:標準のHTTP/HTTPS上で動作
- 柔軟性:シンプルなリクエスト-レスポンスと高度なストリーミングをサポート
- 単一エンドポイント:すべてのMCP通信に単一のURLパスを使用
- 認証:標準のHTTP認証メカニズムを使用可能
- 後方互換性:サーバーは古いHTTP+SSEクライアントとの互換性を維持可能
Streamable HTTPを使う場面
Streamable HTTPトランスポートは以下に最適です:
- すべての新しいリモートMCPサーバー開発
- 堅牢でスケーラブルな柔軟な通信が必要なサーバー
- ストリーミングデータやサーバー送信通知が含まれる可能性がある統合
- 公共サービスや集中型ツール
- レガシーSSEトランスポートの実装を置き換える場合
Streamable HTTP実装例
~/.bob/settings/mcp.json(グローバル)または.bob/mcp.json(プロジェクト)での設定:
{
"mcpServers": {
"StreamableHTTPMCPName": {
"httpURL": "http://localhost:8080/mcp"
}
}
}サーバー側の実装については、StreamableHTTPClientTransportのMCP SDKドキュメントを参照してください。
HTTP+SSEとの後方互換性
BobのMCPクライアントはHTTP+SSEトランスポートへのフォールバックを行いません。以下のガイダンスは、Streamable HTTPをまだサポートしていない古いクライアントからも引き続きアクセスできるようにしたいサーバー作成者向けです。
古いクライアントをサポートする必要があるサーバーは、Streamable HTTPトランスポート用に定義された新しいMCPエンドポイントとともに、古いトランスポートのSSE(/events)およびPOST(/message)エンドポイントの両方を引き続きホストする必要があります。
SSEトランスポート(削除済み)
BobのMCPクライアントは、スタンドアロンのHTTP+SSEトランスポート(MCP仕様 2024-11-05)をサポートしなくなりました。HTTP+SSEトランスポートのみを使用するサーバーはBobに接続できません。
Streamable HTTP接続内のレスポンス・チャネルとしてのSSEは引き続きサポートされています。BobはStreamable HTTPサーバーからSSEストリームを受信できます。スタンドアロンのHTTP+SSEトランスポート(別個の/eventsおよび/messageエンドポイントを持つもの)のみが削除されました。
SSEトランスポートからの移行
HTTP+SSEトランスポートを使用する既存のサーバーがある場合は、Streamable HTTPトランスポートまたはSTDIOトランスポートに移行してください:
- Streamable HTTP: HTTP POSTリクエストを受け付ける単一のMCPエンドポイントを公開します。これはリモートサーバー推奨の方法です。Streamable HTTPトランスポートを参照してください。
- STDIO: サーバーがBobと同じマシン上でローカルに実行されている場合は、STDIOサーバーに変換します。STDIOトランスポートを参照してください。
デプロイの考慮事項
STDIOとStreamable HTTPトランスポートの選択は、MCPサーバーのデプロイと管理方法に直接影響します。
STDIO:ローカルデプロイ
STDIOサーバーはBobと同じマシン上でローカルに実行されます:
- インストール:各ユーザーのマシンにサーバー実行ファイルをインストールする必要があります
- 配布:異なるオペレーティングシステム用のインストールパッケージを提供する必要があります
- 更新:各インスタンスを個別に更新する必要があります
- リソース:ローカルマシンのCPU、メモリ、ディスクを使用します
- アクセス制御:ローカルマシンのファイルシステムパーミッションに依存します
- 統合:ローカルシステムリソース(ファイル、プロセス)との統合が簡単
- 実行:Bobと共に起動・停止します(子プロセスのライフサイクル)
- 依存関係:すべての依存関係をユーザーのマシンにインストールする必要があります
ユースケース例:
STDIOを使用するローカルファイル検索ツールは:
- あなたのマシン上で実行される
- ローカルファイルシステムへの直接アクセスがある
- Bobが必要なときに起動する
- ネットワーク設定が不要
- Bobと並んでまたはパッケージマネージャー経由でインストールする必要がある
リモート:ホステッドデプロイ
リモートサーバー(Streamable HTTP)はリモートサーバーにデプロイしてネットワーク越しにアクセスできます:
- インストール:サーバーに一度インストールされ、多くのユーザーがアクセス可能
- 配布:単一のデプロイが複数のクライアントにサービス提供
- 更新:集中型の更新がすべてのユーザーに即座に反映
- リソース:ローカルマシンではなくサーバーリソースを使用
- アクセス制御:認証および認可システムを通じて管理
- 統合:ユーザー固有のリソースとのより複雑な統合
- 実行:独立したサービスとして実行(多くの場合継続的に)
- 依存関係:ユーザーのマシンではなくサーバーで管理
ユースケース例:
リモートトランスポートを使用するデータベースクエリツールは:
- 中央サーバー上で実行される
- サーバー側の認証情報でデータベースに接続する
- 複数のユーザーが継続的に利用可能
- 適切なネットワークセキュリティ設定が必要
- コンテナやクラウド技術を使用してデプロイされる
ハイブリッドアプローチ
一部のシナリオではハイブリッドアプローチが有益です:
- ネットワークアクセスを持つSTDIO:リモートサービスへのプロキシとして機能するローカルSTDIOサーバー
- ローカルコマンドを持つリモート:コールバックを通じてクライアントマシン上の操作をトリガーできるリモートサーバー
- ゲートウェイパターン:特殊機能のためにリモートサーバーに接続するローカル操作用のSTDIOサーバー
トランスポートの比較
| 考慮事項 | STDIO | Streamable HTTP |
|---|---|---|
| 場所 | ローカルマシンのみ | ローカルまたはリモート |
| クライアント | シングルクライアント | 複数クライアント |
| パフォーマンス | 低レイテンシ | 高レイテンシ(ネットワークオーバーヘッド) |
| セットアップの複雑さ | シンプル | より複雑(HTTPサーバーが必要) |
| セキュリティ | 本質的に安全 | 明示的なセキュリティ対策が必要 |
| ネットワークアクセス | 不要 | 必要 |
| スケーラビリティ | ローカルマシンに限定 | ネットワーク越しに分散可能 |
| デプロイ | ユーザーごとのインストール | 集中型インストール |
| 更新 | 分散型更新 | 集中型更新 |
| リソース使用 | クライアントリソースを使用 | サーバーリソースを使用 |
| 依存関係 | クライアント側の依存関係 | サーバー側の依存関係 |
Bob ShellでのトランスポートC設定
Bob Shellでのトランスポートの設定に関する詳細情報(設定例を含む)については、Bob ShellのMCPを参照してください。