MCP プロトコルはほぼ 1 年前のもので、その間に開発者は何千もの新しい MCP サーバーを構築しました。6 か月前の MCP デモを振り返ると、ほとんどの開発者は 1 つまたは 2 つのローカル MCP サーバーを使用しており、それぞれがほんの一握りのツールしか提供していませんでした。6か月後、私たちは何千ものツールと新しい一連の問題にアクセスできるようになりました。
- どのMCPサーバーを信頼しますか?
- 最終的に必要とならないツール定義でコンテキストを埋めないようにするにはどうすればよいでしょうか?
- エージェントはどのようにしてツールを 効率的 かつ 自律的に検出、構成、使用しますか?
スマート検索 や ツール構成 などの Docker MCP Gateway の最新機能により、「 何を構成する必要がありますか?」 から 「エージェントに何を権限を与えることができるか」 に移行しています。
今週、Anthropic は 、より効率的なエージェントの構築に関する投稿も公開し、この投稿で説明するのと同じ問題の多くを指摘しています。ツール の導入 に向けて進歩したので、ツールを効果的に 使用 することについてもっと考え始めることができます。
動的 MCP を使用すると、エージェントはツールを検索したり追加したりするだけでなく、安全なサンドボックス内で新しいツールを作成するコードを記述し、ツールの効率とトークンの使用率の両方を向上させます。
エージェントがスマート検索を使用して MCP を動的に検索、追加、および構成できるようにする
今日の MCP の設定方法を考えると、このプロセスは特に エージェント的ではありません。通常、エージェントインターフェイスを完全に残し、昔ながらの設定ハッキング(通常は何らかのJSONファイルを編集)を行い、エージェントセッションを再起動してMCPが利用可能になったかどうかを確認します。MCPサーバーの数が増えるにつれて、これはうまくいくのでしょうか?
では、エージェントが 有用なMCPサーバーを発見するためにさらに多くのことをすることを妨げるものは何でしょうか?
DockerのOSSゲートウェイがここで役立つと思います。ゲートウェイは、エージェントとゲートウェイのカタログ内の任意の MCP サーバーとの間のインターフェイスを管理するため、その関係を新しい方法で仲介する機会があります。
ゲートウェイには、 を超えるキュレーションされたサーバーと、もちろん独自のプライベートカタログをキュレーションする機能( コミュニティレジストリ のサーバーを使用するなど)を含む、デフォルトのカタログである Docker MCPカタログ が付属しています。270また、Docker 上で実行されるため、最小限のセットアップでそれらをプルして実行できます。これは、信頼できる MCP サーバーの検出という最初の摩擦点に直接取り組みます。
図 1: Docker MCP ゲートウェイには、エージェントが Docker MCP カタログ内の信頼できる MCP サーバーを検出して接続できる新しいスマート検索機能である mcp-find と mcp-add が含まれるようになり、安全で動的なツールの使用が可能になります。
ただし、動的 MCP の本当の鍵は、エージェントの MCP セッションに対する小さいながらも重要な調整です。ゲートウェイは、エージェントがカタログを検索し、現在のセッションにサーバーを追加または削除するために使用する 、いくつかのプリモディアル ・ツール・セットを提供します。search_tools ツールを提案する Anthropicの投稿 と同様に、エージェントがMCPサーバーを管理するのに役立つ新しいツールを追加しました。
- mcp-findです。 現在のカタログ内の MCP サーバーを名前または説明で検索します。一致するサーバーをその詳細とともに返します。
- mcp-addです。 新しい MCP サーバーをセッションに追加します。サーバーはカタログに存在する必要があります。
この小さな調整により、エージェントは新しい MCP セッションのネゴシエーションを支援できるようになりました。これをもう少し具体的にするために、ゲートウェイに接続されたエージェントが DuckDuckGo MCP を要求し、検索を実行する様子を示します。
図 2: mcp-find と mcp-add を使用して DuckDuckGo MCP サーバーに接続し、検索を実行するデモ
エージェント主導のワークフローを使用した MCP サーバーの構成
上記の例では、エージェントをMCPのカタログに接続することから始めました(オプションについては、docker mcp client connect –helpを参照してください)。その後、エージェントは新しい MCP サーバーを現在のセッションに追加します。明確にするために、duckduckgo MCP サーバーは非常にシンプルです。構成を必要としないため、カタログを検索し、信頼できるレジストリからイメージをプルし、ローカルの Docker エンジンで MCP サーバーをスピンアップするだけで済みました。
ただし、一部の MCP サーバーでは、起動前に 入力 が必要です。たとえば、リモート MCP サーバーでは、ユーザーが OAuth フローを通過する必要がある場合があります。次の例では、ゲートウェイは、この新しい MCP サーバーを承認するように要求することで応答します。MCP が 誘導をサポートし、 mcp-ui などのフレームワークで MCP が UI 要素をチャットにレンダリングできるようになったため、クライアント側の機能に基づいてこれらのフローの最適化を開始しました。
図 3: mcp-findとmcp-addを使用して、OAuthフローを含むNotion MCPサーバーに接続する
工具の雪崩を避ける: 動的な工具の選択
より 効率的なエージェントの構築 の投稿で、著者らは、現在ツールがトークン消費の効率を低下させる2つの方法を強調しています。
- コンテキストウィンドウでのツール定義
- 中間ツールの結果
どちらの場合も結果は同じです。モデルに送信されないトークンが多すぎます。コンテキストウィンドウがツール定義以外の何十万ものトークンを蓄積するのに、驚くほど少ないツールが必要です。
繰り返しになりますが、これは改善できる点です。mcp ゲートウェイ プロジェクトでは、検索ツールで使用できるツールと、コンテキスト ウィンドウに追加されるツールを区別し始めました。エージェントにサーバー選択のためのツールを提供するのと同じように、ツールを選択する新しい方法をエージェントに提供できます。
図 4: 動的ツールの動作: ツールをアクティブに選択できるようになり、利用可能なすべてのツールをすべての LLM リクエストにロードする必要がなくなります。
アイデアは概念的に単純です。エージェントが、ツールを自動的にコンテキストウィンドウに配置しないサーバーを追加できるようにするオプションを提供しています。今日のエージェントでは、 これは、ツール/リスト リクエストでツール定義を返さないが、 ツール呼び出しを検索 できるようにするMCPサーバーを追加することを意味します。ツール/リストリクエストを仲介し、新しいタスク指向の検索ツールを挿入するためのMCPゲートウェイがあるため、これは簡単に行うことができます。mcp-exec や mcp-find などの新しいプリモディアルツールは、エージェントに MCP サーバーツールを検出して使用するための新しい方法を提供します。
ツールの選択について別の考え方をし始めると、さまざまな可能性が広がります。
新しい方法でツールを使用する: ツール呼び出しからコードモードを使用したツール構成まで
「コードモード」のアイデアは、CloudFlareが数週間前に ツールを使用するより良い方法 について投稿して以来、多くの注目を集めています。このアイデアは、実際には論文「CodeAct: Your LLM Agent Acts Better When Generating Code」にまで遡り、LLM が最初にエージェント アクションをコードに統合することでエージェント指向のタスクを改善できると提案しました。Anthropic の最近の投稿では、コンテキスト ウィンドウ内のツール定義とツール出力の数を減らすことでエージェントの効率を向上させる方法としてコード モードも概説しています。
私たちはこのアイデアに本当に興奮しています。エージェントがMCPツールインターフェイスに対して直接「コーディング」できるようにすることで、現在のMCPカタログのツールを新しい方法で使用する「コードモード」ツールをエージェントに提供できます。mcp-find と code-mode を組み合わせることで、エージェントは、コンテキストウィンドウに 1 つまたは 2 つの新しいツールを配置するだけで、使用可能なツールの大規模で動的なセットにアクセスできます。現在のコードモードツールはJavaScriptを記述し、利用可能なMCPサーバーをパラメータとして受け取ります。
コードモード: servers パラメーターにリストされている任意のサーバーからツールを呼び出すことができる JavaScript 対応ツールを作成します。
ただし、これは依然としてエージェントによって記述されたコードです。このコードを実行する場合は、サンドボックスで実行する必要があります。MCP サーバーはすでに Docker コンテナで実行されており、コード モード サンドボックスも例外ではありません。実際、このコンテナは他のMCPサーバーへのアクセスのみが必要なため、理想的なケースです。外部システムにアクセスするための権限は、すでにMCPレイヤーで管理されています。
このアプローチには、次の 3 つの主な利点があります。
- 設計による安全: エージェントはサンドボックス内に完全に含まれたままです。私たちはサンドボックスの利点を一切放棄しません。コード・モード・ツールは、カタログから選択したコンテナー化された MCP サーバーのみを使用します。
- トークンとツールの効率: 使用するツールは、すべてのリクエストでモデルに送信する必要はありません。後続のターンでは、モデルは 1 つの新しい コード モード ツールについて知るだけで済みます。実際には、これにより、各ターンにモデルに送信されるトークンが数十万個少なくなる可能性があります。
- 状態の永続性:ボリュームを使用して、ツール呼び出し間で状態を管理する方法を管理し、モデルに送信する必要のない、または送信すべきではない中間結果を追跡します。
このパターンの一般的な例は、GitHub公式のMCPサーバーを使用してコードモードツールを構築することです。GitHub サーバーにはたまたま多数のツールが同梱されているため、コードモードは劇的な影響を与えます。以下の例では、エージェントに、Github-official から新しいコードモードツールを作成し、MCP サーバーをマークダウンするように求めています。
図 5: MCP コードモードを使用して、GitHub Official および Markdownify MCP サーバーからツールを呼び出すコードを記述する
スマート検索とツールコンポジションの組み合わせにより、MCPを動的かつ安全に使用できるようになります。エージェントは、単にツールを見つけたり追加したりするだけではありません。新しいツールを作成するためのコードを記述し、安全なサンドボックスで安全に実行できます。
その結果、ツールの検出が迅速化され、トークンの使用量が減り、手動の手順が減り、開発者の時間がより集中できるようになります。
|
ワークフロー |
変更前: 静的 MCP セットアップ |
変更後: Docker MCP ゲートウェイを介した動的 MCP |
インパクト |
|---|---|---|---|
|
ツールの検出 |
MCP サーバーを手動で参照する |
mcp-findは、Docker MCPカタログ(230+サーバー)を名前/説明で検索します |
検出の迅速化 |
|
ツールの追加 |
MCP サーバーを手動で有効にする |
mcp-addは、エージェントが必要とするサーバーのみを現在のセッションにプルします |
手動設定はゼロです。ジャストインタイムツーリング |
|
認証 |
MCP サーバーを事前に設定する |
リモート・サーバーで OAuth を完了するようにユーザーに求める |
一部のクライアントは、よりスムーズなオンボーディングフローのために、 mcp の引き出し や mcp-ui などの UX などをサポートし始めています |
|
ツール構成 |
エージェントが生成したツール呼び出し。工具定義がモデルに送信されます |
コードモードでは、エージェントは複数のMCPツールを使用するコードを記述します |
マルチツールワークフローと統合出力 |
|
コンテキストサイズ |
未使用のツール定義を大量にロードする |
タスクに実際に必要なツールのみを保持します |
トークンの使用量と待機時間の削減 |
|
将来性 |
静的統合 |
サンドボックス スクリプティングを備えた動的なコンポーザブル ツール |
進化するエージェントの動作とカタログに対応 |
|
開発者の関与 |
絶え間ないコンテキストの切り替えと構成のハッキング |
エージェントのセルフサービス:ツールの検出、承認、調整 |
手動ステップが少なくなります。集中時間の向上 |
表 1: 動的MCPに対するDockerのスマート検索とツール構成の利点の概要
Docker からエディターへ: cagent と ACP を使用した動的 MCP ツールの実行
Dockerプラットフォームのもう1つの新しいコンポーネントは、オープンソースのエージェントビルダー&ランタイムである cagentで、 新しいエージェントをビルドして配布する簡単な方法を提供します。cagentの最新バージョンは、開発者がneovimや Zed などのACP対応エディターにカスタムエージェントを追加し、 Docker Hub にプッシュしたりプルしたりしてこれらのエージェントを共有できるエージェントクライアント プロトコル をサポートするようになりました。
つまり、スマート検索ツールやコードモードなどの機能の使用方法を知っている エージェント を構築し、cagentを使用してこれらのエージェントをACP搭載のエディターに埋め込むことができます。これは、現在編集しているプロジェクトに関連する新しいツールを見つけるのに役立つ、neovimで実行されているエージェントの例です。
図 6: エージェントクライアントプロトコルと、MCPサーバーの知識で事前構成されたcagentで構築されたカスタムエージェントを介してNeovimで動的MCPを実行する
Anthropic の人々は、状態の永続性とスキルに関するセクションで、動的ツールとコード モードの実行により、時間の経過とともにエージェントがうまく連携するコードとツールを蓄積する世界に近づくという考えもほのめかしています。現在の コードモード ツールは、プロジェクトに書き込んだコードをまだ保存していませんが、 ここではこれに取り組んでいきます。
上記の neovim の例では、 コード コンパニオン プラグインで ACP サポートを使用しました。また、このリポジトリのcagentアダプターも確認してください。Zedについては、 カスタムエージェントの追加 に関するドキュメントを参照し、もちろん、独自のカスタム agent.yaml ファイルを使用して cagent acp agent.yaml を試してください。
スマート検索とツールコンポジションを使用した動的MCPの使用開始
動的ツールが mcp ゲートウェイ プロジェクトで使用できるようになりました。明示的な機能セット (既存の –servers フラグを使用) を使用してゲートウェイを実行していない限り、これらのツールはデフォルトでエージェントで使用できます。動的ツール機能は、 docker mcp feature disable dynamic-tools を使用して無効にすることもできます。これは私たちが積極的に開発している機能ですので、試してみて、 問題を開くか、リポジトリで ディスカッション を開始して、ご意見をお聞かせください。
docker mcp client connect を使用してお気に入りのクライアントを MCP ゲートウェイに接続するか、Docker Desktop MCP Toolkit パネルの [クライアント] タブを使用して接続を追加して開始します。
概要
Docker MCP Toolkit は、信頼できるランタイム (Docker エンジン) と MCP サーバーのカタログを組み合わせたものです。Docker Desktop.4 から始まり、50 mcp-find 、 mcp-add 、 code-mode などの新しいツールで mcp ゲートウェイ インターフェイスを拡張し、エージェントが MCP サーバーをより効果的に検出し、これらのサーバーを新しい方法で使用できるようにしています。
信頼できるカタログからの検索やプル、OAuth フローの開始、サンドボックス ランタイムでのマルチツール ワークフローのスクリプト作成など、エージェントはより多くのことを自分で実行できるようになりました。そして、それは私たちが約束されたエージェントの未来に大きな一歩を踏み出します。
フィードバックがありますか?リポジトリで 課題 を開くか、 ディスカッション を開始します。
さらに詳しく
- MCP ゲートウェイ プロジェクトを探索する: コード、例、およびコントリビューション ガイドラインについては、 GitHub リポジトリ にアクセスしてください。
- スマート検索とツール構成の詳細: 完全なドキュメント を読んで、これらの機能がどのように動的で効率的なエージェント ワークフローを実現するかを理解してください。
- Docker の MCP ソリューションの詳細をご覧ください。
