Available MCP Tools
Free Tier
| Tool | Description |
|---|---|
list_containers | List containers with status, filterable by state |
get_container | Detail for one container by name/ID |
get_container_logs | Fetch recent log lines |
list_images | List container images |
list_volumes | List volumes |
list_networks | List networks |
list_deploy_apps | List Paste & Deploy apps + their last deploy status |
list_git_deploy_apps | List Git Deployment apps + their last deploy status |
list_git_providers | List connected Git providers (GitHub App, GitLab/Bitbucket/Gitea tokens) — connect new ones from Settings → Git Providers in the web UI, not via MCP |
list_provider_repos | List the repositories a connected provider can deploy (owner/repo, default branch, private flag) — the picker step before create_deploy_app |
create_deploy_app | Create a new Git Deployment app — from a connected provider (git_provider_id + repo_full_name) or a raw repo_url (returns an SSH deploy key to add to the repo) |
trigger_deploy_app | Trigger a deploy for an existing Git Deployment app by name |
delete_deploy_app | Permanently delete a Git Deployment app (stack, images, build history, deploy key) |
add_domain | Point a custom domain at a Git Deployment app's service (Traefik + Let's Encrypt, or a local certificate for .test/.local) |
get_system_info | Host CPU/RAM/disk info |
list_databases | List provisioned databases (Postgres/MySQL/Redis/MongoDB/ClickHouse/DragonflyDB) with connection info |
create_database | Provision a new database container |
start_database | Start a stopped database container |
stop_database | Stop a running database container (data on its volume is preserved) |
delete_database | Permanently delete a database container |
link_database_to_app | Connect a provisioned database to a Git Deployment app over container networking and inject connection env vars |
unlink_database_from_app | Disconnect a database from a Git Deployment app and remove its injected env vars |
None of the tools above are Pro-gated — they answer to the same limits the web UI already enforces, not a separate MCP-specific counter or ceiling. On Free that means unlimited deploy apps and unlimited provisioned databases, with database types being the actual limit: Postgres, MySQL, and Redis, while MongoDB, ClickHouse, and DragonflyDB need Pro (see Pricing). add_domain adds no cap of its own.
add_domain auto-detects local-only domains (.test, .local, .localhost, .example, .invalid — IANA-reserved TLDs that can never resolve publicly) and issues them a certificate from DockPod's own local certificate authority instead of attempting Let's Encrypt, which would just fail (see Custom Domains for how this works and how to trust the CA). No ACME email is needed for these. Any other domain still needs an ACME email configured under Settings → General → Reverse Proxy first; without one it returns an error explaining that instead of creating a domain that could never get a certificate — unless skip_tls is set, which routes over plain HTTP with no certificate at all (local or otherwise).
The tool accepts a hostname only and applies the same normalization, format checks, and global collision detection as the web UI. Protocols, paths, ports, wildcards, underscores, raw IP addresses, trailing dots, and hostnames already owned by any other DockPod resource are rejected.
Pass redirect_www: true to also add a redirect-only router for the domain's www/non-www counterpart, permanently redirecting it to the domain you passed — see Custom Domains for how the counterpart host is derived.
create_deploy_app points at a repo one of two ways. If a Git provider is already connected, the recommended flow is: list_git_providers → list_provider_repos for the connected provider → match the user's repo against the returned full_name → create_deploy_app with git_provider_id + repo_full_name. That path derives the clone URL server-side, clones over the provider's own credentials (so private repos work with no key handling), and skips the deploy key entirely — and for a GitHub App provider, push-to-deploy is live immediately with no webhook step. Only when no provider is connected does it fall back to a raw repo_url, which returns the SSH deploy key to add to the repo as a read-only Deploy Key before the first deploy of a private repo.
For a token provider (GitLab/Bitbucket/Gitea), the per-app push webhook is registered automatically at creation — but that needs a publicly reachable panel URL. If none is configured (Settings → General panel domain, or Settings → Git Providers), the app is still created and returns a warning that push-to-deploy won't fire until a public URL is set; trigger_deploy_app always works manually regardless.
create_deploy_app's branch has no default — it's a required parameter, so the AI is expected to ask which branch to deploy (e.g. main vs master) rather than silently guessing.
link_database_to_app/unlink_database_from_app exist because list_databases/create_database only return the host-facing 127.0.0.1:<port> connection string, which isn't reachable from inside a deployed app's own container. Linking connects the database's container to the app's dedicated network and injects <PREFIX>_HOST/_PORT/_NAME/_USER/_PASSWORD/_URL env vars using the database's container name instead — see Linking a Database.
Pro Tier — Actions
| Tool | Description |
|---|---|
start_container | Start a stopped container |
stop_container | Stop a running container |
restart_container | Restart a container |
pull_image | Pull a container image by reference |
trigger_deploy | Trigger a deploy for a named Paste & Deploy app |
rollback_deploy_app | Roll back a Git Deployment app to its previous successful build |
scale_deploy_app | Set the replica count (1-10) for an image-based Git Deployment app (Dockerfile/Nixpacks/Railpack — not compose) |
set_deploy_app_resources | Set the memory/CPU/pids limits for a Git Deployment app — image-based or compose, unlike scale_deploy_app |
set_deploy_app_service_resources | Override memory/CPU/pids for a single compose service, instead of the one shared value set_deploy_app_resources applies to every service |
run_exec | Run a restricted command inside a container |
scale_deploy_app only applies to image-based deploy modes — compose apps define their own service topology and aren't scaled this way. If the app is already running, replicas are added/removed live with no rebuild; otherwise the new count takes effect on the next deploy. Traefik round-robins across replicas automatically, no extra configuration needed.
set_deploy_app_resources works for both deploy modes. Pass memory_mb (required, 128–16384, or 0 to reset to the default 512MB), and optionally cpu_limit_m (millicores, 1000 = 1 vCPU, 100–16000, or 0/omitted to reset to the default 1 vCPU) and pids_limit (64–8192, or 0/omitted to reset to the default 512). For a compose app, this is the default every service falls back to, not necessarily what each one ends up with — see set_deploy_app_service_resources below. If the app is running, the new limits are applied live via the Docker API — no rebuild or restart; otherwise they apply on the next deploy.
set_deploy_app_service_resources (compose apps only) takes the same memory_mb/cpu_limit_m/pids_limit fields plus a required service_name, and overrides just that one service. Any field left at 0/omitted inherits set_deploy_app_resources' value instead of a hardcoded default — passing 0 for all three resets the service back to the app-wide default entirely. Same live-apply behavior as set_deploy_app_resources, scoped to that service's container(s).
Calling a Pro tool without a valid license returns a clear error explaining the tool requires an upgrade — the conversion prompt happens right inside the AI conversation, no need to switch to the web UI. These are genuinely Pro-only (no Free-tier equivalent at any count), unlike the plan-limited tools above.
Auth
MCP requests authenticate via Authorization: Bearer dp_mcp_... — an API key generated under Settings → API Keys, not your login session. Keys are bcrypt-hashed at rest; only the prefix is ever shown again after creation, so treat the full key like a password and store it somewhere safe when you generate it.
The same key also works as a Bearer token against the panel's own REST API (the one the web UI itself calls, on the main --addr port) — useful for a script, CI job, or IaC tool that isn't speaking MCP. Whichever surface it's used against, requests are attributed to the key's owner the same way (see Audit Trail below).
Audit Trail
Every key can be assigned to a specific team member at creation time (the "Assign to" picker, shown once more than one user exists). Tool calls made with that key show up in Settings → Team → Audit Log attributed to that person by username — so on a shared install, you know who actually told the AI to do what, not just that "the MCP server" did something. Keys created before this existed (or with no owner picked) attribute their calls to "Unknown" rather than erroring.