{
  "markdown": "# dokploy-mcp-server\n\n[![npm version](https://img.shields.io/npm/v/dokploy-mcp-server)](https://www.npmjs.com/package/dokploy-mcp-server)\n\nA comprehensive [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) server for [Dokploy](https://dokploy.com/) - the open-source, self-hosted PaaS. Deploy apps, manage containers, databases, domains, and servers through AI assistants like Claude.\n\n## Why This Server?\n\nThe [official Dokploy MCP](https://github.com/Dokploy/mcp) generates one tool per API endpoint — at the 0.29.14 measurement below, 546 of them, exactly matching the 546 paths in Dokploy's OpenAPI spec at that version. (Dokploy v0.30.2 ships 597 paths; the figures in this section are left at their measured values rather than re-estimated.) Coverage is complete, and every one of those schemas loads into the model's context before you ask your first question.\n\nThis server hand-curates the same API into **27 tools** (one per category, each taking an `action` enum), covering the deploy-and-operate surface most self-hosters use daily.\n\n### Context cost\n\n|                                    | Official `@dokploy/mcp` | This server      |\n| ---------------------------------- | ----------------------- | ---------------- |\n| Tools exposed                      | 546                     | 22 (21 + `info`) |\n| `tools/list` schema payload        | 294,957 bytes           | 34,528 bytes     |\n| Approximate tokens loaded up front | **~74k**                | **~8.6k**        |\n| Median tool schema                 | 388 bytes               | 1,131 bytes      |\n\nMeasured 2026-08-08 against `@dokploy/mcp@0.29.14` and `dokploy-mcp-server@1.8.2`, by starting each server, calling `tools/list`, and counting the serialized schema bytes (divided by 4 for a rough token estimate).\n\nSince that measurement this server grew to 27 tools tracking Dokploy v0.30.2. Measured the same way — live `tools/list` over stdio — it now exposes 28 tools (27 + `info`) for **48,452 bytes (~12.1k tokens)**. The official server has not been re-measured against 0.30.2, so the table above is left at the paired 0.29.14 figures rather than mixing a new number for one side with an old one for the other.\n\nOn a 200k-token context window, the official server spends more than a third of it before you ask anything. The larger median schema here is deliberate: descriptions carry the workflow knowledge that prevents failed calls, such as which service id pairs with which `databaseType`.\n\n### Feature Comparison\n\nTool counts for the official server are per category, taken from its live `tools/list`.\n\n| Category            | Official MCP           | This Server                   |\n| ------------------- | ---------------------- | ----------------------------- |\n| Projects            | 9 tools                | 1 tool (6 actions)            |\n| Applications        | 31 tools               | 1 tool (23 actions)           |\n| Compose             | 31 tools               | 1 tool (21 actions)           |\n| Deployments         | 9 tools                | 1 tool (5 actions)            |\n| Docker              | 12 tools               | 1 tool (17 actions)           |\n| Docker Volumes      | n/a (new in 0.30.2)    | 1 tool (8 actions)            |\n| Docker Images       | n/a (new in 0.30.2)    | 1 tool (3 actions)            |\n| Networks            | n/a (new in 0.30.2)    | 1 tool (8 actions)            |\n| Overview            | n/a (new in 0.30.2)    | 1 tool (3 actions)            |\n| DNS Providers       | n/a (new in 0.30.2)    | 1 tool (11 actions)           |\n| Vault Providers     | n/a (new in 0.30.2)    | 1 tool (7 actions)            |\n| Domains             | 9 tools                | 1 tool (9 actions)            |\n| Redirects           | 4 tools                | 1 tool (4 actions)            |\n| Servers             | 18 tools               | 1 tool (8 actions)            |\n| Settings            | 54 tools               | 1 tool (5 actions)            |\n| Databases           | 94 tools (6 engines)   | 1 tool (17 actions, all 6 DB) |\n| Backups             | 12 tools               | 1 tool (6 actions)            |\n| Volume Backups      | 6 tools                | 1 tool (6 actions)            |\n| Preview Deployments | 4 tools                | 1 tool (4 actions)            |\n| Schedules           | 6 tools                | 1 tool (6 actions)            |\n| Audit Log           | 1 tool                 | 1 tool (1 action)             |\n| Environments        | 7 tools                | 1 tool (6 actions)            |\n| Infrastructure      | 13 tools (ports+certs) | 1 tool (8 actions)            |\n| Mounts              | 6 tools                | 1 tool (6 actions)            |\n| SSH Keys            | 7 tools                | 1 tool (6 actions)            |\n| Registries          | 7 tools                | 1 tool (7 actions)            |\n| Destinations        | 6 tools                | 1 tool (6 actions)            |\n| **Total**           | **346 tools**          | **27 tools**                  |\n\nKey advantages:\n\n- **Minimal token usage** - 346 endpoints' worth of surface in 27 tools, for roughly an eighth of the context\n- **Unified database tool** - One tool handles all 6 database types (postgres, mysql, mariadb, mongo, redis, libsql) via `dbType` + `action` params\n- **Curated descriptions** - Each tool documents which parameters pair with which action, so calls succeed on the first try\n- **Action-based design** - Each tool has an `action` enum parameter; other params are optional based on action\n\n### When to use the official server instead\n\nThe official server covers 49 categories to this server's 27. Of its 546 tools, 346 fall inside the categories above; the remaining 200 have no equivalent here:\n\n- **Notifications** (41 tools) - email, Slack, Discord, Telegram, Gotify webhooks\n- **Users, organizations, roles, SSO** (64 tools) - user management, organizations, custom roles, SSO, SCIM, forwardAuth\n- **Git providers** (32 tools) - GitHub, GitLab, Gitea, Bitbucket app configuration\n- **AI providers** (14 tools) - Dokploy's own LLM integration for log analysis and compose generation\n- **Cluster and Swarm** (8 tools), **patch** (12), **tags** (8), **rollback** (2), **admin** (1)\n- **Dokploy Cloud commercial features** (18 tools) - Stripe billing, license keys, whitelabeling\n\nIf your workflow needs any of those, use the official server, or run both.\n\n## Installation\n\n### Claude Desktop / Claude Code\n\nAdd to your MCP configuration:\n\n```json\n{\n  \"mcpServers\": {\n    \"dokploy\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"dokploy-mcp-server\"],\n      \"env\": {\n        \"DOKPLOY_URL\": \"https://dokploy.example.com\",\n        \"DOKPLOY_API_KEY\": \"your-api-key\"\n      }\n    }\n  }\n}\n```\n\n### Cursor\n\nAdd to `.cursor/mcp.json`:\n\n```json\n{\n  \"mcpServers\": {\n    \"dokploy\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"dokploy-mcp-server\"],\n      \"env\": {\n        \"DOKPLOY_URL\": \"https://dokploy.example.com\",\n        \"DOKPLOY_API_KEY\": \"your-api-key\"\n      }\n    }\n  }\n}\n```\n\n### Docker\n\n```bash\ndocker run -e DOKPLOY_URL=https://dokploy.example.com \\\n           -e DOKPLOY_API_KEY=your-api-key \\\n           -e TRANSPORT_TYPE=httpStream \\\n           -p 3000:3000 \\\n           dokploy-mcp-server\n```\n\n## Environment Variables\n\n| Variable          | Required | Default   | Description                              |\n| ----------------- | -------- | --------- | ---------------------------------------- |\n| `DOKPLOY_URL`     | Yes      | -         | Your Dokploy instance URL                |\n| `DOKPLOY_API_KEY` | Yes      | -         | API key from Dokploy Settings > API Keys |\n| `TRANSPORT_TYPE`  | No       | `stdio`   | Transport mode: `stdio` or `httpStream`  |\n| `PORT`            | No       | `3000`    | HTTP port (httpStream mode only)         |\n| `HOST`            | No       | `0.0.0.0` | HTTP host (httpStream mode only)         |\n\n## Tools (27)\n\nEach tool uses an `action` enum to select the operation. Parameters are optional and used based on the chosen action.\n\n### `dokploy_project` (6 actions)\n\nActions: `list | get | create | update | remove | duplicate`\n\nManage projects. `list` and `get` return nested environments with their applications, composes, and databases (with names, IDs, and status), so you can discover service IDs without extra calls. `create` requires `name`. `update` requires `projectId` + fields. `remove` requires `projectId`. `duplicate` requires `sourceEnvironmentId` + `name`.\n\n**Reading the status label.** Dokploy's status enum is `idle | running | done | error`, rendered as `[IDLE]`, `[RUNNING]`, `[DONE]`, `[ERROR]`. It describes the **deployment**, not live container state — `[DONE]` means the last deploy finished, and `[IDLE]` means nothing has run, neither of which implies a container is up right now. Check `dokploy_docker` `getContainers` for what is actually running.\n\n### `dokploy_application` (23 actions)\n\nActions: `create | get | update | move | deploy | start | stop | delete | markRunning | refreshToken | cleanQueues | killBuild | cancelDeployment | reload | saveEnvironment | setEnvVars | getEnvKeys | getEnvValuesUnsafe | saveBuildType | traefikConfig | readMonitoring | readLogs | search`\n\nFull application lifecycle. Most actions require `applicationId`. `create` requires `name` + `environmentId`. `deploy` supports `redeploy` flag. `readMonitoring` requires `appName`. `search` finds applications by `q`/`name`/`appName`/`repository`/`owner`/`dockerImage`/`projectId`/`environmentId`, with `limit` (1–100, default 20) and `offset`; the reply flags a truncated page.\n\n**Env handling.** `get` returns a masked env summary (count only) — never the values. Three actions cover the rest:\n\n- `setEnvVars` — granular merge inside the server. Pass `set` (KEY=VALUE per line, upsert) and/or `unset` (array of KEY names). The read-modify-write happens server-side; the tool result is a masked confirmation listing only the changed key names. No untouched-key values ever enter the transcript.\n- `getEnvKeys` — returns KEY names only, sorted. Safe to read.\n- `getEnvValuesUnsafe` — **unsafe escape hatch** that returns the full `KEY=VALUE` blob. Use only when you genuinely need the values; the output is in the tool transcript and any retained agent logs.\n- `saveEnvironment` — full-replace, kept for explicit blob-set workflows.\n\n`sourceType`:\n\n- `github` → `repository` + `owner` + `branch` (+ `githubId` for private)\n- `git` → `customGitUrl` + `customGitBranch`\n- `docker` → `dockerImage`\n\n`buildType`: `dockerfile | heroku_buildpacks | paketo_buildpacks | nixpacks | static | railpack`.\n\nThe underlying API also supports `gitlab`/`bitbucket`/`gitea`/`drop` sources, but those need provider-specific fields not yet exposed by this tool.\n\n### `dokploy_compose` (21 actions)\n\nActions: `create | get | update | delete | deploy | start | stop | move | loadServices | loadMounts | getDefaultCommand | cancelDeployment | cleanQueues | killBuild | refreshToken | saveEnvironment | setEnvVars | getEnvKeys | getEnvValuesUnsafe | readLogs | search`\n\nDocker Compose management. Most actions require `composeId`. `create` requires `name` + `environmentId`. `loadMounts` requires `serviceName`. `cancelDeployment`/`cleanQueues`/`killBuild`/`refreshToken` require `composeId`. `search` takes the same query fields as `dokploy_application`.\n\n**Env handling.** Same shape as `dokploy_application`: `get` returns a masked summary, `setEnvVars` merges, `getEnvKeys` lists key names, `getEnvValuesUnsafe` is the escape hatch, `saveEnvironment` full-replaces.\n\n`sourceType`:\n\n- `github` → `repository` + `owner` + `branch` (+ `composePath`)\n- `git` → `customGitUrl` + `customGitBranch` (+ `customGitSSHKeyId` for private)\n- `raw` → `composeFile` (inline YAML)\n\nThe underlying API also supports `gitlab`/`bitbucket`/`gitea` sources, but those need provider-specific fields not yet exposed by this tool.\n\n### `dokploy_database` (17 actions)\n\nActions: `create | get | update | move | start | stop | deploy | rebuild | remove | reload | changeStatus | saveEnvironment | setEnvVars | getEnvKeys | getEnvValuesUnsafe | saveExternalPort | search`\n\nUnified database management. All actions require `dbType` (`postgres | mysql | mariadb | mongo | redis | libsql`); most also require `databaseId`. `create` baseline: `dbType` + `name` + `environmentId` + `databasePassword`.\n\n**Env handling.** Same shape as `dokploy_application`: `get` returns a masked summary, `setEnvVars` merges (works for every engine), `getEnvKeys` lists key names, `getEnvValuesUnsafe` is the escape hatch.\n\nPer-engine extras:\n\n- `postgres` / `mysql` / `mariadb` — also require `databaseName` + `databaseUser`. `mysql`/`mariadb` accept `databaseRootPassword`.\n- `mongo` — requires `databaseUser` (no `databaseName`).\n- `redis` — only `databasePassword`.\n- `libsql` — requires `appName` + `dockerImage` + `sqldNode` (`primary | replica`); accepts `sqldPrimaryUrl` + `enableNamespaces`.\n\n`changeStatus` uses `applicationStatus` (`idle | running | done | error`). `search` covers every engine except `libsql`, which has no search endpoint — locate libsql databases via `dokploy_project` or `dokploy_environment`.\n\n### `dokploy_domain` (9 actions)\n\nActions: `create | list | get | update | delete | toggleEnable | generate | canGenerateTraefikMe | validate`\n\nDomain/DNS management. `create` requires `host` + `applicationId`|`composeId` (and `serviceName` for compose domains). Enums: `certificateType` (`letsencrypt | none | custom`), `domainType` (`compose | application | preview`). `validate` requires `domain`.\n\n`update` accepts `enabled` to set the domain's enable flag to a known value. `toggleEnable` flips that flag without reporting the result — the API returns an undescribed body — so prefer `update` when you need a deterministic end state.\n\n### `dokploy_redirects` (4 actions)\n\nActions: `create | update | remove | get`\n\nURL redirect rules on an application, expressed as Traefik regex/replacement pairs. `create` requires `regex` + `replacement` + `permanent` + `applicationId`. `update` requires `redirectId` + the rule fields. `remove`/`get` require `redirectId`. Changes take effect only after the application is redeployed.\n\n### `dokploy_environment` (6 actions)\n\nActions: `create | get | list | update | remove | duplicate`\n\nProject environment management. `create` requires `projectId` + `name`. `list` requires `projectId`.\n\n### `dokploy_server` (8 actions)\n\nActions: `list | get | create | update | remove | count | publicIp | getMetrics`\n\nServer management. `create` requires `name` + `ipAddress` + `port` + `username` + `sshKeyId` + `serverType` (`deploy | build`). `getMetrics` requires `url` + `token`.\n\n### `dokploy_backup` (6 actions)\n\nActions: `create | get | update | remove | listFiles | manualBackup`\n\nBackup scheduling and triggers. `create` requires `schedule` + `prefix` + `destinationId` + `database` + `databaseType`. Provide the **one** service id matching the engine:\n\n- `databaseType: postgres` → `postgresId`\n- `databaseType: mysql` → `mysqlId`\n- `databaseType: mariadb` → `mariadbId`\n- `databaseType: mongo` → `mongoId`\n- `databaseType: libsql` → `libsqlId`\n- `databaseType: web-server` → no service id (backs up the Dokploy server itself)\n- Backing up a DB inside a compose stack → `composeId` + `serviceName` + the engine as `databaseType`\n\n`create` and `update` also accept `includeEncryptionKey`, which stores the database encryption key alongside the backup.\n\n`manualBackup` requires `backupId` + `backupType`:\n\n- `postgres | mysql | mariadb | mongo | libsql` — individual DB backups\n- `compose` — whole-stack backup\n- `webServer` — Dokploy server backup\n\n### `dokploy_volume_backup` (6 actions)\n\nActions: `create | update | remove | get | list | runManually`\n\nScheduled volume-level backups, taken with rclone. Distinct from `dokploy_backup`, which takes DB-native dumps.\n\n`create` requires `name` + `volumeName` + `prefix` + `cronExpression` + `destinationId`, and accepts `serviceType` with the matching `*Id`, plus `appName`, `keepLatestCount`, `enabled`, and `turnOff` (stops the service for the backup window). `volumeName` must match `^[a-zA-Z0-9][a-zA-Z0-9_.-]*$` — it is validated before the request is sent. `update` takes `volumeBackupId` plus the same fields. `remove`/`get` take `volumeBackupId`. `list` requires `id` (the parent service id) + `volumeBackupType`. `runManually` triggers a backup immediately from `volumeBackupId`.\n\n### `dokploy_deployment` (5 actions)\n\nActions: `list | queueList | killProcess | readLogs | remove`\n\nDeployment tracking. `list` requires `applicationId`|`composeId`|`serverId`|`type`+`id`. `type` enum: `application | compose | server | schedule | previewDeployment | backup | volumeBackup` (database deployments are listed via the database resource itself, not this endpoint). `queueList` requires `applicationId`. `killProcess` requires `deploymentId`. `readLogs` reads a single deployment's log file. `remove` deletes a deployment record.\n\n### `dokploy_preview_deployment` (4 actions)\n\nActions: `list | get | remove | redeploy`\n\nPer-PR and per-branch preview deploys hanging off a parent application. `list` requires `applicationId`. `get`/`remove`/`redeploy` require `previewDeploymentId`; `redeploy` optionally takes `title` and `description` for the deploy record.\n\n### `dokploy_schedule` (6 actions)\n\nActions: `create | update | remove | get | list | runManually`\n\nCron schedules that run commands against an application, a compose service, a server, or the Dokploy server itself. `create` requires `name` + `cronExpression` + `command`, plus `scheduleType` and its matching id; it also accepts `shellType` (`bash | sh`), `script` for multi-line commands, and `timezone`. `list` requires `id` (the parent id, or `dokploy-server`) + `scheduleType`. `runManually` fires a schedule immediately from `scheduleId`.\n\n`scheduleType`: `application | compose | server | dokploy-server`.\n\n### `dokploy_docker` (17 actions)\n\nActions: `getContainers | restartContainer | startContainer | stopContainer | killContainer | removeContainer | getConfig | findContainers | listContainerFiles | readContainerFile | writeContainerFile | deleteContainerFile | getEvents | getServerHealth | getDiskUsage | getBuildCache | pruneBuildCache`\n\nDocker daemon management. Every action accepts an optional `serverId` to target a remote server.\n\n**Containers.** The lifecycle actions (`restart`/`start`/`stop`/`kill`/`removeContainer`) and `getConfig` take `containerId`. `findContainers` requires `appName` + `method` (`match | label | stack | service`). For `method=match`, `appType` accepts `stack | docker-compose`. For `method=label`, `type` is **required** and accepts `standalone | swarm` (the API rejects without it).\n\n**Container files.** `listContainerFiles`, `readContainerFile`, `writeContainerFile`, and `deleteContainerFile` take `containerId` + `path` (absolute, inside the container); `writeContainerFile` also takes `content`. `readContainerFile` truncates its output at 100,000 characters. `writeContainerFile` writes into the **running** container — the change is lost on redeploy unless the path lives on a mount.\n\n**Observability.** `getEvents` takes `minutes` (1–1440, default 15). `getServerHealth` takes `sinceHours` (1–168).\n\n**Disk.** `getDiskUsage` is `docker system df` — it covers containers, volumes, images, and build cache, so start here when hunting space. `getBuildCache` details the cache; `pruneBuildCache` clears it (the same effect as `dokploy_settings` `clean` with `cleanType=dockerBuilder`).\n\n### `dokploy_docker_volume` (8 actions)\n\nActions: `getVolumes | getVolumesSize | getVolumeConfig | removeVolume | listVolumeFiles | readVolumeFile | writeVolumeFile | deleteVolumeFile`\n\nDocker volume management and volume file access. Every action accepts an optional `serverId`. `getVolumeConfig` and `removeVolume` take `volumeName`; the file actions take `volumeName` + `path`, and `writeVolumeFile` also takes `content`. `readVolumeFile` truncates at 100,000 characters. `removeVolume` destroys the volume's data — take a `dokploy_volume_backup` first. Unlike a write into a running container, a volume write survives redeploys.\n\n### `dokploy_docker_image` (3 actions)\n\nActions: `getImages | getImageConfig | removeImage`\n\nDocker image inventory. `getImageConfig` takes `imageRef` (`nginx:latest` or an image ID). `removeImage` requires **all three** of `repository`, `tag`, and `id` — read them off `getImages` — plus optional `force`. Disk usage and build cache live in `dokploy_docker` (`getDiskUsage`, `getBuildCache`, `pruneBuildCache`).\n\n### `dokploy_network` (8 actions)\n\nActions: `list | get | create | remove | recreate | inspect | import | networksToSync`\n\nDocker network management. `create` requires `name` and accepts `driver` (`bridge | overlay`), `internal`, `attachable`, `enableIPv4`, `enableIPv6`, `mtu` (68–65535), `ipam`, and `serverId`. `get`, `inspect`, `remove`, and `recreate` take `networkId` — `recreate` drops and re-adds the network, so attached services are briefly disconnected. `networksToSync` lists networks that exist on the Docker host but are not yet tracked by Dokploy; `import` brings them in by `names`. Attach networks to workloads via `dokploy_application` `update` `networkIds`, or `dokploy_compose` `update` `serviceNetworks`.\n\n### `dokploy_overview` (3 actions)\n\nActions: `services | backups | domains`\n\nRead-only rollups spanning every project — no parameters. Use these to orient before drilling in: `services` lists every application, compose service, and database with its status; `backups` every configured backup and schedule; `domains` every domain and what it points at. Dokploy's OpenAPI spec does not describe these response bodies, so the tool renders them as JSON.\n\n**Prefer this over `search` for inventory.** Dokploy's search index is narrower than the project tree — on a test instance holding 1 application and 14 compose services, `application.search` reported 0 matches and `compose.search` reported 5. The `search` actions on `dokploy_application`, `dokploy_compose`, and `dokploy_database` are for finding a service you already know exists; `dokploy_overview` and `dokploy_project` are for enumerating what is there.\n\n### `dokploy_infrastructure` (8 actions)\n\nActions: `createPort | deletePort | createAuth | deleteAuth | listCerts | getCert | createCert | removeCert`\n\nPorts, basic auth, and SSL certificates.\n\n### `dokploy_mounts` (6 actions)\n\nActions: `create | update | remove | get | listByServiceId | allNamedByApplicationId`\n\nVolumes, bind mounts, and file mounts attached to a service. `create` requires `type` + `mountPath` + `serviceId` + `serviceType`, then one field per type: `volumeName` for a volume, `hostPath` for a bind, `filePath` + `content` for a file. `update` takes `mountId` plus any field. `remove`/`get` take `mountId`. `listByServiceId` requires `serviceType` + `serviceId`. `allNamedByApplicationId` lists named volumes for an `applicationId`.\n\n`serviceType`: `application | postgres | mysql | mariadb | mongo | redis | compose | libsql`.\n\nMount changes require a redeploy of the parent service to take effect.\n\n### `dokploy_ssh_key` (6 actions)\n\nActions: `create | list | get | update | remove | generate`\n\nSSH key management for git-based deployments. `create` requires `name` + `privateKey` + `publicKey` + `organizationId`. `get` requires `sshKeyId`. `update` requires `sshKeyId`, optional `name`, `description`, `lastUsedAt`. `remove` requires `sshKeyId`. `generate` uses `type` (rsa|ed25519).\n\n### `dokploy_registry` (7 actions)\n\nActions: `list | get | create | update | remove | test | testById`\n\nContainer registries for pulling private images. `create` requires `registryName` + `username` + `password` + `registryUrl`; `registryType` defaults to `cloud`. `get`/`remove` require `registryId`, `update` takes `registryId` + fields. `test` checks credentials without persisting them; `testById` tests a saved registry by `registryId`, optionally against a `serverId`.\n\n### `dokploy_destination` (6 actions)\n\nActions: `list | get | create | update | remove | test`\n\nS3-compatible destinations that backups are written to. `create` requires `name` + `accessKey` + `bucket` + `region` + `endpoint` + `secretAccessKey`, and accepts `provider` and `additionalFlags` (passed to rclone). `get`/`remove` require `destinationId`, `update` takes `destinationId` + fields. `test` validates the same fields as `create` without saving.\n\n### `dokploy_audit_log` (1 action)\n\nActions: `list`\n\nQuery the Dokploy audit trail. Every filter is optional: `userId`, `userEmail`, `resourceName`, `auditAction`, `resourceType`, `from`/`to` (ISO timestamps), `limit` (default 50, max 500), and `offset`.\n\n`auditAction`: `create | update | delete | deploy | cancel | redeploy | login | logout`.\n\n`resourceType`: `project | service | environment | deployment | user | customRole | domain | certificate | registry | server | sshKey | gitProvider | notification | settings | session`.\n\nThe wire-level query parameter is named `action`; this tool exposes it as `auditAction` so it does not collide with the `action` discriminator every tool uses.\n\n### `dokploy_dns_provider` (11 actions)\n\nActions: `list | get | create | update | remove | testConnection | listZones | listRecords | createRecord | updateRecord | deleteRecord`\n\nDNS provider credentials plus zone and record management. `config` is discriminated on `providerType`: `cloudflare` (`apiToken`) or `route53` (`accessKeyId`, `secretAccessKey`). `update` requires `dnsProviderId` + `name` + `config` — the API **replaces** the provider rather than patching it, so a rename means re-sending the credentials. `testConnection` takes either a saved `dnsProviderId` or a raw `config` to check credentials before saving.\n\nRecords: `listZones` (`dnsProviderId`), `listRecords` (`+ zoneId`), `createRecord`/`updateRecord` (`+ type`, `recordName`, `content`, optional `ttl`, plus `recordId` for update), `deleteRecord` (`+ recordId`). `type` accepts `A` or `CNAME` only. Note `recordName` is the DNS record name — it maps to the API's `name` field, kept distinct here from the provider's `name`.\n\nProvider reads return id, name, and `providerType` only; stored credentials are never rendered into tool output.\n\n### `dokploy_vault_provider` (7 actions)\n\nActions: `list | get | create | update | remove | testConnection | listSecretNames`\n\nExternal secret-manager configuration. `config` is discriminated on `providerType` across six backends: `hashicorp`, `infisical`, `aws`, `doppler`, `azure`, `scaleway`. `assignments` is `[{ projectId, environmentIds? }]` naming the Dokploy projects the vault serves.\n\nWatch the overloaded field name: `infisical.projectId` and `scaleway.projectId` are that provider's own project ID, **not** the Dokploy `projectId` used in `assignments`.\n\n`update` requires all four of `vaultProviderId`, `name`, `config`, and `assignments` — like the DNS provider, the API replaces rather than patches, so run `get` first to recover the current name and assignments.\n\n`listSecretNames` (`vaultProviderId` + `projectId`, optional `environmentId`) returns secret **names only**. Dokploy exposes no API to read a secret's value, and provider credentials are never echoed back — the same rule the env tools follow.\n\n### `dokploy_settings` (5 actions)\n\nActions: `health | version | ip | clean | reload`\n\nSystem settings. `clean` uses `cleanType` — server-scoped: `all | images | volumes | stoppedContainers | dockerBuilder | dockerPrune` (honor `serverId`); global: `monitoring | deploymentQueue | sshPrivateKey`. `reload` uses `reloadTarget` (`server | traefik`); `serverId` is honored for `traefik`.\n\n## Usage Examples\n\n### Deploy an application\n\n```\n\"Deploy my web app\" → dokploy_application { action: \"deploy\", applicationId: \"app-123\" }\n```\n\n### Start a PostgreSQL database\n\n```\n\"Start the postgres database\" → dokploy_database { action: \"start\", dbType: \"postgres\", databaseId: \"db-456\" }\n```\n\n### Check system health\n\n```\n\"Is Dokploy healthy?\" → dokploy_settings { action: \"health\" }\n```\n\n### List all containers\n\n```\n\"What containers are running?\" → dokploy_docker { action: \"getContainers\" }\n```\n\n## Development\n\n```bash\npnpm install\npnpm dev          # Development mode with watch\npnpm validate     # Format + lint + test + build\npnpm inspect      # Open MCP Inspector\n```\n\n## License\n\nMIT\n\n---\n\n**Sponsored by <a href=\"https://sapientsai.com/\"><img src=\"https://sapientsai.com/images/logo.svg\" alt=\"SapientsAI\" width=\"20\" style=\"vertical-align: middle;\"> SapientsAI</a>** — Building agentic AI for businesses\n",
  "bytes": 28618,
  "sha": "9561f6ea8183a6396b1dcb1a919749be461f556955a80dfdbc0f6718ac6c38b2",
  "repo_slug": "sapientsai/dokploy-mcp-server",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_io_github_sapientsai_dokploy_mcp_server_95e29523/readme"
}