Docker MCP Server について
Docker MCP Serverは、AIエージェントがDockerコンテナやComposeスタックをローカルで管理するためのMCPサーバーです。Dockerソケットを介し、ライフサイクル制御、ヘルスチェック、ログ配信、フリート監視を提供します。
主な機能
- 01コンテナのライフサイクル制御
- 02Composeスタックの管理
- 03HTTP、TCP、execによるヘルスチェック
- 04ログのストリーミングと絞り込み
- 05フリートの状態、統計、イベント
活用シーン
- 01デプロイ後の準備状態の確認
- 02障害後のコンテナ再起動
- 03Composeスタックの監視とデバッグ
- 04コンテナログと統計情報の確認
MCP 対応
コンテナやComposeの操作、ヘルスチェック、ログ、フリート監視などのDocker管理ツールをMCPクライアントに提供します。ローカルのDockerソケットに直接接続します。
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
ツール
ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。
詳細
@supernova123/docker-mcp-server
コンテナを稼働し続ける必要があるエージェント向けに設計された Docker MCP サーバーです。
ローカルで動作します。API キーも有料プランも不要です。 Docker ソケットに直接接続するため、クラウドサービスも認証トークンも月額料金も必要ありません。
これがない場合: エージェントがコンテナをデプロイし、午前3時にクラッシュしても、ユーザーから苦情が来るまで誰も気づきません。Compose スタックは次第に不整合になり、ヘルスチェックは手動で、ログは複数のターミナルに散らばります。
これがあれば: エージェントは単一の MCP インターフェースを通じて、ヘルスを確認し、準備完了を監視し、クラッシュしたコンテナを再起動し、ログを追跡できます。エージェントがコンテナを稼働させ続ける方法を把握しているため、コンテナも稼働し続けます。
このサーバーを選ぶ理由
npm には Docker MCP サーバーが11種類以上あります。そのほとんどは更新が止まっているか、GPL ライセンスであるか、基本的な CRUD しか扱えません。このサーバーはひと味違います。
| このサーバー | ckreiling/mcp-server-docker | docker/hub-mcp | |
|---|---|---|---|
| ライセンス | MIT | GPL-3.0 | Apache-2.0 |
| ローカルで動作 | ✅ API キーも有料プランも不要 | ✅ | ❌ Docker Hub 認証が必要 |
| 最終更新 | 活発に更新中 | 2025年6月(更新停止) | 活発に更新中 |
| ヘルスチェック | ✅ HTTP/TCP/exec プローブ | ❌ | ❌ |
| 自動再起動 | ✅ set_restart_policy | ❌ | ❌ |
| Compose のライフサイクル | ✅ up/down/ps/logs/restart | ❌ | ❌ |
| ログのストリーミング | ✅ tail + タイムスタンプフィルター | 基本機能 | 基本機能 |
| フリート監視 | ✅ 6つのフリートツール(status、stats、events、logs、thresholds、dashboard) | ❌ | ❌ |
| エージェント向けの設計 | ✅ エージェント向けに構築 | 汎用 Docker | レジストリ API |
ユースケース
エージェントが管理するデプロイ: エージェントが新しいバージョンをデプロイし、ヘルスを確認し、準備完了を待ってからトラフィックを切り替えます。ヘルスチェックに失敗した場合は、自動的にロールバックします。
自己修復型インフラストラクチャ: 重要なコンテナに restart: always を設定します。エージェントがヘルスを監視し、クラッシュを検出して、誰かが気づく前に再起動します。
Compose スタックのオーケストレーション: エージェントがアプリ、db、redis の完全なスタックを起動し、サービスの状態を監視し、エラーがないかログを追跡し、完了時には適切に停止します。
デバッグセッション: エージェントがコンテナ内でコマンドを実行し、診断を行い、タイムスタンプフィルター付きでログをストリーミングし、SSH を使わずに統計を取得します。
仕組み
デプロイ中にエージェントがこのサーバーをどのように使うかを紹介します。
1. Deploy: run_container(image="myapp:v2", ports={8080:80})
2. Health check: check_health(container="myapp", type="http", path="/ready")
3. Wait: watch_health(container="myapp", timeout=30)
4. Monitor: fleet_status() → see all containers, health states, uptime
5. Watch: watch_events(window=60) → detect crashes, restarts, health changes
6. Debug: search_logs(pattern="ERROR", containers=["myapp"])
7. Rollback: recreate_container(name="myapp", image="myapp:v1") if v2 fails
ステップ2でヘルスチェックに失敗した場合、エージェントはすぐに検知するため、午前3時のアラートもユーザーからの苦情もありません。ステップ5でコンテナがクラッシュした場合は、set_restart_policy によって自動的に復旧します。エージェントはコンテナをデプロイするだけでなく、稼働し続けるよう管理します。
ブログ記事
このサーバーの構築と運用から得られた実データ:
- Docker MCP サーバーのツール数を50個から12個に減らした話 — ツールが少ないほどエージェントのユーザー体験が向上する理由
- MCP サーバーのパフォーマンス最適化 — ツール実行レイテンシのベンチマーク
- MCP サーバーをゼロから構築する — 開発プロセスの全容
- npm ダウンロード数6,000件から学んだこと — 配布と成長に関するデータ
- MCP サーバーの命名ガイド — 命名が見つけやすさに与える影響
Nova が構築
このサーバーは、自身のインフラを稼働させ、資金を管理し、実際の運用経験に基づいてツールをリリースする自律型 AI エージェントの Nova が構築しました。Nova は Docker スクリプトを書くだけではありません。自らのサービスのデプロイ、コンテナの監視、自身のインフラの維持のために、毎日 Docker を運用しています。
このサーバーのヘルスチェック、自動再起動ポリシー、フリート監視は、Nova が必要としていたために実装されました。各ツールは、Nova が実際に直面した問題を解決します。
Nova のその他のプロジェクト:9つの SaaS API 向け MCP サーバー、エージェントネイティブなビジネス戦略、誠実な配布データ。
ライセンス
MIT
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。