大規模な言語モデル自体は、セマンティック検索および取得タスクに非常に役立ちます。ただし、適切なツールのコレクションと組み合わせると、その有用性が飛躍的に高まり、MCP サーバーは、LLM を活用した生産性スタックへの最も便利な追加機能の 1 つになります。まず、モデル コンテキスト プロトコル サーバーは、LLM プロバイダーとランタイム環境を、AI モデルをネイティブにサポートしていない外部サービスに接続します。これは、特定の LLM リクエストをアプリが理解できるツール呼び出しに変換することによって行われます。
私はかなりの数の MCP サーバーをいじってきましたが、LLM がアクセスできるデバイスにいくつかの制限を維持している限り、ホーム アシスタント ハブから Nextcloud アプリ スタックに至るまで、すべてのものとうまく連携しています。そして最近学んだことですが、適切な MCP サーバーとハイエンド MoE モデルを組み合わせることで、簡単な会話プロンプトを使用して Docker Workstation を制御できるようになります。
私が保存した 2 つの古い GPU は、新品の 2000 ドルのカードよりも多くの AI 作業を実行しているため、すぐにアップグレードするつもりはありません
安く売られていた 2 つの古い GPU からローカル AI セットアップを構築したところ、新しいカードよりも優れています
取り付けもとても簡単です
Docker には堅牢な MCP ゲートウェイがありますが (そのデスクトップ アプリはすぐにこの機能をサポートします)、基盤となる Docker 環境にアクセスできるようにするための回避策を検討する必要がありました。幸いなことに、開発者 ckleiling による Docker MCP Server パッケージを使用すると、変更を加えることなく、Docker セットアップのあらゆる側面を制御できます。
最初のいくつかのテストでは、ローカルの Docker 環境をこの MCP サーバーに接続したいと考えました。そこで、config.json という新しいドキュメントを作成し、次のコード スニペットを追加しました。
{
"mcpServers": {
"mcp-server-docker": {
"command": "uvx",
"args": [
"mcp-server-docker"
]
}
}
}
それから、私は運転しました uvx mcp-proxy –name-server-config config.json –allow-origin “*” –port 8001 –stateless –host 0.0.0.0 Docker MCP サーバーを起動して実行するためのターミナル内のコマンド。
コンテナ管理パイプライン全体をローカルに残しておきたかったので、Docker MCP をローカル LLM に接続しました。 Raspberry Pi ベースの Pi インスタンスで低パラメータのモデルを使用しようとしたときに、パラメータが低いモデルによって引き起こされる混乱を見た後、非常に強力な Qwen3.6-35B-A3B を RTX 3080 Ti で使用することにしました。 MoE オフロードを使用すると、私の古い GPU は 24 トークン/秒で簡単に実行できます。そして、参照ウィンドウは 100,000 トークンであり、それ以下でもありません。 llama-server Web UI は MCP サーバーをサポートしているため、次を使用しました。 –webui-mcp-server Docker MCP によって生成された URL を使用して相互にリンクする前に Qwen3.6-35B-A3B を実行する場合。
管理ツールに関する限り、Docker MCP Server には、Docker コンテナーを管理するために必要なものがすべて含まれています。コンテナの健全性の確認やログへのアクセスから、ボリュームの一覧表示やネットワークの詳細の変更に至るまで、非公式の Docker MCP サーバーは、LLM によって要求されたツール呼び出し機能を問題なく実行できました。推論タスクを処理する重い LLM があるため、複雑な命令でも処理でき、満足のいく結果が得られます。たとえば、すべてのボリュームを調べて現在孤立しているボリュームをリストするようにしたところ、Qwen3.6-35B-A3B はクエリを複数のツール呼び出しに分割してジョブを完了することができました。
Intel の最も安価な iGPU でローカル LLM を実行したところ、結果は驚くほど良好でした。
専用 GPU には匹敵しませんが、N100 上でいくつかの軽量 LLM を実行できます。
単純なプロンプトを使用して新しいコンテナを作成できます
問題が発生した場合には自動修正を実行することもできます
これまでのところ、Qwen3.6-35B-A3B + Docker MCP Server の組み合わせが既存のコンテナーを制御できる機能についてのみ説明してきました。ただし、このローカル LLM 制御の Docker パイプラインは、新しいコンテナーを最初から作成する場合と同様に効果的です。これを使用してコンテナ化されたデバイスを多数デプロイしてみましたが、成功するたびに、信号をやや曖昧にし、LLM に必要なパラメータを認識させるようにしました。
まず、LLM にローカル ディレクトリを使用して n8n インスタンスをデプロイするよう依頼しました。 /ホーム/ノード/.n8n フォルダーと 5678 を内部ポートおよび外部ポートとして使用します。いくつかのツール呼び出しの後、Qwen3.6-35B-A3B は自動化ツールを正常に開始しました。次に、状況を切り替えて、BentoPDF の例の唯一のパラメーターとして 3000:8080 のポート マッピングを指定しました。ここでも、LLM は Docker MCP サーバーを使用して問題なく BentoPDF を起動できました。
私は複数のコンテナを必要とする FOSS ツールをよく使用するため、LLM に Joplin コンテナを作成するよう依頼し、それにすべてのボリュームのディレクトリとして新しいフォルダを指定しました (Clunker によって基礎となる PC フォルダが台無しになるのが嫌だったので)。残念ながら、最初の実行ではコンテナが壊れてしまい、コンテナのデプロイ時に LLM が間違ったパラメータを追加したのではないかと思いました。しかし、結局のところ、私の Joplin サーバーには時刻同期の問題があり、LLM はこの問題をトラブルシューティングできるだけでなく、実行コマンドを変更することで問題を修正しました。
信号が誤って解釈されると、ボリューム マウントとネットワークが使用できなくなる可能性があります
Docker MCP サーバーが Qwen3.6-35B-A3B でうまく機能したことには本当に感銘を受けましたが、セットアップに使用したセキュリティ ルールを確認しないと、この記事が完了したとは言えません。 LLM はロジックから簡単に脱線してしまう可能性があることを念頭に置き、プロンプトを誤解して Docker MCP サーバーのツールを台無しにしてほしくありませんでした。
したがって、完全に機能するコンテナーが壊れた混乱に変わる可能性があるため、remove_volume ツールとremove_network ツールをリクエストを拒否するように設定します。このモードでremove_containerを設定することも考えましたが、トラブルシューティングのタスクによっては、古いインスタンスをクリアして同じ名前で新しいインスタンスを作成する必要があるため、コンテナを削除する前に許可を求めるようにLlama-ServerのWeb UIを構成しました。
しかし、これらのルールが整理されているので、LLM を利用した Docker 制御環境で文句を言う必要はありません。どちらかといえば、来週末にこのセットアップにリモート ノードを追加する予定です。
Leave a Reply