How MCP works
Coolify exposes an MCP server at /mcp. An MCP-compatible client sends Streamable HTTP requests to that endpoint with a Coolify API token.
Connection flow
- Enable MCP for the Coolify instance in Settings > Advanced > API and MCP. This step is required on self-hosted instances. Coolify Cloud has it enabled.
- Keep MCP enabled for the team the token belongs to.
- Create an API token for that team.
- Configure the client with the endpoint and Bearer token.
- The client negotiates MCP capabilities and calls tools, reads resources, or uses prompts.
Authentication and scope
The client sends the complete token as a Bearer credential:
Authorization: Bearer 67|abcthisisa123dummytokenThe token is bound to one Coolify team. MCP only returns resources owned by that team. Create one token per team when a client needs access to multiple teams.
The instance MCP setting must be enabled before /mcp responds. Team admins and owners can disable MCP for individual teams. A disabled instance returns 404; a disabled team returns 403. On self-hosted instances, the Allowed IPs list in Settings > Advanced also applies to /mcp.
On self-hosted instances, Allowed IPs applies to MCP requests. The MCP server switch controls /mcp independently of REST API access.
MCP primitives
Tools perform Coolify queries and operations. Read tools need read. Deployment and lifecycle tools need deploy. Tools that create, update, or delete resources (create_* and manage_*) need write. MCP lists only the tools that the token's permissions allow. MCP capabilities groups tools by task.
Response boundaries
Coolify returns structured responses with data and may include _pagination, _actions, or failure details. Configuration snapshots and full deployment logs are not returned. Environment values are returned only by get_env_values, which needs read:sensitive and a team admin or owner. Log summaries are capped and best-effort redacted.