銀河へのAIガイド:MCPツールキットとゲートウェイの説明

投稿日 10月 24, 2025

これは、 AI Guide to the Galaxyで、ホストのOleg ŠelajevがDockerのプリンシパルソフトウェアエンジニアであるJim Clarkと話をして、DockerのMCPツールキットとMCPゲートウェイを解き明かしたインタビューの要約版です。

TLです。博士

  • それらは何ですか:MCP Toolkit は、MCP サーバーの検出、実行、および管理に役立ちます。MCP ゲートウェイは、それらを統合し、エージェント クライアントに安全に公開します。
  • Dockerを選ぶ理由: すべてがコンテナとして実行され、サプライチェーンチェック、シークレット分離、OAuthサポートが行われます。
  • 使い方: MCPカタログからサーバーを選択し、MCPゲートウェイを起動すると、クライアント(Claudeなど)が即座にツールを確認します。

まず最初に、公式の概要とハウツーが必要な場合は、 Docker MCP Catalog and Toolkit.

簡単な起源の話(なぜMCPとDockerなのか?

オレグ: あなたはしばらくエージェントに深く関わってきました。これはどこから始まったのでしょうか?

ジム: ツール呼び出しが登場したとき、 ツールはコンテナによく似ているという、シンプルだが強力なことに気づきました。そこで、ツールをDockerイメージでラップし、エージェントに制御された「手」を与えたところ、すべてがうまくいきました。それは、モデル コンテキスト プロトコル (MCP) 仕様が上陸する前でさえありました。Anthropic が MCP をリリースしたとき、それは私たちがすでに構築していたものに名前を付けました。

MCP Toolkitが実際に解決すること

オレグ: では、ツールキットは初日にどのような問題を解決するのでしょうか?

ジム: インストールとオーケストレーション。Toolkit は、コンテナとしてパッケージ化され、すぐに実行できる MCP サーバー (YouTube トランスクリプト、Brave 検索、Atlassian など) のカタログを提供します。クローン作成も環境ドリフトもありません。画像をつかんで開始し、実行するだけです。Docker はこれらのイメージをビルドして Hub に発行すると、プル時に一貫性とガバナンスが得られます。

オレグ: そして、それは単一のクライアントフレンドリーなサーフェスを提供しますか?

ジム: その通り。Toolkit はクライアントに対する MCP サーバーとして機能し、有効にしたサーバーを集約して、クライアントがツールを 1 か所に一覧表示できるようにします。

MCP ゲートウェイの適合方法

オレグ: Docker Desktop内に「Toolkit」が表示されます。MCP ゲートウェイはどこで来ますか?

ジム: ゲートウェイは、ツールキット 内の 中核となる部分であり、どのMCPサーバーがどのクライアントに公開されるかを統合するプロセス(およびオープンソースプロジェクト)です。CLI と UI は、ローカルのコンテナー化されたサーバーと 信頼できるリモート MCP サーバーの両方を管理します。これにより、クライアントをアタッチし、必要に応じて OAuth を実行し、1 つのエントリ ポイントを介してこれらのリモート機能を安全に使用できます。

オレグ: クライアントの視点から見ることができますか?

ジム: もちろん。Gatewayを起動し、Claudeを接続し、 mcp listを実行すると、そのセッションで利用可能なツール(Brave Web Search、Get Transcriptなど)が、Gatewayがオンデマンドで起動するコンテナに支えられていることがわかります。

セキュリティ:出所、秘密、ドラマのないOAuth

オレグ: サーバーが実行される前にどのような強化が行われますか?

ジム: プル/実行時に、来 歴の検証を行い、Dockerがイメージをビルドしたことを確認し、SBOMをチェックし、サプライチェーンチェック(Docker Scout経由)を実行して、改ざんされたものを実行しないようにします。

オレグ: そして資格は?

ジム: 追加したシークレット (たとえば、Atlassian の場合) は、実行時 にのみターゲット コンテナにマウント され、他のシークレットは見ることができません。リモートサーバーの場合、ゲートウェイは OAuthフローを処理し、トークンを取得またはプロキシして適切なコンテナまたはリクエストパスに送信できます。これは、ローカルインジェクションとリモートOAuthの2種類のシークレット管理であり、どちらもDocker Desktop CLIから制御されます。

プロファイル、フィルタリング、および「必要なツールだけ」

オレグ: サーバーが 30 している場合、特定のクライアントに表示される範囲を設定できますか?

ジム: はい。ゲートウェイの実行ごとにサーバーを選択し、 ツール、プロンプト、およびリソースをフィルタリング して、クライアントが必要なサブセットのみを取得するようにします。コードと一緒にバージョン管理できる「プロファイル」のように扱います。ファイルと構成を作成すると、チームで繰り返し可能になります。さまざまな構成に対して 複数の ゲートウェイを実行することもできます (たとえば、「チェス ツール」と「クラウド運用ツール」など)。

ローカル開発から本番環境へ (そして再び)

オレグ: いじくり回しから耐久性のあるものに移行するにはどうすればよいですか?

ジム:作成優先にしてください。ゲートウェイとサーバーは作成ファイルでサービスとして定義されているため、エージェントスタックは再現可能です。そこからクラウドにプッシュ: Google Cloud Run などのパートナーは、すでに Compose からのワンコマンド デプロイをサポートしており、Azure 統合が進行中です。ローカルから始めて、リモートランにシームレスに移行します。

オレグ: そしてモデルを選ぶのは?

ジム: ローカルで実験し、必要に応じてモデルを交換し、エージェントの仕事に合ったMCPツールを接続します。パターンは同じで、モデルを選び、ツールを選び、構成し、出荷します。

MCP Gateway の使用開始 (分単位)

オレグ: 私のために道を要約してください。

ジム:

  1. Docker Desktop (または CLI) のカタログからサーバーを選択します。
  2. MCP ゲートウェイを起動し、クライアントを接続します。
  3. 必要に応じて、シークレットを追加するか、OAuth を経由するフローを使用します。
  4. ツールをプロファイルにフィルタリングします。
  5. Compose でキャプチャしてスケールアウトします。

MCP Toolkit と Gateway がチームのワークフローを改善する理由

  • 迅速なオンボーディング: グルーコードや競合する環境はなく、サーバーはコンテナ化されています。
  • セキュリティ組み込み: サプライチェーンチェックとスコープ付きシークレットアクセスにより、リスクが軽減されます。
  • 1つのワークフロー: ローカルデバッグ、Compose 設定、クラウドデプロイ。同じプリミティブで、書き換えが少ない。

試してみよう

最初のプロファイルをスピンアップし、お気に入りのクライアントをゲートウェイに向けます。エージェント スタックを拡張する準備ができたら、ローカル イテレーション用の Docker Desktop やオンデマンド クラウド リソース用の Docker Offload などのツールを検討し、Compose ですべてを宣言型に保ちます。

構築する準備はできましたか?探索する Docker MCP Catalog and Toolkit 開始する。

詳細情報

投稿カテゴリ

関連記事