私たちは最近、新しく再考された Docker MCPカタログ をリリースし、検出が改善され、新しい提出プロセスが追加されました。コンテナ化されたMCPサーバーは 、エージェントアプリケーションを安全に実行および拡張する方法を提供し、ホストアクセスとシークレット管理に関連するリスクを最小限に抑えます。開発者は、完全なセキュリティスイート(署名、SBOM、認証、連続スキャン)を含むDockerビルドサーバーと、開発者が独自のDockerイメージを使用して構築および保守するコミュニティビルドサーバーの2つの方法でサーバーを送信できます。
このブログでは、MCP サーバーの設計、テスト、および提出用のパッケージ化に関する 5 MCP サーバーのベスト プラクティスを共有します。これらの推奨事項は、Docker MCP カタログ用に 100 を超える MCP サーバーを構築し、開発者を支援した経験に基づいています。提出プロセスを合理化し、 20 00万人以上のDocker開発者にリーチし、エージェントとそれらを使用する開発者の両方に真のユーティリティを提供するのに役立ちます。
1。エージェントのツール予算を意図的に管理する
「ツール予算」は、エージェントが効果的に処理できるツールの数を表す社内用語です。他の予算と同様に、予算を適切に管理することは、優れたユーザーエクスペリエンスの鍵です。MCPサーバーの作成者として、提供しすぎるツールとは、サーバーがより複雑で使用コストがかかり、ユーザーを遠ざける可能性があることを考慮することが重要です。一部の AI エージェントでは、ユーザーがツールを選択的に有効にできるようになり、エクスペリエンスの合理化に役立てられるようになりました。しかし、より良い戦略は、明確なユースケースを中心にツールセットを設計し、すべてのAPIエンドポイントを別々のツールにマッピングしないようにすることです。
たとえば、API にアクセスするための MCP サーバーを作成する場合、API のエンドポイントごとに 1 つのツールを作成したいと思うかもしれません。これはすぐに始める方法ですが、多くの場合、ツールセットが過負荷になり、導入が妨げられます。
では、エンドポイントごとに 1 つのツールが理想的でない場合、より優れた MCP サーバーをどのように設計すればよいのでしょうか。
ここで、MCP サーバのプロンプトの出番です。マクロのように考えてください。ユーザーに複数のツールを呼び出すように要求する代わりに、複数のツールまたはエンドポイント呼び出しをバックグラウンドでチェーンする 1 つのプロンプトを作成できます。これにより、ユーザーはエージェントに「ユーザーの請求書を取得してください」と依頼するだけで、エージェントはオーバーヘッドをさらすことなく 2 つまたは 3 つのツールを呼び出して、複雑さを内部で処理できます。
2。ツールのエンドユーザーはエージェント/LLM
見落とされがちな重要なポイントの 1 つは、ツールを実際に使用するのは、エンドユーザーではなく、エージェントまたは LLM であるということです。ユーザーはツールを有効にしますが、エージェントを呼び出すのはツールです。なぜこれが重要なのでしょうか?MCP サーバーを構築する場合、ユーザーと直接やり取りすることはありません。あなたは、彼らの代わりに行動するエージェントのために構築しています。
エラー処理は、開発者が一貫して問題に直面している領域の 1 つです。ツールが人間向けのエラーメッセージを返す場合、あなたが思っているようなユーザーエクスペリエンスを提供していない可能性があります。ツールを呼び出すのはユーザーではなくエージェントであり、エラーメッセージをユーザーに返す保証はありません。
エージェントは、タスクを完了するように設計されています。何かが失敗すると、彼らはしばしば別のアプローチを試みます。そのため、エラー処理は、エージェントが問題にフラグを立てるだけでなく、次に何をすべきかを決定するのに役立つ必要があります。「このシステムにアクセスできません」の代わりに、「このシステムにアクセスするには、MCPサーバーを有効なAPI_TOKENで構成する必要があります。現在のAPI_TOKENは無効です」という行に沿って何かを返します。
ここで行っているのは、アクセスが完全に拒否されたためではなく、設定ミスが原因でサードパーティシステムにアクセスできないことをエージェントに通知することです。この区別は重要です。アクセス権がないのは、ユーザーが MCP サーバーを適切に構成していないためであり、ハードな権限の問題ではありません。
3。人間とエージェントのためのドキュメント!
これは、同様に重要なポイント、つまり文書化につながります。
MCPサーバー向けに執筆するときは、エンドユーザーとAIエージェントの2つのオーディエンスにサービスを提供していることを覚えておいてください。エラー処理で見たように、両方のニーズを理解することが重要です。
ドキュメントは、各視聴者に明確に対応する必要があります。エンドユーザーは、なぜMCPサーバーを使用する 必要があるのか 、どのような問題を解決するのか、ワークフローにどのように適合するのかを知りたがっています。一方、エージェントは、適切に記述されたツール名と説明に基づいて、サーバーが特定のタスクに適しているかどうかを判断します。
MCPサーバーを実際に使用しているのはエージェントですが、エージェントがアクセスできるツールを決定するのはエンドユーザーであることに注意してください。あなたのドキュメントは両方をサポートする必要があります!
4。機能をテストするだけでなく、ユーザーとの対話もテストします
ドキュメントを検証する最良の方法の 1 つは、独自の MCP サーバーをテストすることです。開発中にサーバーと対話する最も簡単な方法は、 MCP インスペクタ ーを使用することです (ターミナルに npx @modelcontextprotocol/inspector と入力すれば、すぐに使用できます。
MCPサーバーが動作しているかどうかをテストするのは一般的ですが、インスペクターはエンドユーザーの視点から考えるのにも役立ちます。これにより、ユーザーがサーバーとどのように対話するか、およびドキュメントがそのエクスペリエンスをサポートしているかどうかをより明確に把握できます。
サーバーのテストには、次の 3 つの主要な手順があります。
- MCP サーバーへの接続: この手順は、サーバーが正しく実行するために必要なすべての構成をキャプチャしていることを検証するのに役立ちます。
- リストツール:これは、AIエージェントがMCPサーバーを初期化するときに表示されるものです。
- ツールコール: ツールが期待どおりに動作することを確認します。ここで、障害モードを検証できます。
設計上の重要な考慮事項の 1 つは、MCP サーバーのライフサイクルについて考えることです。 問う: MCP クライアントが MCP サーバーに接続するために何が必要か。ツールはどのようにリストアップし、発見すべきか?また、特定のツールを呼び出すプロセスはどのようなものですか?
たとえば、データベースの MCP サーバーを作成している場合です。一般的な API では、サーバーの起動時にデータベース接続を確立します。ただし、MCP サーバーを作成するときは、各ツール呼び出しをできるだけ自己完結型にすることを目指す必要があります。これは、サーバーの起動時ではなく、すべてのツール呼び出しに対して接続を作成することを意味します。これにより、サーバーが正しく構成されていない場合でも、ユーザーが接続してツールを一覧表示できるようになります。
これは最初はアンチパターンのように感じるかもしれませんが、実際にはこの文脈ではより理にかなっています。少しのレイテンシーと引き換えに、使いやすさと信頼性を向上させているのです。実際には、MCPがデータベース(またはサードパーティのシステム)への接続を必要とするのは、ツールが呼び出されたときだけです。MCP Inspector は、これを実際に確認し、ユーザーとエージェントの両方がサーバーとどのように対話するかをよりよく理解するための優れた方法です。
Docker MCP Toolkit を使用している場合、MCP サーバーが期待どおりに動作しているかどうかをテストする方法はいくつかあります。
次のコマンドを実行して、Docker Desktop で定義した構成を使用してツールを呼び出します。
`docker mcp tools call my-tool`
MCP クライアントに表示される内容をテストするには、次のコマンドを実行します。
`docker mcp gateway run --verbose --dry-run`
このコマンドは、Docker MCP カタログで有効になっていると仮定して、MCP クライアントから MCP サーバーへの呼び出しをシミュレートします。
5。コンテナを使用した MCP サーバーのパッケージ化
素晴らしい、私たちはMCPサーバーを作成してテストしました、次は何ですか?包装！
MCP サーバーのパッケージ化は、成果物を作成することではなく、成果物がどのように使用されるかを考えることです。ここでは少し偏見があるかもしれませんが、MCPサーバーをDockerイメージとしてパッケージ化することが正しい方法であると私たちは本当に信じています。
MCPサーバーには、Python、TypeScript、Javaなど、さまざまな種類があります。Docker イメージとしてパッケージ化すると、Docker イメージの性質上、サーバーを真に移植可能にすることができます。エンド ユーザーがシステムの構成方法に関係なく、MCP サーバーを実行できるようにすることができます。Docker コンテナを使用することは、他の人のマシンへの依存関係に対処するのを避ける最も簡単な方法です。Docker を実行できる場合は、MCP サーバーを実行できます。
優れたDockerfileを作成する方法については多くのリソースを利用できますが、正しいことをしたかどうかわからない場合は、いつでもGordonまたは「dockerai」コマンドを使用して改善できます。「docker ai improve my Dockerfile」と入力するだけで、Docker AIエージェントであるGordonがMCPサーバーのDockerfileの最適化を支援します。
MCP サーバーの提出方法
リポジトリにDockerfileが入ったら、 MCPサーバーを Docker公式レジストリに送信することをお勧めします。この記事の執筆時点では、提出されたすべての MCP サーバーは stdio トランスポート メカニズムを使用する必要があるため、コンテナとして実行する場合は、サーバーがこれをサポートしていることを確認してください。皆様のご応募をお待ちしております!
結論
新しいDocker MCPカタログにより、 MCPサーバーを安全に検出し、スケーリングすることがこれまで以上に容易になります。Dockerで構築されたサーバーを完全なセキュリティ処理で提出する場合でも、コミュニティのコントリビューターとして自分のサーバーを維持する場合でも、MCPサーバーに関する次の5つのベストプラクティスに従ってください。ツールの予算管理、エージェント向けの設計、ユーザーとLLMの両方向けの作成、徹底的なテスト、コンテナによるパッケージ化は、信頼性が高く、使いやすく、実際のエージェントワークロードに対応したMCPサーバーを作成するのに役立ちます。
あなたのものをDockerコミュニティで共有する準備はできましたか?Docker MCP カタログに提出して、何百万人もの開発者に公開してください。
さらに詳しく
- 新しいMCPカタログの発表ブログをご覧ください
- Docker MCP Catalog and Toolkit のドキュメントが見つかります。
- Docker Navigator ニュースレターを購読してください。
- Docker は初めてですか? アカウントを作成します。
- ご質問はございますか? Docker コミュニティがお手伝いします。