delete_application, delete_database and delete_service each accept delete_configurations, delete_connected_networks, delete_volumes and docker_cleanup, so the same call can leave the data behind or take it — a difference worth settling deliberately when an agent is holding the token. enable_api, disable_api, enable_mcp and disable_mcp reach further still: each requires a root-level token, and disabling the API turns off the interface everything else here depends on. health_check is the counterweight, stated to need no authentication at all, which makes it the safe probe for whether an instance is up.
A Coolify client with 111 tools covering teams and servers, projects and environments, applications, databases, services, deployments, environment variables, storages, scheduled tasks, SSH keys, GitHub Apps and cloud provider tokens.
- Applications from whichever source you have: create_public_application from a public Git repository, create_private_github_app_application, create_private_deploy_key_application, create_dockerfile_application, create_dockerimage_application and create_dockercompose_application.
- Databases as first-class objects, each with its own credential parameters: create_postgresql_database, create_mysql_database, create_mariadb_database, create_mongodb_database, create_redis_database, create_keydb_database, create_dragonfly_database and create_clickhouse_database.
- Runtime control: start, stop and restart tools for applications, databases and services alike, with get_application_logs for output.
- Environment variables per object type — list, create, update and delete for applications, databases and services, plus bulk_update_application_envs — with is_literal, is_multiline, is_preview and is_shown_once as flags.
- Deployments: list_deployments for what is running now, get_deployment, cancel_deployment, list_deployments_by_application with paging, and deploy_by_tag_or_uuid supporting force deploys and pull-request deployments.
- Servers: create_server, update_server with concurrent_builds, deployment_queue_limit and dynamic_timeout, validate_server for connectivity, get_server_resources and get_server_domains, plus create_hetzner_server, which provisions on Hetzner Cloud and registers the result in Coolify.
- Persistence and scheduling: application storages with a mount path and host path, database backups through create_database_backup with an S3 target and list_database_backup_executions, and scheduled tasks with a command, container, frequency and timeout for both applications and services.
- Credentials and integrations: private keys, GitHub Apps with list_github_app_repositories, and cloud provider tokens alongside the Hetzner reads get_hetzner_locations, get_hetzner_server_types, get_hetzner_images and get_hetzner_ssh_keys.
- Instance-level switches: enable_api and disable_api, and enable_mcp and disable_mcp for Coolify's own built-in MCP endpoint at /mcp — all four requiring a root-level token.
- Cheap reads: get_version for the version string, health_check, which the vendor states does not require authentication, and list_resources for everything across the instance.
A reachable Coolify instance and an API token for it, read from COOLIFY_API_URL, COOLIFY_API_TOKEN and COOLIFY_TEAM_ID. enable_api, disable_api, enable_mcp and disable_mcp each require a root-level token.
One command plus a key — npx coolify-mcp-server --yes, then supply credentials