11月3日、Postmanが「Manage MCP context with Postman Fabric Gateway」と題した記事を公開した。この記事では、Postman Fabric Gatewayを使って複数のMCPサーバーを単一エンドポイントに束ね、AIエージェントのツール探索を効率化する方法について詳しく紹介されている。
MCPサーバーが増えると何が問題になるか
Model Context Protocol（MCP）は、AIエージェントが外部ツールと連携するための標準プロトコルだ。2024年末にAnthropicが公開して以来、各社が対応サーバーを続々と提供しており、実運用では複数のMCPサーバーを組み合わせるケースが増えている。
問題はスケールだ。ツール定義（スキーマ）を起動時に全件ロードすると、無関係なスキーマでトークンを消費し、指示文や会話履歴、タスクデータのためのコンテキスト空間が圧迫される。記事が例として挙げるシナリオでは、銀行系とサポート系の2つのMCPサーバーを合わせると103個のツール定義が存在する。これをまとめてモデルに渡すのは明らかに非効率だ。
Postman Fabric Gatewayはこの問題に対して「複数サーバーの統合」と「段階的なツール探索（Progressive Tool Discovery）」という2つのアプローチで応える。
最も面白いポイント：エージェントへの公開インターフェースを3つに絞る仕組み
Tool Searchプラグインが変えるエージェントへの見せ方
Fabric Gatewayの核心はTool Searchプラグインだ。これをルートに適用すると、エージェントから見えるインターフェースが以下の3つだけに変わる：
| 機能 | 役割 |
|---|---|
| Search tools | 自然言語クエリでカタログを意味検索する |
| Get tool | 指定ツールの入力スキーマを取得する |
| Execute tool | 取得したスキーマに基づきツールを実行する |
元の103個のツール定義が削除されたわけではなく、Gatewayがクライアントへの見せ方を変えているという点が重要だ。エージェントは以下の順序で動作する：
search_toolsで候補を絞り込むget_toolでスキーマを取得するexecute_toolでツールを実行する
このプラグインはEmbeddingモデルを使ってツールカタログをベクトル化し、「list transactions」のような自然言語クエリに対して意味的に近いツール群を返す。元記事ではEmbeddingモデルの連携先としてOpenAIが示されているが、プラグイン設定上はモデルのエンドポイントを指定する形式をとっており、OpenAI互換のAPIを提供する他のサービスを利用できる可能性がある。ただし元記事ではOpenAI以外の具体的なサービス名は明示されていないため、実際に試す際はFabric GatewayのドキュメントでサポートされるEmbeddingモデルの選択肢を確認することを推奨する。
複数MCPサーバーを1つのエンドポイントに束ねる
Tool Searchプラグインを適用する前提として、まず複数のMCPサーバーを統合する必要がある。Fabric Gatewayでは、各MCPサーバーへの接続（Connection）を登録し、それをルート（Route）に紐付ける。認証情報はGateway側のセキュアなVaultに保管されるため、クライアント側に認証情報を持たせる必要がない。
記事では以下の2サーバーを例に使っている：
| 接続名 | アップストリームURL | APIキー |
|---|---|---|
| banking-mcp | https://intergalacticbanking-mcp-production.up.railway.app/mcp |
banking-mcp-demo-key |
| support-mcp | https://intergalacticsupport-mcp-production.up.railway.app/mcp |
support-mcp-demo-key |
それぞれに個別ルート（/banking/mcp、/support/mcp）を作成した後、両サービスを束ねる第3のルート（例：/banking/all）を作成する。このルートへのリクエストひとつで、2サーバー合計103個のツール定義にアクセスできる。ツール名はサービスごとにプレフィックスが付与されるため（例：ban__banking_list_transactions）、どのサーバー由来かは識別できる。
ただし、この時点ではまだクライアントに103個のツール定義が全件返される。前述のTool Searchプラグインを適用することで、ここが変わる。
トレースによるデバッグ
Fabric GatewayはすべてのリクエストのテレメトリーをGateway側で自動収集する。ルートマッチング、プラグイン実行、アップストリームへの通信がトレースとして確認できるため、クライアントがエラーを返したとき、何がどこで失敗したかをGateway側から調査できる。
整理：このアプローチが解決すること
Fabric Gatewayを使うことで得られるのは以下の制御だ：
- 認証情報の集中管理：各MCPサーバーのAPIキーをクライアントに渡さずGatewayのVaultで管理
- エンドポイントの統合：複数サーバーへのアクセスを1URLに集約
- コンテキストの制御：ツール定義がいつ会話に入るかをエージェントが選択できる
なお、記事は正直に注記している。トークン削減率や削減コストの実測値は示されていないと。検索結果、取得スキーマ、ツールレスポンスはすべてコンテキストを消費し、探索自体もリクエストを追加する。加えて、Tool SearchプラグインにはEmbeddingサービスとの連携設定が必要で、そのコストや遅延は別途考慮が必要になる。実際の効果はワークフロー全体で測定する必要がある。
詳細はManage MCP context with Postman Fabric Gatewayを参照していただきたい。
