coolify-mcp operates a self-hosted Coolify instance through its REST API: applications, databases, services, servers, projects, environments, deployments and their configuration.

Related operations share one tool with an `action` argument, and each tool's `action` enum is the complete list of what it accepts. `list_*` tools return small projections (uuid, name, status); `get_*` tools return one resource in full. `diagnose_app` accepts a uuid, a name or a domain, and `diagnose_server` a uuid, a name or an IP address, so neither needs a lookup call first. Some results carry `_actions`, follow-up calls that apply to that result with their arguments already filled in, and `_pagination` with the next and previous page; both are computed by the server from the real response.

`get_infrastructure_overview` summarises the whole estate in one call, `find_issues` scans it for anything unhealthy, and `diagnose_app` or `diagnose_server` explains one resource. `search_docs` searches the Coolify documentation.

Secrets are masked in every response. `get_application`, `get_database` and `get_service` accept `reveal: true` to return one resource's credentials in plaintext; `env_vars` with `reveal: true` requires a `key` and returns that one variable.

Tools annotated read-only make no change to the instance. Destructive actions (delete, stop, restart, bulk operations) ask the person for confirmation in clients that support elicitation; a declined confirmation returns a message, not an error, and the operation does not run. In a client without elicitation they run unconfirmed.

Tested against Coolify 4.0.x – 4.3.x. Tags, destinations and service sub-resource actions need 4.2 or later; the GET-to-POST change in 4.2 is handled by the server, so a 405, or a 404 on an older instance, means both methods were refused. `get_version` reports the Coolify version and `get_mcp_version` this server's.
