mcpField
D
dokploy-mcp-server

dokploy-mcp-server

ローカル
github.com/sapientsaiクラウド・インフラ31 週間前に更新
リポジトリ

dokploy-mcp-server について

dokploy-mcp-serverは、セルフホスト型PaaSのDokployを操作するMCPサーバーです。カテゴリ別のアクション型ツールで、一般的なデプロイやインフラ管理を扱い、APIエンドポイントごとにツールを設ける方式よりツール数を抑えています。

主な機能

  1. 01プロジェクトとアプリの管理
  2. 02Docker Composeサービスの操作
  3. 036種類のデータベース管理
  4. 04ドメイン、バックアップ、サーバーの管理
  5. 05カテゴリ別アクション型ツール

活用シーン

  1. 01アプリのデプロイや停止
  2. 02Composeサービスの更新
  3. 03対応する複数のデータベースの運用
  4. 04ドメインとサーバーインフラの管理

MCP 対応

カテゴリ別のアクション型ツールを通じて、MCPクライアントにDokployの管理操作を公開します。stdioとhttpStreamに対応し、URLとAPIキーでDokployインスタンスに接続します。

設定

ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。

mcp.json · 共通設定
{
  "mcpServers": {
    "jordanburke-dokploy": {
      "command": "npx",
      "args": [
        "-y",
        "dokploy-mcp-server"
      ],
      "env": {
        "DOKPLOY_URL": "<DOKPLOY_URL>",
        "DOKPLOY_API_KEY": "<DOKPLOY_API_KEY>",
        "TRANSPORT_TYPE": "<TRANSPORT_TYPE>",
        "PORT": "<PORT>",
        "HOST": "<HOST>"
      }
    }
  }
}
起動コマンドnpx -y dokploy-mcp-server
設定が必要な環境変数
DOKPLOY_URLDokploy instance URL (e.g., https://dokploy.example.com)
DOKPLOY_API_KEYシークレットDokploy API key (generate in Settings > API Keys)
TRANSPORT_TYPETransport: 'stdio' (default) or 'httpStream' for remote/Docker deployments
PORTHTTP port for httpStream transport (default 3000)
HOSTHTTP host for httpStream transport (default 0.0.0.0)

ローカルサーバーにはマシン上の実行環境（Node.js 18 以上など）が必要です。設定ファイルの場所はクライアントごとに異なります。

パッケージ
npmdokploy-mcp-server1.6.2

ツール

16

掲載時のツール一覧 · 今日に更新

このツールにパラメーターはありません。

詳細

dokploy-mcp-server

npm version

Dokploy（オープンソースでセルフホスト可能な PaaS）向けの包括的な Model Context Protocol (MCP) サーバーです。Claude などの AI アシスタントを通じて、アプリのデプロイ、コンテナ、データベース、ドメイン、サーバーを管理できます。

このサーバーを選ぶ理由

Dokploy v0.30.8 に対応しています。 ツールは v0.30.8 の OpenAPI 仕様（604 パス）に基づいて構築されています。以下の比較は 2026-10-03 に測定しました。

公式 Dokploy MCP は、API エンドポイントごとに 1 つのツールを生成します。最新リリースの @dokploy/[email protected] では 604 個のツールが公開されており、それぞれが Dokploy v0.30.8 の OpenAPI 仕様にある 604 個のパスに対応しています。網羅性は完全ですが、最初の質問をする前に、これらすべてのスキーマがモデルのコンテキストに読み込まれます。

このサーバーでは、同じ API を手作業で整理し、27 個のツール（カテゴリごとに 1 つで、それぞれ action 列挙型を受け取ります）にまとめています。多くのセルフホストユーザーが日常的に使用する、デプロイと運用に関する機能をカバーしています。

コンテキストコスト
公式 @dokploy/mcpこのサーバー
公開されるツール60428（27 + info）
tools/list スキーマのペイロード319,143 バイト51,974 バイト
最初に読み込まれるおおよそのトークン数約 80k約 13k
ツールスキーマの中央値387 バイト1,257 バイト

2026-10-03 に、@dokploy/[email protected]（公開済みの最新バージョン）と、Dokploy v0.30.8 に対応するこのサーバーのビルドを対象に測定しました。各サーバーを stdio 経由で起動し、tools/list を送信して、シリアライズされたツール配列のバイト数を数えました（概算トークン数を求めるため、4 で割っています）。

コンテキストウィンドウが 200k トークンの場合、公式サーバーは何かを質問する前にその約 40% を消費しますが、このサーバーが消費するのは約 6.5% です。こちらのスキーマの中央値が大きいのは意図的です。説明に、呼び出しの失敗を防ぐワークフローの知識（どのサービス ID がどの databaseType と組み合わさるかなど）が含まれているためです。

機能比較

公式サーバーのツール数はカテゴリごとの数で、稼働中の tools/list（@dokploy/[email protected]）から取得しています。

カテゴリ公式 MCPこのサーバー
プロジェクト11 ツール1 ツール（6 アクション）
アプリケーション32 ツール1 ツール（24 アクション）
Compose31 ツール1 ツール（21 アクション）
デプロイ9 ツール1 ツール（5 アクション）
Docker21 ツール（ディスク使用量を含む）1 ツール（17 アクション）
Docker ボリューム8 ツール1 ツール（8 アクション）
Docker イメージ3 ツール1 ツール（3 アクション）
ネットワーク9 ツール1 ツール（9 アクション）
概要3 ツール1 ツール（3 アクション）
DNS プロバイダー11 ツール1 ツール（11 アクション）
Vault プロバイダー7 ツール1 ツール（7 アクション）
ドメイン10 ツール1 ツール（9 アクション）
リダイレクト4 ツール1 ツール（4 アクション）
サーバー19 ツール1 ツール（9 アクション）
設定52 ツール1 ツール（5 アクション）
データベース94 ツール（6 エンジン）1 ツール（17 アクション、6 DB すべて）
バックアップ12 ツール1 ツール（6 アクション）
ボリュームのバックアップ6 ツール1 ツール（6 アクション）
プレビューデプロイ4 ツール1 ツール（4 アクション）
スケジュール6 ツール1 ツール（6 アクション）
監査ログ1 ツール1 ツール（1 アクション）
環境7 ツール1 ツール（6 アクション）
インフラストラクチャ13 ツール（ポート、証明書、認証）1 ツール（8 アクション）
マウント6 ツール1 ツール（6 アクション）
SSH キー7 ツール1 ツール（6 アクション）
レジストリ7 ツール1 ツール（7 アクション）
宛先6 ツール1 ツール（6 アクション）
合計399 ツール27 ツール

主な利点：

  • トークン使用量を最小限に抑制 - 399 エンドポイント分の機能を 27 ツールで提供し、コンテキスト使用量を約 6 分の 1 に抑えます
  • 統合データベースツール - 1 つのツールで、dbType + action パラメーターを使って 6 種類すべてのデータベース（postgres、mysql、mariadb、mongo、redis、libsql）を操作できます
  • 厳選された説明 - 各ツールで、どのパラメーターがどのアクションと組み合わせて使われるかを説明しているため、最初の試行で呼び出しが成功します
  • アクションベースの設計 - 各ツールには action 列挙型パラメーターがあり、その他のパラメーターはアクションに応じて任意です
公式サーバーを使う場合

公式サーバーの604個のツールのうち、399個は上記のカテゴリに含まれています。残りの205個に相当するツールはここにはありません。

  • 通知（41個のツール） - メール、Slack、Discord、Telegram、Gotify の Webhook
  • ユーザー、組織、ロール、SSO（67個のツール） - ユーザー管理、組織、カスタムロール、SSO、SCIM、forwardAuth
  • Git プロバイダー（32個のツール） - GitHub、GitLab、Gitea、Bitbucket アプリの設定
  • AI プロバイダー（14個のツール） - ログ分析と Compose 生成のための Dokploy 独自の LLM 統合
  • クラスターと Swarm（8個）、パッチ（12個）、タグ（8個）、ロールバック（2個）、管理（1個）
  • Dokploy Cloud の商用機能（20個のツール） - Stripe による課金、ライセンスキー、ホワイトラベル化

これらのいずれかをワークフローで使用する場合は、公式サーバーを使うか、両方を実行してください。

インストール

Claude Desktop / Claude Code

MCP 設定に追加します。

{
  "mcpServers": {
    "dokploy": {
      "command": "npx",
      "args": ["-y", "dokploy-mcp-server"],
      "env": {
        "DOKPLOY_URL": "https://dokploy.example.com",
        "DOKPLOY_API_KEY": "your-api-key"
      }
    }
  }
}
Cursor

.cursor/mcp.json に追加します。

{
  "mcpServers": {
    "dokploy": {
      "command": "npx",
      "args": ["-y", "dokploy-mcp-server"],
      "env": {
        "DOKPLOY_URL": "https://dokploy.example.com",
        "DOKPLOY_API_KEY": "your-api-key"
      }
    }
  }
}
Docker
docker run -e DOKPLOY_URL=https://dokploy.example.com \
           -e DOKPLOY_API_KEY=your-api-key \
           -e TRANSPORT_TYPE=httpStream \
           -p 3000:3000 \
           dokploy-mcp-server

環境変数

変数必須デフォルト説明
DOKPLOY_URLはい-Dokploy インスタンスの URL
DOKPLOY_API_KEYはい-Dokploy の Settings > API Keys で取得する API キー
TRANSPORT_TYPEいいえstdioトランスポートモード：stdio または httpStream
PORTいいえ3000HTTP ポート（httpStream モードのみ）
HOSTいいえ0.0.0.0HTTP ホスト（httpStream モードのみ）

ツール（27）

各ツールでは action 列挙型を使って操作を選択します。パラメーターは任意で、選択した操作に応じて使用されます。

dokploy_project（6 個のアクション）

アクション：list | get | create | update | remove | duplicate

プロジェクトを管理します。list と get は、アプリケーション、Compose、データベース（名前、ID、ステータスを含む）がネストされた環境を返すため、追加の呼び出しなしでサービス ID を確認できます。create では name が必須です。update では projectId とフィールドが必須です。remove では projectId が必須です。duplicate では sourceEnvironmentId と name が必須です。

ステータスラベルの読み方。 Dokploy のステータス列挙型は idle | running | done | error で、[IDLE]、[RUNNING]、[DONE]、[ERROR] と表示されます。これは稼働中のコンテナーの状態ではなく、デプロイの状態を示します。[DONE] は最後のデプロイが完了したことを意味し、[IDLE] は何も実行されていないことを意味します。どちらも、現在コンテナーが起動しているとは限りません。実際に稼働しているものを確認するには、dokploy_docker の getContainers を確認してください。

dokploy_application（24 個のアクション）

アクション：create | get | update | move | deploy | start | stop | delete | markRunning | refreshToken | cleanQueues | killBuild | cancelDeployment | reload | saveEnvironment | setEnvVars | getEnvKeys | getEnvValuesUnsafe | saveBuildType | traefikConfig | readMonitoring | readLogs | search | deployNginxQuickstart

アプリケーションのライフサイクル全般を管理します。ほとんどのアクションで applicationId が必要です。create では name と environmentId が必要です。deploy は redeploy フラグに対応しています。readMonitoring では appName が必要です。search は q／name／appName／repository／owner／dockerImage／projectId／environmentId でアプリケーションを検索し、limit（1～100、デフォルトは20）と offset を指定できます。返信には、ページが切り捨てられたかどうかが示されます。deployNginxQuickstart は environmentId（および任意の serverId）を受け取り、生成された traefik.me ドメイン上に「Hello World」nginx デモアプリを作成してデプロイします。これは Dokploy のオンボーディング用スモークテストです。

環境変数の処理。 get はマスクされた環境変数の概要（件数のみ）を返し、値は返しません。残りの処理には、次の3つのアクションを使用します。

  • setEnvVars — サーバー内で細かくマージします。set（1行ごとに KEY=VALUE を指定して更新または追加）および／または unset（KEY 名の配列）を渡します。読み取り・変更・書き込みはサーバー側で行われます。ツールの結果は、変更されたキー名のみを一覧にしたマスク済みの確認応答です。変更対象外のキーの値がトランスクリプトに含まれることはありません。
  • getEnvKeys — KEY 名のみを並べ替えて返します。安全に読み取れます。
  • getEnvValuesUnsafe — KEY=VALUE の全内容を返す安全でないエスケープハッチです。値が本当に必要な場合にのみ使用してください。出力はツールのトランスクリプトと、保持されるエージェントのログに含まれます。
  • saveEnvironment — 全置換です。環境変数の全内容を明示的に設定するワークフロー向けに残されています。

sourceType：

  • github → repository + owner + branch（非公開の場合は githubId も必要）
  • git → customGitUrl + customGitBranch
  • docker → dockerImage

基盤となる API は gitlab／bitbucket／gitea／drop ソースにも対応していますが、それらにはプロバイダー固有のフィールドが必要で、現時点ではこのツールから公開されていません。

dokploy_compose（21 個のアクション）

アクション：create | get | update | delete | deploy | start | stop | move | loadServices | loadMounts | getDefaultCommand | cancelDeployment | cleanQueues | killBuild | refreshToken | saveEnvironment | setEnvVars | getEnvKeys | getEnvValuesUnsafe | readLogs | search

Docker Compose を管理します。ほとんどのアクションで composeId が必要です。create では name と environmentId が必要です。deploy では redeploy と freshVolumes を任意で指定できます。freshVolumes を指定すると、最初に docker compose down --volumes が実行され、サービスのボリュームデータが削除されます（docker-compose タイプのみ）。loadMounts では serviceName が必要です。cancelDeployment／cleanQueues／killBuild／refreshToken では composeId が必要です。search では dokploy_application と同じ検索フィールドを使用します。

環境変数の処理。 dokploy_application と同じ形式です。get はマスクされた概要を返し、setEnvVars はマージし、getEnvKeys はキー名を一覧表示し、getEnvValuesUnsafe はエスケープハッチとして機能し、saveEnvironment は全置換します。

sourceType：

  • github → repository + owner + branch（任意で composePath）
  • git → customGitUrl + customGitBranch（非公開の場合は customGitSSHKeyId も必要）
  • raw → composeFile（インライン YAML）

基盤となる API は gitlab／bitbucket／gitea ソースにも対応していますが、それらにはプロバイダー固有のフィールドが必要で、現時点ではこのツールから公開されていません。

dokploy_database（17 個のアクション）

アクション：create | get | update | move | start | stop | deploy | rebuild | remove | reload | changeStatus | saveEnvironment | setEnvVars | getEnvKeys | getEnvValuesUnsafe | saveExternalPort | search

データベースを一元管理します。すべてのアクションで dbType（postgres | mysql | mariadb | mongo | redis | libsql）が必要です。ほとんどのアクションでは databaseId も必要です。create の基本パラメーターは、dbType + name + environmentId + databasePassword です。

環境変数の処理。 dokploy_application と同じ形式です。get はマスクされた概要を返し、setEnvVars はマージします（すべてのエンジンで動作します）。getEnvKeys はキー名を一覧表示し、getEnvValuesUnsafe は値を直接取得するための手段です。

エンジンごとの追加パラメーター：

  • postgres / mysql / mariadb — databaseName + databaseUser も必要です。mysql / mariadb では databaseRootPassword も指定できます。
  • mongo — databaseUser が必要です（databaseName は不要です）。
  • redis — databasePassword のみです。
  • libsql — appName + dockerImage + sqldNode（primary | replica）が必要です。sqldPrimaryUrl + enableNamespaces も指定できます。

changeStatus では applicationStatus（idle | running | done | error）を使用します。search は libsql を除くすべてのエンジンを対象とします。libsql には検索エンドポイントがないため、dokploy_project または dokploy_environment から libsql データベースを探してください。

dokploy_domain（9 個のアクション）

アクション：create | list | get | update | delete | toggleEnable | generate | canGenerateTraefikMe | validate

ドメインと DNS を管理します。create には host + applicationId|composeId が必要です（Compose ドメインの場合は serviceName も必要です）。列挙値：certificateType（letsencrypt | none | custom）、domainType（compose | application | preview）。validate には domain が必要です。任意で serverId を指定すると、そのサーバーの IP アドレスに対する DNS を確認できます（Dokploy v0.30.8 では、以前の serverIp フィールドが置き換えられました）。

update では enabled を指定して、ドメインの有効化フラグを明示的な値に設定できます。toggleEnable はそのフラグを切り替えますが、結果は報告されません。API は説明のないレスポンス本文を返すため、確実に最終状態を指定する必要がある場合は update を使用してください。

dokploy_redirects（4 個のアクション）

アクション：create | update | remove | get

アプリケーションの URL リダイレクトルールを、Traefik の正規表現と置換文字列のペアで指定します。create には regex + replacement + permanent + applicationId が必要です。update には redirectId とルールのフィールドが必要です。remove / get には redirectId が必要です。変更を反映するには、アプリケーションを再デプロイする必要があります。

dokploy_environment（6 個のアクション）

アクション：create | get | list | update | remove | duplicate

プロジェクトの環境を管理します。create には projectId + name が必要です。list には projectId が必要です。

dokploy_server（9 個のアクション）

アクション：list | get | create | update | remove | count | publicIp | getMetrics | getServices

サーバーを管理します。create には name + ipAddress + port + username + sshKeyId + serverType（deploy | build）が必要です。getMetrics には url + token が必要です。getServices には serverId が必要で、そのサーバーにデプロイされたアプリケーション、Compose サービス、データベースを一覧表示します。サーバーを削除する前に確認してください。

dokploy_backup（6 個のアクション）

アクション：create | get | update | remove | listFiles | manualBackup

バックアップのスケジュール設定とトリガーです。createには、schedule + prefix + destinationId + database + databaseTypeが必要です。エンジンに一致するサービス ID を1つ指定してください。

  • databaseType: postgres → postgresId
  • databaseType: mysql → mysqlId
  • databaseType: mariadb → mariadbId
  • databaseType: mongo → mongoId
  • databaseType: libsql → libsqlId
  • databaseType: web-server → サービス ID は不要です（Dokploy サーバー自体をバックアップします）
  • compose スタック内の DB をバックアップする場合 → composeId + serviceName + エンジンを指定したdatabaseType

createとupdateでは、includeEncryptionKeyも指定できます。これを指定すると、データベースの暗号化キーがバックアップと一緒に保存されます。

manualBackupには、backupId + backupTypeが必要です。

  • postgres | mysql | mariadb | mongo | libsql — 個別の DB バックアップ
  • compose — スタック全体のバックアップ
  • webServer — Dokploy サーバーのバックアップ
dokploy_volume_backup（6 個のアクション）

アクション：create | update | remove | get | list | runManually

rclone を使って取得する、スケジュール設定されたボリュームレベルのバックアップです。DB ネイティブのダンプを取得するdokploy_backupとは異なります。

createには、name + volumeName + prefix + cronExpression + destinationIdが必要です。また、一致する*Idを持つserviceTypeに加えて、appName、keepLatestCount、enabled、turnOff（バックアップ期間中にサービスを停止します）を指定できます。volumeNameは^[a-zA-Z0-9][a-zA-Z0-9_.-]*$に一致する必要があり、リクエスト送信前に検証されます。updateには、volumeBackupIdと同じフィールドが必要です。remove／getにはvolumeBackupIdが必要です。listにはid（親サービス ID）+ volumeBackupTypeが必要です。runManuallyは、volumeBackupIdを指定してバックアップを即時に実行します。

dokploy_deployment（5 個のアクション）

アクション：list | queueList | killProcess | readLogs | remove

デプロイを追跡します。listには、applicationId|composeId|serverId|type+idが必要です。typeの列挙値：application | compose | server | schedule | previewDeployment | backup | volumeBackup（データベースのデプロイはこのエンドポイントではなく、データベースリソース自体を通じて一覧表示されます）。queueListにはapplicationIdが必要です。killProcessにはdeploymentIdが必要です。readLogsは、単一のデプロイのログファイルを読み取ります。removeはデプロイレコードを削除します。

dokploy_preview_deployment（4 個のアクション）

アクション：list | get | remove | redeploy

親アプリケーションに紐づく、PR ごとおよびブランチごとのプレビューデプロイです。listにはapplicationIdが必要です。get／remove／redeployにはpreviewDeploymentIdが必要です。redeployでは、デプロイレコードのtitleとdescriptionを任意で指定できます。

dokploy_schedule（6 個のアクション）

アクション：create | update | remove | get | list | runManually

アプリケーション、compose サービス、サーバー、または Dokploy サーバー自体に対してコマンドを実行する cron スケジュールです。createには、name + cronExpression + commandに加えて、scheduleTypeとそれに一致する ID が必要です。また、shellType（bash | sh）、複数行のコマンド用のscript、timezoneも指定できます。listには、id（親 ID、またはdokploy-server）+ scheduleTypeが必要です。runManuallyは、scheduleIdを指定してスケジュールを即時に実行します。

scheduleType：application | compose | server | dokploy-server。

dokploy_docker（17 個のアクション）

アクション：getContainers | restartContainer | startContainer | stopContainer | killContainer | removeContainer | getConfig | findContainers | listContainerFiles | readContainerFile | writeContainerFile | deleteContainerFile | getEvents | getServerHealth | getDiskUsage | getBuildCache | pruneBuildCache

Docker デーモンを管理します。すべてのアクションで、リモートサーバーを対象にするための省略可能な serverId を指定できます。

コンテナー。 ライフサイクルアクション（restart／start／stop／kill／removeContainer）と getConfig には containerId が必要です。findContainers には appName と method（match | label | stack | service）が必要です。method=match の場合、appType には stack | docker-compose を指定できます。method=label の場合、type は必須で、standalone | swarm を指定できます（指定しないと API に拒否されます）。

コンテナーファイル。 listContainerFiles、readContainerFile、writeContainerFile、deleteContainerFile には containerId と path（コンテナー内の絶対パス）が必要です。writeContainerFile には content も必要です。readContainerFile の出力は 100,000 文字で切り捨てられます。writeContainerFile は実行中のコンテナーに書き込みます。パスがマウント上にない限り、再デプロイ時に変更は失われます。

可観測性。 getEvents には minutes（1～1440、既定値は 15）が必要です。getServerHealth には sinceHours（1～168）が必要です。

ディスク。 getDiskUsage は docker system df を実行します。コンテナー、ボリューム、イメージ、ビルドキャッシュが対象なので、空き容量の問題を調べるときはここから始めてください。getBuildCache でキャッシュの詳細を確認でき、pruneBuildCache でキャッシュを消去できます（cleanType=dockerBuilder を指定した dokploy_settings の clean と同じ効果です）。

dokploy_docker_volume（8 個のアクション）

アクション：getVolumes | getVolumesSize | getVolumeConfig | removeVolume | listVolumeFiles | readVolumeFile | writeVolumeFile | deleteVolumeFile

Docker ボリュームの管理と、ボリューム内のファイルへのアクセスを行います。すべてのアクションで省略可能な serverId を指定できます。getVolumeConfig と removeVolume には volumeName が必要です。ファイル操作には volumeName と path が必要で、writeVolumeFile には content も必要です。readVolumeFile の出力は 100,000 文字で切り捨てられます。removeVolume はボリュームのデータを消去します。まず dokploy_volume_backup でバックアップしてください。実行中のコンテナーへの書き込みとは異なり、ボリュームへの書き込みは再デプロイ後も保持されます。

dokploy_docker_image（3 個のアクション）

アクション：getImages | getImageConfig | removeImage

Docker イメージの一覧を管理します。getImageConfig には imageRef（nginx:latest またはイメージ ID）が必要です。removeImage には repository、tag、id のすべてが必須です。getImages の出力から値を取得してください。さらに省略可能な force を指定できます。ディスク使用量とビルドキャッシュについては dokploy_docker（getDiskUsage、getBuildCache、pruneBuildCache）を参照してください。

dokploy_network（9 個のアクション）

アクション：list | get | create | remove | recreate | resync | inspect | import | networksToSync

Docker ネットワークを管理します。create には name が必要で、driver（bridge | overlay）、internal、attachable、enableIPv4、enableIPv6、mtu（68～65535）、ipam、serverId を指定できます。get、inspect、remove、recreate、resync には networkId が必要です。recreate はネットワークを削除して再追加するため、接続されているサービスは一時的に切断されます。resync はネットワークに触れずに Docker からネットワーク情報を再取得し、Dokploy の保存済みレコードを更新します。networksToSync は、Docker ホスト上に存在するものの、まだ Dokploy で追跡されていないネットワークを一覧表示します。import は names で指定したネットワークを取り込みます。ワークロードへのネットワーク接続には、dokploy_application の update の networkIds、または dokploy_compose の update の serviceNetworks を使用します。

dokploy_overview（3 アクション）

アクション：services | backups | domains

すべてのプロジェクトを対象とした読み取り専用の概要です。パラメーターは不要です。詳細を確認する前に全体像を把握するために使用します。services はすべてのアプリケーション、Compose サービス、データベースとそのステータスを一覧表示します。backups は設定済みのすべてのバックアップとスケジュールを、domains はすべてのドメインとその接続先を一覧表示します。Dokploy の OpenAPI 仕様ではこれらのレスポンス本文が記述されていないため、このツールは JSON として表示します。

インベントリには search よりこちらを優先してください。 Dokploy の検索インデックスはプロジェクトツリーより範囲が狭く、アプリケーションを1つ、Compose サービスを14個保持するテストインスタンスでは、application.search の一致件数は0件、compose.search は5件でした。dokploy_application、dokploy_compose、dokploy_database の search アクションは、すでに存在するとわかっているサービスを探すためのものです。何が存在するかを一覧表示するには、dokploy_overview と dokploy_project を使用してください。

dokploy_infrastructure（8 アクション）

アクション：createPort | deletePort | createAuth | deleteAuth | listCerts | getCert | createCert | removeCert

ポート、基本認証、SSL 証明書を管理します。

dokploy_mounts（6 アクション）

アクション：create | update | remove | get | listByServiceId | allNamedByApplicationId

サービスにアタッチされたボリューム、バインドマウント、ファイルマウントです。create には type + mountPath + serviceId + serviceType が必要で、さらにタイプごとにフィールドを1つ指定します。ボリュームには volumeName、バインドには hostPath、ファイルには filePath + content を指定します。update には mountId と任意のフィールドを指定します。remove／get には mountId を指定します。listByServiceId には serviceType + serviceId が必要です。allNamedByApplicationId は applicationId の名前付きボリュームを一覧表示します。

serviceType：application | postgres | mysql | mariadb | mongo | redis | compose | libsql

マウントの変更を反映するには、親サービスの再デプロイが必要です。

dokploy_ssh_key（6 アクション）

アクション：create | list | get | update | remove | generate

Git ベースのデプロイ用 SSH キーを管理します。create には name + privateKey + publicKey + organizationId が必要です。get には sshKeyId が必要です。update には sshKeyId が必要で、name、description、lastUsedAt は任意です。remove には sshKeyId が必要です。generate では type（rsa|ed25519）を使用します。

dokploy_registry（7 アクション）

アクション：list | get | create | update | remove | test | testById

プライベートイメージの取得に使用するコンテナレジストリです。create には registryName + username + password + registryUrl が必要です。registryType のデフォルト値は cloud です。get／remove には registryId が必要で、update には registryId と各種フィールドを指定します。test は認証情報を保存せずに確認します。testById は保存済みのレジストリを registryId でテストし、必要に応じて serverId も指定できます。

dokploy_destination（6 アクション）

アクション：list | get | create | update | remove | test

バックアップの書き込み先となる、S3 互換の宛先です。create には name + accessKey + bucket + region + endpoint + secretAccessKey が必要で、provider と additionalFlags（rclone に渡されます）も指定できます。get／remove には destinationId が必要で、update には destinationId と各種フィールドを指定します。test は保存せずに create と同じフィールドを検証します。

dokploy_audit_log（1 アクション）

アクション：list

Dokploy の監査証跡を検索します。すべてのフィルターは任意です：userId、userEmail、resourceName、auditAction、resourceType、from／to（ISO タイムスタンプ）、limit（デフォルトは50、最大500）、offset。

auditAction：create | update | delete | deploy | cancel | redeploy | login | logout

resourceType：project | service | environment | deployment | user | customRole | domain | certificate | registry | server | sshKey | gitProvider | notification | settings | session

ワイヤーレベルのクエリパラメーター名は action です。このツールでは、各ツールで使用される action 識別子との衝突を避けるため、auditAction として公開しています。

dokploy_dns_provider（11 個のアクション）

アクション：list | get | create | update | remove | testConnection | listZones | listRecords | createRecord | updateRecord | deleteRecord

DNS プロバイダーの認証情報と、ゾーンおよびレコードの管理です。config は providerType に応じて形式が分かれます。cloudflare（apiToken）、route53（accessKeyId、secretAccessKey）、porkbun（apiKey、secretApiKey）、infomaniak（apiToken）、または ovh（applicationKey、applicationSecret、consumerKey、任意の endpoint、デフォルトは ovh-eu）です。update には dnsProviderId + name + config が必要です。API はプロバイダーにパッチを適用するのではなく置き換えるため、名前を変更する場合は認証情報を再送信する必要があります。testConnection は、保存済みの dnsProviderId または生の config を受け取り、保存前に認証情報を確認します。

レコード：listZones（dnsProviderId）、listRecords（+ zoneId）、createRecord／updateRecord（+ type、recordName、content、任意の ttl と proxied、更新時はさらに recordId）、deleteRecord（+ recordId）。type には A、AAAA、CNAME、MX、TXT、NS、SRV、CAA、PTR を指定できます。proxied が有効になるのは Cloudflare の場合のみです。recordName は DNS レコード名で、API の name フィールドに対応します。ここではプロバイダーの name と区別しています。

プロバイダーの取得結果に含まれるのは、id、name、providerType のみです。保存された認証情報がツールの出力に表示されることはありません。

dokploy_vault_provider（7 個のアクション）

アクション：list | get | create | update | remove | testConnection | listSecretNames

外部シークレットマネージャーの設定です。config は providerType に応じて、8 つのバックエンドのいずれかの形式になります。hashicorp、infisical、aws（Secrets Manager）、aws-parameter-store（任意の parameterPath。/ で始まる必要があります）、doppler、azure、scaleway、phase（token、appId、env、任意の path と apiUrl）です。assignments は [{ projectId, environmentIds? }] 形式で、Vault が利用する Dokploy プロジェクトを指定します。

名前が重複しているフィールドに注意してください。infisical.projectId と scaleway.projectId は各プロバイダー固有のプロジェクト ID であり、assignments で使う Dokploy の projectId ではありません。

update には vaultProviderId、name、config、assignments の 4 つすべてが必要です。DNS プロバイダーと同様、API はパッチを適用するのではなく置き換えるため、まず get を実行して現在の名前と割り当てを取得してください。

listSecretNames（vaultProviderId + projectId、任意の environmentId）は、シークレットの名前のみを返します。Dokploy にはシークレットの値を読み取る API がなく、プロバイダーの認証情報が返されることもありません。これは env ツールと同じルールです。

dokploy_settings（5 個のアクション）

アクション：health | version | ip | clean | reload

システム設定です。clean は cleanType を使用します。サーバー単位の値は all | images | volumes | stoppedContainers | dockerBuilder | dockerPrune（serverId が適用されます）、グローバル値は monitoring | deploymentQueue | sshPrivateKey です。reload は reloadTarget（server | traefik）を使用します。traefik の場合は serverId が適用されます。

使用例

アプリケーションをデプロイする
"Deploy my web app" → dokploy_application { action: "deploy", applicationId: "app-123" }
PostgreSQL データベースを起動する
"Start the postgres database" → dokploy_database { action: "start", dbType: "postgres", databaseId: "db-456" }
システムの健全性を確認する
"Is Dokploy healthy?" → dokploy_settings { action: "health" }
すべてのコンテナーを一覧表示する
"What containers are running?" → dokploy_docker { action: "getContainers" }

開発

pnpm install
pnpm dev          # Development mode with watch
pnpm validate     # Format + lint + test + build
pnpm inspect      # Open MCP Inspector

ライセンス

MIT

SapientsAI SapientsAI 提供 — ビジネス向けのエージェント型 AI を構築

コメント

Markdown 対応

MCP は初めてですか？

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。