# io.github.StuMason/coolify MCP Server 44 optimized tools for managing Coolify infrastructure, diagnostics, and docs search **Publisher claimed.** No tool list reported, and Pod has not connected to this server. ## Status Pod has not dialled io.github.StuMason/coolify yet, so everything on this page is what its publisher reported rather than what we observed. Registries describe servers; they do not connect to them. Until a check runs, treat the tool list below as a claim. ## Connect Published as `@masonator/coolify-mcp` on npm. Runs locally. ## Known issues **24 problems reported by people outside the maintainer team.** Issues filed by the project's own owners, members and collaborators are excluded — those are release checklists and internal refactors, not things that will go wrong for you. Showing 12. ### Most discussed ### Heads up: Coolify v4.2 breaks several client calls (405s + hidden secrets) # Heads up: Coolify v4.2 breaks several client calls (405s + hidden secrets) Coolify v4.2 was merged into `v4.x` on Jul 19, 2026 via [coollabsio/coolify#10872](https://github.com/coollabsio/coolify/pull/10872). It is not on the releases index page yet, so it is easy to miss. I went through `src/lib/coolify-client.ts` at `e8dfb4b` (current `main`, dated Jul 16) and found four areas that will break once users upgrade. Opening this as a heads up rather than a bug report, since nothing is broken t [Read the thread](https://github.com/StuMason/coolify-mcp/issues/292) · 2026-07-25 · closed · external user · 2 comments ### Ability to connect with multiple servers ### Problem or motivation Would love a settings screen where we could specify multiple coolify URL's and Api's ### Proposed solution Menu that allows us to CRUD coolify URL's and Keys, then have the LLM auto select the current repo's assigned Coolify server details. ### Alternatives considered The ability to manually select the coolify server we are currently working with [Read the thread](https://github.com/StuMason/coolify-mcp/issues/164) · 2026-04-27 · closed · external user · 4 comments ### bug: fqdn field not sent correctly to Coolify API (should be domains) ## Bug Description When creating or updating applications with a custom domain using the `fqdn` field, the domain setting is silently ignored by the Coolify API. ## Root Cause The Coolify API expects the field to be named `domains`, not `fqdn`. The following methods pass `fqdn` directly in the request body without mapping it: - `createApplicationPublic` - `createApplicationPrivateGH` - `createApplicationPrivateKey` - `updateApplication` ## Steps to Reproduce ```typescript await client.crea [Read the thread](https://github.com/StuMason/coolify-mcp/issues/126) · 2026-02-23 · closed · outside contributor · 3 comments ### `create` with `docker_compose_raw` param throws error ### What happened? Trying to create a service on my Coolify instance with a docker_compose_raw definition from inside of Claude Code returns `Error: messages.join is not a function` ``` ⏺ coolify - service (MCP)(action: "create", project_uuid: "replaced", server_uuid: "replaced", environment_name: "production", docker_compose_raw: "services:\n test:\n image: nginx") ⎿  Error: messages.join is not a function ``` ### Steps to reproduce Best as I can tell the service create tool hangs or [Read the thread](https://github.com/StuMason/coolify-mcp/issues/107) · 2026-01-30 · closed · external user · 2 comments ### Support fetching logs for specific services in docker-compose applications ### Problem or motivation Currently, application_logs only returns logs from one container when an application uses docker compose build pack with multiple services. There's no way to specify which service's logs to retrieve. Use case: For a docker-compose app with frontend and backend services, calling application_logs only returns one of the application logs. I need to access logs from other services too. ### Proposed solution Add an optional service parameter to application_logs: { [Read the thread](https://github.com/StuMason/coolify-mcp/issues/92) · 2026-01-18 · closed · external user · 2 comments ### Most recent ### Three Coolify API parameters not exposed: destination_uuid on service create, public port on existing databases, connect_to_docker_network First, thanks for this server. I spent a full day driving a Coolify instance through it and the tool design held up well, `service`, `env_vars`, `deploy` and `scheduled_tasks run_once` in particular. I hit three gaps where the Coolify API supports a parameter that the MCP does not expose, and each one forced me out of the MCP and into the browser or the CLI. Version tested: **2.19.3**, Coolify **4.3.9** self-hosted. ### 1. `service create` cannot set `destination_uuid` On a server with more t [Read the thread](https://github.com/StuMason/coolify-mcp/issues/351) · 2026-08-21 · open · external user · 1 comment ### Include whether an env variable is "preview" type or not ### Problem or motivation It seems that the mcp doesn't let the llm know whether a variable is a preview type or not, which confuses it a lot, since it will think that variables are set wrong, then it corrects, often the wrong one, and gets really confused 😅 ### Proposed solution Add information about what type of env variable a variable is. I'm not sure on the setting of variables, but I assume you'd need to be able to distinguish what you are setting as well :) ### Alternatives considered [Read the thread](https://github.com/StuMason/coolify-mcp/issues/291) · 2026-07-23 · closed · external user · 1 comment ### env_vars list ignores the key parameter — reveal=true dumps every secret on the resource ## What happens The `env_vars` tool schema accepts `key` on every action, so an MCP client (LLM) that wants a single value naturally calls: ```json { "resource": "application", "action": "list", "uuid": "", "key": "MY_FLAG", "reveal": true } ``` But the three `list` branches in `src/lib/mcp-server.ts` never use `key` — they always return the **full** env list. With `reveal: true` that means asking "what is MY_FLAG set to?" returns every variable on the resource in plaintext (API keys, D [Read the thread](https://github.com/StuMason/coolify-mcp/issues/271) · 2026-07-14 · closed · outside contributor · 1 comment ### README contains a hidden HTML comment addressed to AI agents ("prompt injection") While reviewing this MCP server before installing it, I noticed the README (main branch) contains an HTML comment that isn't meant for human readers but is explicitly addressed to AI coding agents that read the raw file: ```html