Coolify Creation MCP

Overview Schema Source Related Servers Discussions Admin

create_dockerfile_application

Creates an inline Dockerfile application via Coolify API, returning its UUID and authenticated deploy webhook without deploying.

Instructions

Create one inline Dockerfile application using Coolify's API. Requires read and write token permissions. Returns UUID and authenticated deploy webhook. Does not deploy. Git automatic deployment is disabled. On uncertain failure inspect inventory before retrying.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_uuid": "<project_uuid>",
      "server_uuid": "<server_uuid>",
      "environment_uuid": "<environment_uuid>",
      "name": "<name>",
      "dockerfile": "<dockerfile>"
    },
    "name": "create_dockerfile_application"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes
`domains`	No
`redirect`	No		both
`dockerfile`	Yes	Plain UTF-8 Dockerfile content; the server base64-encodes it for Coolify.
`server_uuid`	Yes
`project_uuid`	Yes
`ports_exposes`	No		80
`destination_uuid`	No
`environment_uuid`	Yes
`autogenerate_domain`	No
`health_check_enabled`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 29, 2026

TDQS

B3.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations by stating the auth requirement (read+write token), that no deployment occurs, that git automatic deployment is disabled, and that the caller should inspect inventory before retrying an uncertain failure. It stops short of stating name-uniqueness or what a duplicate create produces, so not a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Six short, front-loaded sentences with no filler; the create action and its constraints come first. Slightly list-like but every sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the mutation's side effects and return payload (UUID plus deploy webhook), which compensates for the missing output schema. However, with 11 mostly undocumented parameters and no output schema, a caller still lacks guidance on the optional configuration surface.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 9% across 11 parameters, so the description carries the burden — but it says nothing about domains, redirect, ports_exposes, autogenerate_domain, health_check_enabled, or destination_uuid. The one documented parameter (dockerfile) is documented in the schema, not here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Create one inline Dockerfile application using Coolify's API.' The word 'inline' distinguishes it from create_docker_image_application and create_public_repository_application, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides some operating context (token permissions required, does not deploy, git auto-deploy disabled), but never says when to choose this over plan_dockerfile_application or the other create_* siblings. Usage is implied rather than routed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server