coolify-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| COOLIFY_URL | Yes | Instance URL, e.g. https://coolify.example.com. A trailing slash or /api/v1 is stripped; /api/v1 is added. | |
| COOLIFY_TOKEN | Yes | API token (sent as Authorization: Bearer). | |
| COOLIFY_READ_ONLY | No | 1 refuses every mutating tool. Dry runs are still allowed. | |
| COOLIFY_TIMEOUT_MS | No | Per-request timeout in ms. Default 30000. | 30000 |
| COOLIFY_ALLOW_REVEAL | No | 1 lets list_envs return plaintext when called with reveal: true. Off by default. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_versionA | Check connectivity: returns the Coolify version, the health endpoint result, the API base URL in use and whether this MCP server is read-only / allows revealing secrets. Call this first when other tools fail. |
| list_projectsA | List Coolify projects with their environments (e.g. production, staging). |
| list_serversA | List servers attached to Coolify with IP, reachability and proxy type. |
| list_applicationsA | List applications with name, uuid, domain(s) (fqdn), status (e.g. running:healthy, exited), git repo/branch, build pack, project and environment. Use |
| get_applicationA | Get one application's details (domains, status, git, build/start commands, ports, health check, limits, project/environment). Accepts a uuid, exact name, or a unique name/domain substring; errors with the candidates when ambiguous. Secrets (webhook secrets, basic-auth password, compose files) are never returned. |
| list_servicesA | List one-click / docker-compose services (name, uuid, type, status, project/environment). |
| list_databasesA | List standalone databases (name, uuid, type, status, public exposure, project/environment). Connection URLs and passwords are never returned. |
| list_envsA | List the environment variables of an application or service: key, uuid and flags (is_build_time, is_runtime, is_preview, is_literal, is_multiline, is_shown_once). Values are MASKED (short prefix + length, or "(empty)") so secrets stay out of the conversation. |
| set_envsA | Upsert one or many environment variables on an application or service in a single call: existing keys are updated, missing keys created, identical ones left alone. Returns per key created / updated / unchanged plus which fields changed — values are never echoed. Flags you omit keep their current value on update. For applications, the main and preview copies of a key are separate (use is_preview). Use dry_run to preview. Changes only take effect after restart_application / restart_service, or deploy for build-time variables. |
| delete_envA | Delete one environment variable from an application or service, by key. For applications, is_preview selects the preview copy (default: the main one). Use dry_run to check first. Takes effect after a restart/redeploy. |
| create_applicationA | Create a Coolify application from a git repository. Public repos by default; a private repo needs either |
| update_applicationA | Change a safe subset of an application's settings: name, description, domains, git_branch, build_pack, ports_exposes, publish_directory, base_directory, install/build/start commands, health_check_path. Only fields that actually differ are sent; returns each change as from -> to. Nothing else (secrets, limits, compose files) can be touched. Use |
| deployA | Queue a (re)deployment — rebuilds and restarts. Target either |
| restart_applicationA | Restart an application's containers without rebuilding (picks up runtime env var changes; build-time changes need deploy). Returns a deployment uuid to follow with get_deployment. |
| start_applicationB | Start (deploy) a stopped application. |
| stop_applicationA | Stop an application's containers (the site goes down until start_application or deploy). |
| restart_serviceA | Restart a service (all its containers), e.g. after changing its env vars. |
| list_deploymentsA | With |
| get_deploymentA | Status of one deployment plus the last |
| get_application_logsA | Last |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 20 tools
Tools are largely distinct by resource and action, with clear boundaries for get/list/create/update/restart/start/stop. Minor overlap exists between deploy and start_application (both trigger deployment) and between restart_application and deploy for applying changes, but descriptions clarify the intended use.
Nearly all tools follow a snake_case verb_noun pattern (get_, list_, create_, update_, set_, delete_, restart_, start_, stop_). Minor deviations: env vs envs across list_envs/set_envs/delete_env, and deploy is a verb without a noun.
20 tools is appropriate for a Coolify management server spanning applications, deployments, envs, services, databases, projects, and servers. It is slightly on the high side but each tool maps to a distinct operation rather than being redundant.
Core application lifecycle (create/update/start/stop/restart/logs), env management, and deployment tracking are covered. However delete_application is missing, and services/databases/projects/servers have only read or restart operations—no create/update/delete/get for services or databases, creating significant dead ends for full platform management.