io.github.jordanburke/dokploy-mcp-server
Dokploy MCP server: manage apps, Docker Compose, databases, domains, backups, and servers.
Open source Open in the app JSON README (API)
About
Dokploy MCP server: manage apps, Docker Compose, databases, domains, backups, and servers.
Details
- Kind
- MCP servers
- Topic
- Cloud & DevOps
- Publisher
- jordanburke
- Origin
- official
- Category
- ferramentas
- Transport
- local
- Version
- 1.6.2
- Stars
- 2
- Forks
- 1
- Open pull requests
- 3
- Last push
- 2026-09-02T10:07:31Z
- Repository state
- ativo
- Language
- TypeScript
- License
- MIT
- Added
- 2026-08-29 04:00:17
- Updated
- 2026-08-29 04:00:17
- Origin id
io.github.jordanburke/dokploy-mcp-server
README
# dokploy-mcp-server
[](https://www.npmjs.com/package/dokploy-mcp-server)
A 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.
## Why This Server?
The [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.
This 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.
### Context cost
| | Official `@dokploy/mcp` | This server |
| ---------------------------------- | ----------------------- | ---------------- |
| Tools exposed | 546 | 22 (21 + `info`) |
| `tools/list` schema payload | 294,957 bytes | 34,528 bytes |
| Approximate tokens loaded up front | **~74k** | **~8.6k** |
| Median tool schema | 388 bytes | 1,131 bytes |
Measured 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).
Since 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.
On 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`.
### Feature Comparison
Tool counts for the official server are per category, taken from its live `tools/list`.
| Category | Official MCP | This Server |
| ------------------- | ---------------------- | ----------------------------- |
| Projects | 9 tools | 1 tool (6 actions) |
| Applications | 31 tools | 1 tool (23 actions) |
| Compose | 31 tools | 1 tool (21 actions) |
| Deployments | 9 tools | 1 tool (5 actions) |
| Docker | 12 tools | 1 tool (17 actions) |
| Docker Volumes | n/a (new in 0.30.2) | 1 tool (8 actions) |
| Docker Images | n/a (new in 0.30.2) | 1 tool (3 actions) |
| Networks | n/a (new in 0.30.2) | 1 tool (8 actions) |
| Overview | n/a (new in 0.30.2) | 1 tool (3 actions) |
| DNS Providers | n/a (new in 0.30.2) | 1 tool (11 actions) |
| Vault Providers | n/a (new in 0.30.2) | 1 tool (7 actions) |
| Domains | 9 tools | 1 tool (9 actions) |
| Redirects | 4 tools | 1 tool (4 actions) |
| Servers | 18 tools | 1 tool (8 actions) |
| Settings | 54 tools | 1 tool (5 actions) |
| Databases | 94 tools (6 engines) | 1 tool (17 actions, all 6 DB) |
| Backups | 12 tools | 1 tool (6 actions) |
| Volume Backups | 6 tools | 1 tool (6 actions) |
| Preview Deployments | 4 tools | 1 tool (4 actions) |
| Schedules | 6 tools | 1 tool (6 actions) |
| Audit Log | 1 tool | 1 tool (1 action) |
| Environments | 7 tools | 1 tool (6 actions) |
| Infrastructure | 13 tools (ports+certs) | 1 tool (8 actions) |
| Mounts | 6 tools | 1 tool (6 actions) |
| SSH Keys | 7 tools | 1 tool (6 actions) |
| Registries | 7 tools | 1 tool (7 actions) |
| Destinations | 6 tools | 1 tool (6 actions) |
| **Total** | **346 tools** | **27 tools** |
Key advantages:
- **Minimal token usage** - 346 endpoints' worth of surface in 27 tools, for roughly an eighth of the context
- **Unified database tool** - One tool handles all 6 database types (postgres, mysql, mariadb, mongo, redis, libsql) via `dbType` + `action` params
- **Curated descriptions** - Each tool documents which parameters pair with which action, so calls succeed on the first try
- **Action-based design** - Each tool has an `action` enum parameter; other params are optional based on action
### When to use the official server instead
The 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:
- **Notifications** (41 tools) - email, Slack, Discord, Telegram, Gotify webhooks
- **Users, organizations, roles, SSO** (64 tools) - user management, organizations, custom roles, SSO, SCIM, forwardAuth
- **Git providers** (32 tools) - GitHub, GitLab, Gitea, Bitbucket app configuration
- **AI providers** (14 tools) - Dokploy's own LLM integration for log analysis and compose generation
- **Cluster and Swarm** (8 tools), **patch** (12), **tags** (8), **rollback** (2), **admin** (1)
- **Dokploy Cloud commercial features** (18 tools) - Stripe billing, license keys, whitelabeling
If your workflow needs any of those, use the official server, or run both.
## Installation
### Claude Desktop / Claude Code
Add to your MCP configuration:
```json
{
"mcpServers": {
"dokploy": {
"command": "npx",
"args": ["-y", "dokploy-mcp-server"],
"env": {
"DOKPLOY_URL": "https://dokploy.example.com",
"DOKPLOY_API_KEY": "your-api-key"
}
}
}
}
```
### Cursor
Add to `.cursor/mcp.json`:
```json
{
"mcpServers": {
"dokploy": {
"command": "npx",
"args": ["-y", "dokploy-mcp-server"],
"env": {
"DOKPLOY_URL": "https://dokploy.example.com",
"DOKPLOY_API_KEY": "your-api-key"
}
}
}
}
```
### Docker
```bash
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
```
## Environment Variables
| Variable | Required | Default | Description |
| ----------------- | -------- | --------- | ---------------------------------------- |
| `DOKPLOY_URL` | Yes | - | Your Dokploy instance URL |
| `DOKPLOY_API_KEY` | Yes | - | API key from Dokploy Settings > API Keys |
| `TRANSPORT_TYPE` | No | `stdio` | Transport mode: `stdio` or `httpStream` |
| `PORT` | No | `3000` | HTTP port (httpStream mode only) |
| `HOST` | No | `0.0.0.0` | HTTP host (httpStream mode only) |
## Tools (27)
Each tool uses an `action` enum to select the operation. Parameters are optional and used based on the chosen action.
### `dokploy_project` (6 actions)
Actions: `list | get | create | update | remove | duplicate`
Manage 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`.
**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.
### `dokploy_application` (23 actions)
Actions: `create | get | update | move | deploy | start | stop | delete | markRunning | refreshToken | cleanQueues | killBuild | cancelDeployment | reload | saveEnvironment | setEnvVars | getEnvKeys | getEnvValuesUnsafe | saveBuildType | traefikConfig | readMonitoring | readLogs | search`
Full 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.
**Env handling.** `get` returns a masked env summary (count only) — never the values. Three actions cover the rest:
- `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.
- `getEnvKeys` — returns KEY names only, sorted. Safe to read.
- `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.
- `saveEnvironment` — full-replace, kept for explicit blob-set workflows.
`sourceType`:
- `github` → `repository` + `owner` + `branch` (+ `githubId` for private)
- `git` → `customGitUrl` + `customGitBranch`
- `docker` → `dockerImage`
`buildType`: `dockerfile | heroku_buildpacks | paketo_buildpacks | nixpacks | static | railpack`.
The underlying API also supports `gitlab`/`bitbucket`/`gitea`/`drop` sources, but those need provider-specific fields not yet exposed by this tool.
### `dokploy_compose` (21 actions)
Actions: `create | get | update | delete | deploy | start | stop | move | loadServices | loadMounts | getDefaultCommand | cancelDeployment | cleanQueues | killBuild | refreshToken | saveEnvironment | setEnvVars | getEnvKeys | getEnvValuesUnsafe | readLogs | search`
Docker 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`.
**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.
`sourceType`:
- `github` → `repository` + `owner` + `branch` (+ `composePath`)
- `git` → `customGitUrl` + `customGitBranch` (+ `customGitSSHKeyId` for private)
- `raw` → `composeFile` (inline YAML)
The underlying API also supports `gitlab`/`bitbucket`/`gitea` sources, but those need provider-specific fields not yet exposed by this tool.
### `dokploy_database` (17 actions)
Actions: `create | get | update | move | start | stop | deploy | rebuild | remove | reload | changeStatus | saveEnvironment | setEnvVars | getEnvKeys | getEnvValuesUnsafe | saveExternalPort | search`
Unified database management. All actions require `dbType` (`postgres | mysql | mariadb | mongo | redis | libsql`); most also require `databaseId`. `create` baseline: `dbType` + `name` + `environmentId` + `databasePassword`.
**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.
Per-engine extras:
- `postgres` / `mysql` / `mariadb` — also require `databaseName` + `databaseUser`. `mysql`/`mariadb` accept `databaseRootPassword`.
- `mongo` — requires `databaseUser` (no `databaseName`).
- `redis` — only `databasePassword`.
- `libsql` — requires `appName` + `dockerImage` + `sqldNode` (`primary | replica`); accepts `sqldPrimaryUrl` + `enableNamespaces`.
`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`.
### `dokploy_domain` (9 actions)
Actions: `create | list | get | update | delete | toggleEnable | generate | canGenerateTraefikMe | validate`
Domain/DNS management. `create` requires `host` + `applicationId`|`composeId` (and `serviceName` for compose domains). Enums: `certificateType` (`letsencrypt | none | custom`), `domainType` (`compose | application | preview`). `validate` requires `domain`.
`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.
### `dokploy_redirects` (4 actions)
Actions: `create | update | remove | get`
URL 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.
### `dokploy_environment` (6 actions)
Actions: `create | get | list | update | remove | duplicate`
Project environment management. `create` requires `projectId` + `name`. `list` requires `projectId`.
### `dokploy_server` (8 actions)
Actions: `list | get | create | update | remove | count | publicIp | getMetrics`
Server management. `create` requires `name` + `ipAddress` + `port` + `username` + `sshKeyId` + `serverType` (`deploy | build`). `getMetrics` requires `url` + `token`.
### `dokploy_backup` (6 actions)
Actions: `create | get | update | remove | listFiles | manualBackup`
Backup scheduling and triggers. `create` requires `schedule` + `prefix` + `destinationId` + `database` + `databaseType`. Provide the **one** service id matching the engine:
- `databaseType: postgres` → `postgresId`
- `databaseType: mysql` → `mysqlId`
- `databaseType: mariadb` → `mariadbId`
- `databaseType: mongo` → `mongoId`
- `databaseType: libsql` → `libsqlId`
- `databaseType: web-server` → no service id (backs up the Dokploy server itself)
- Backing up a DB inside a compose stack → `composeId` + `serviceName` + the engine as `databaseType`
`create` and `update` also accept `includeEncryptionKey`, which stores the database encryption key alongside the backup.
`manualBackup` requires `backupId` + `backupType`:
- `postgres | mysql | mariadb | mongo | libsql` — individual DB backups
- `compose` — whole-stack backup
- `webServer` — Dokploy server backup
### `dokploy_volume_backup` (6 actions)
Actions: `create | update | remove | get | list | runManually`
Scheduled volume-level backups, taken with rclone. Distinct from `dokploy_backup`, which takes DB-native dumps.
`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`.
### `dokploy_deployment` (5 actions)
Actions: `list | queueList | killProcess | readLogs | remove`
Deployment 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.
### `dokploy_preview_deployment` (4 actions)
Actions: `list | get | remove | redeploy`
Per-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.
### `dokploy_schedule` (6 actions)
Actions: `create | update | remove | get | list | runManually`
Cron 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`.
`scheduleType`: `application | compose | server | dokploy-server`.
### `dokploy_docker` (17 actions)
Actions: `getContainers | restartContainer | startContainer | stopContainer | killContainer | removeContainer | getConfig | findContainers | listContainerFiles | readContainerFile | writeContainerFile | deleteContainerFile | getEvents | getServerHealth | getDiskUsage | getBuildCache | pruneBuildCache`
Docker daemon management. Every action accepts an optional `serverId` to target a remote server.
**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).
**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.
**Observability.** `getEvents` takes `minutes` (1–1440, default 15). `getServerHealth` takes `sinceHours` (1–168).
**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`).
### `dokploy_docker_volume` (8 actions)
Actions: `getVolumes | getVolumesSize | getVolumeConfig | removeVolume | listVolumeFiles | readVolumeFile | writeVolumeFile | deleteVolumeFile`
Docker 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.
### `dokploy_docker_image` (3 actions)
Actions: `getImages | getImageConfig | removeImage`
Docker 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`).
### `dokploy_network` (8 actions)
Actions: `list | get | create | remove | recreate | inspect | import | networksToSync`
Docker 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`.
### `dokploy_overview` (3 actions)
Actions: `services | backups | domains`
Read-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.
**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.
### `dokploy_infrastructure` (8 actions)
Actions: `createPort | deletePort | createAuth | deleteAuth | listCerts | getCert | createCert | removeCert`
Ports, basic auth, and SSL certificates.
### `dokploy_mounts` (6 actions)
Actions: `create | update | remove | get | listByServiceId | allNamedByApplicationId`
Volumes, 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`.
`serviceType`: `application | postgres | mysql | mariadb | mongo | redis | compose | libsql`.
Mount changes require a redeploy of the parent service to take effect.
### `dokploy_ssh_key` (6 actions)
Actions: `create | list | get | update | remove | generate`
SSH 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).
### `dokploy_registry` (7 actions)
Actions: `list | get | create | update | remove | test | testById`
Container 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`.
### `dokploy_destination` (6 actions)
Actions: `list | get | create | update | remove | test`
S3-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.
### `dokploy_audit_log` (1 action)
Actions: `list`
Query the Dokploy audit trail. Every filter is optional: `userId`, `userEmail`, `resourceName`, `auditAction`, `resourceType`, `from`/`to` (ISO timestamps), `limit` (default 50, max 500), and `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`.
The 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.
### `dokploy_dns_provider` (11 actions)
Actions: `list | get | create | update | remove | testConnection | listZones | listRecords | createRecord | updateRecord | deleteRecord`
DNS 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.
Records: `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`.
Provider reads return id, name, and `providerType` only; stored credentials are never rendered into tool output.
### `dokploy_vault_provider` (7 actions)
Actions: `list | get | create | update | remove | testConnection | listSecretNames`
External 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.
Watch the overloaded field name: `infisical.projectId` and `scaleway.projectId` are that provider's own project ID, **not** the Dokploy `projectId` used in `assignments`.
`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.
`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.
### `dokploy_settings` (5 actions)
Actions: `health | version | ip | clean | reload`
System 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`.
## Usage Examples
### Deploy an application
```
"Deploy my web app" → dokploy_application { action: "deploy", applicationId: "app-123" }
```
### Start a PostgreSQL database
```
"Start the postgres database" → dokploy_database { action: "start", dbType: "postgres", databaseId: "db-456" }
```
### Check system health
```
"Is Dokploy healthy?" → dokploy_settings { action: "health" }
```
### List all containers
```
"What containers are running?" → dokploy_docker { action: "getContainers" }
```
## Development
```bash
pnpm install
pnpm dev # Development mode with watch
pnpm validate # Format + lint + test + build
pnpm inspect # Open MCP Inspector
```
## License
MIT
---
**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