coolify-mcp

Create application from a git repository

create_application

Create a Coolify application from a Git repository, supporting public and private repos via GitHub App or deploy key, with optional immediate deployment.

Instructions

Create a Coolify application from a git repository. Public repos by default; a private repo needs either github_app (a GitHub App registered in Coolify) or private_key_uuid (a deploy key stored in Coolify: Keys & Tokens -> Private Keys). project and server accept a uuid or name (see list_projects / list_servers); server may be omitted when only one server can host apps. Nothing is built unless instant_deploy: true (needs the token's deploy permission). Use dry_run: true to see the exact request first. Returns the new application's uuid and next steps (set_envs, then deploy).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	No	Application name. Coolify defaults to a name derived from the repo and branch.
`server`	No	Server uuid or name. Default: the only server that can host applications; an error lists them when there are several.
`domains`	No	Comma-separated full URLs, e.g. "https://app.example.com,https://www.example.com" (a :port suffix routes to that container port). Not allowed for dockercompose.
`dry_run`	No	Report what would change without calling the mutating API. Allowed even in read-only mode.
`project`	Yes	Project uuid or name.
`is_static`	No	nixpacks/railpack: serve the build output as a static site (with publish_directory).
`build_pack`	No	nixpacks (auto-detect), static (nginx serving files), dockerfile, dockercompose, or railpack (Coolify >= 4.1.0).	nixpacks
`git_branch`	No	Branch to deploy.	main
`github_app`	No	Private repo via a GitHub App: its uuid or name.
`description`	No	Free-text description (null clears it on update).
`environment`	No	Environment name inside the project (must exist).	production
`build_command`	No	Override the build command (nixpacks/railpack).
`ports_exposes`	No	Container port(s) the proxy routes to, comma-separated.
`start_command`	No	Override the start command (nixpacks/railpack).
`base_directory`	No	Sub-directory of the repo to build from (monorepos), e.g. "/apps/web". Default "/".
`git_repository`	Yes	owner/repo (GitHub), or a full URL: https://host/owner/repo, git@host:owner/repo.git.
`instant_deploy`	No	Queue the first deployment right away (needs the deploy permission).
`install_command`	No	Override the install command (nixpacks/railpack).
`destination_uuid`	No	Docker network (destination) uuid; only needed when the server has several.
`private_key_uuid`	No	Private repo via a deploy key: the uuid of the private key stored in Coolify.
`health_check_path`	No	HTTP health check path, e.g. "/health".
`publish_directory`	No	Directory with the built static files (static sites, e.g. "/dist").

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.0Sep 27, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing auth requirements (GitHub App vs. stored deploy key), the deploy-permission prerequisite for instant_deploy, that nothing is built unless instant_deploy is true, that dry_run is allowed even in read-only mode, and the server-ambiguity error behavior. These are exactly the operational traits an agent needs and that readOnlyHint/destructiveHint/openWorldHint do not convey.

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?

Front-loads the core action in the first clause and keeps every subsequent sentence load-bearing (auth, defaults, preview, return). It is dense for a 22-parameter tool but does not enumerate redundant fields; only minor tightening would help.

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

Completeness5/5

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

For a high-complexity create tool with no output schema, it covers the safety profile, auth variants, defaults, build gating, and even the return value plus next steps (set_envs, then deploy). Nothing essential to calling it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema lacks: project/server accept uuid or name, github_app vs. private_key_uuid map to distinct private-repo auth paths, and instant_deploy has a concrete build consequence. Some of this only lightly extends the detailed per-parameter schema text, so it lands at 4 rather than 5.

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

Purpose5/5

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

States a specific verb and resource ("Create a Coolify application from a git repository") and clearly separates itself from siblings like get_application and update_application. It even names adjacent tools (list_projects, list_servers, set_envs, deploy), so an agent can route without opening other schemas.

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

Usage Guidelines4/5

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

Gives concrete conditional routing: public repos by default; private repos require either github_app or private_key_uuid; server may be omitted when only one can host; use dry_run to preview. It names alternatives for lookups (list_projects/list_servers) but stops short of stating when NOT to use this tool (e.g. use update_application to modify an existing app).

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

Create application from a git repository

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools