Podman MCPサーバーの使い方 — Dockerとの違いとrootless接続

Podman MCPサーバーは、PodmanまたはDockerのコンテナ操作をClaude Codeから自然文で実行できるようにするMCPサーバーです。コンテナの一覧・起動・停止、イメージのビルドとプッシュ、ネットワークやボリュームの参照までをツール呼び出しとして提供します。開発元はRed Hatのエンジニアが公開する個人リポジトリで、Podman公式プロジェクト(containers組織)配下ではありません。公式MCP Registryにはnpm・PyPI・GitHub Releasesバイナリの3形態で登録済みです。

このサーバーの独自性は、Podman REST API(Unix socket経由)とCLIラッパーという2つの実装を状況に応じて切り替えられる点にあります。以下ではその切り替え方、rootless環境での接続先の見分け方、Claude Codeへの追加手順、つまずきやすい点までを順に確認します。

Podman MCPサーバーとは

Podman MCPサーバーとは、コンテナランタイムをMCP経由で操作できるようにするサーバーです。GoでMCPの公式SDKを使って実装されており、npm・PyPI・GitHub Releasesのバイナリで配布されています。開発者はRed Hat所属のMarc Nuri氏で、manusa/podman-mcp-serverという個人名義のリポジトリです。Podmanプロジェクト自身(containers組織)が持つ公式ツールではないため、「Red Hatのエンジニアが手がける準公式のサーバー」という位置付けで捉えるのが正確です。

公式のMCP Registryにはio.github.manusa/podman-mcp-serverとして登録されており、最新版はv0.0.15です。バージョン番号が0.0系であることは、APIやツール名がまだ安定版に達していないことを示しています。今後のマイナーアップデートでツール名やパラメータが変わる可能性は、通常の1.0以降のソフトウェアより高いと見ておくのが無難です。

MCP Registryを検索すると、同じ「Podman」を扱うio.github.crunchtools/podmanという別サーバー(mcp-podman-crunchtools)も見つかります。開発元が異なる別プロジェクトなので、claude mcp addで指定するパッケージ名を取り違えないよう注意が必要です。本記事が扱うのはRed HatのMarc Nuri氏によるnpm/PyPI配布のpodman-mcp-serverです。

名前は「Podman」ですが、実際にはPodmanとDockerの両方を自動検出して使えます。ローカル環境にどちらか一方でも入っていれば、明示的な設定なしで動きます。

Claude CodeにPodman MCPを追加する

前提条件はPodmanかDockerのどちらかがインストール済みで、コマンドが実行できる状態になっていることです。podman infoまたはdocker infoが正常終了すれば準備は完了です。

npmが入っている環境なら、claude mcp addコマンド1行で追加できます。

claude mcp add podman -- npx -y podman-mcp-server@latest

Node.jsではなくPythonの環境を使っている場合は、uvx経由でも同じことができます。

claude mcp add podman -- uvx podman-mcp-server@latest

追加後はclaude mcp listでpodmanがconnectedと表示されるかを確認します。表示されない、あるいはfailedになっている場合は、PodmanかDockerのデーモン(またはソケット)が起動しているかを先に疑います。

> 実行中のコンテナを一覧表示して

接続が正常なら、上記のような自然文の指示だけでコンテナ一覧・イメージビルド・ログ確認まで実行できるようになります。

APIとCLI、2つの実装を使い分ける

Podman MCPサーバーの技術的な特徴は、バックエンドの実装を2種類持ち、状況に応じて自動的に切り替える設計にあります。

既定では自動検出です。Podmanのソケットが見つかればapi実装を、見つからなければcli実装を使います。挙動を固定したい場合は--podman-implフラグで明示できます。

# CLIラッパーの実装を強制する
podman-mcp-server --podman-impl=cli
 
# REST API実装を強制する(Podmanソケットが必須)
podman-mcp-server --podman-impl=api

ソケットの探索順はrootful環境とrootless環境で異なります。この違いを把握しておくと、コンテナがつながらない原因の切り分けが早くなります。

一般的な開発マシンではrootless Podmanを使うことが多く、ソケットはユーザーごとの$XDG_RUNTIME_DIR配下に作られます。管理者権限なしで動く分、システム全体のコンテナには手が届かず、自分が起動したコンテナだけを操作対象にできます。これはコンテナが乗っ取られた場合の被害範囲を、ホストのroot権限まで広げない設計です。逆にrootfulなPodmanを使っている場合は、/run/podman/podman.sockへの書き込み権限を持つユーザー全員がroot相当の操作を実行できる点を踏まえて権限を絞る必要があります。

使えるツールの範囲

Podman MCPサーバーが提供するツールは13個で、コンテナ・イメージ・ネットワーク・ボリュームの4カテゴリーに分かれます。

コンテナとイメージは読み書き両方に対応します。container_list container_inspect container_logsのような参照系に加えて、container_run container_stop container_removeのような操作系も揃っています。イメージ側も同様にimage_build image_pull image_push image_removeが使えます。

一方でネットワークとボリュームは、network_listとvolume_listの参照のみです。ネットワークの作成・削除やボリュームの作成・削除を任せるツールは、v0.0.15の時点では実装されていません。ネットワーク構成やボリューム管理まで自動化したい場合、この範囲外の操作はdocker network createのようなコマンドを別途Bashツール経由で実行することになります。

配布形態は3つあります。Node.js環境向けのnpmパッケージ、Python環境向けのPyPIパッケージ、そしてGitHub Releasesで配布されるプラットフォーム別のスタンドアロンバイナリです。CI環境のようにNode.jsもPythonも入れたくない場合は、バイナリを直接ダウンロードして実行する選択肢があります。動作の実体はどの配布形態でも同じGoバイナリで、npm/PyPIパッケージはそのバイナリを取得して起動するラッパーという扱いです。

よくあるつまずき

接続はできているのにコンテナが見えない

rootless Podmanとrootful Podmanで別々のソケットを持つため、dockerコマンドをsudoで使っている環境では、MCPサーバー側がrootlessソケットを拾い、既存のコンテナ(rootfulで作成したもの)が見えないことがあります。CONTAINER_HOST環境変数で使いたいソケットのパスを明示すると解消します。

HTTPモードで起動したのにSSEでしか繋がらない

--portはStreamable HTTPとSSEの両方を/mcpと/sseで提供します。--sse-portは非推奨の旧モードで、SSEのみに限定されます。混同するとクライアント側の期待するエンドポイントとずれるため、新規に設定する場合は--sse-portではなく--portを使います。

api実装にしたいのにcliにフォールバックする

--podman-impl=apiを指定してもソケットが見つからなければ起動時にエラーになります。Docker Desktopのみをインストールしていてrootless Podmanのソケットが存在しない環境では、api実装は使えません。この場合はcli実装(既定の自動検出、あるいは明示指定)を使うのが正しい選択です。

バージョンアップでツール名が変わった

0.0系のバージョンでは後方互換性が保証されていません。CIやスクリプトから特定のツール名(container_runなど)を前提に自動化している場合、アップデート前にnpx @modelcontextprotocol/inspector@latestでツール一覧の差分を確認しておくと事故を防げます。

まとめ

Podman MCPサーバーは、Red Hatのエンジニアが個人名義で公開している準公式のMCPサーバーです。公式MCP Registryに登録済みですが、バージョンは0.0系で、ツール名やパラメータは今後変わりうる段階です。導入はclaude mcp add podman -- npx -y podman-mcp-server@latestの1行で完結し、PodmanとDockerのどちらでも自動検出で動きます。技術的な要は、REST API実装(優先度100)とCLIラッパー実装(優先度50)を自動選択し、--podman-implで固定もできる構成です。rootless環境ではソケットの探索順を把握しておくと、コンテナが見えないトラブルの切り分けが速くなります。ネットワークとボリュームは参照のみで書き込み系ツールが無い点、バージョンが0.0系でツール名が変わりうる点は、自動化に組み込む前に押さえておく価値があります。コンテナオーケストレーション側の操作まで含めたい場合はKubernetes MCPサーバーの使い方、レジストリ側のイメージ検索や選定を自動化したい場合はDocker Hub MCPサーバーが対応します。

よくある質問

リモートのPodmanホストを操作できますか

CONTAINER_HOST環境変数にリモートソケットのアドレスを指定すれば、理論上はリモートホストにも接続できます。ただしPodman MCPサーバー自体にSSHトンネルを張る機能は無いため、podman system connectionなどで別途トンネルを確立しておく必要があります。

Docker Desktopだけの環境でも使えますか

使えます。Podmanのソケットが存在しない環境ではcli実装が自動的に選ばれ、dockerバイナリをシェルアウトで呼び出します。Podman固有の機能(rootless実行のソケット探索など)は関係しなくなり、Dockerの操作範囲に準じます。

MCP経由の操作はホストのシェルより安全ですか

一概には言えません。MCPサーバーが提供するツールは引数のスキーマが決まっている分、任意コマンド実行より誤操作の余地は狭くなります。ただしcontainer_runはコンテナ内でのコマンド実行を許すため、信頼できないイメージを対象に使う場合はBashツールの権限管理と同程度の警戒が必要です。