Coolify Creation MCP

Overview Schema Source Related Servers Discussions Admin

create_deploy_key_application

Create a private Git repository application in Coolify using a deploy key, returning the app UUID and an authenticated deploy webhook for manual deployment later.

Instructions

Create one private Git repository through a deploy key 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>",
      "git_repository": "<git_repository>",
      "git_branch": "<git_branch>",
      "build_pack": "<build_pack>",
      "private_key_uuid": "<private_key_uuid>"
    },
    "name": "create_deploy_key_application"
  }
}

Input Schema

Name	Required	Default
`name`	Yes
`is_spa`	No
`domains`	No
`redirect`	No	both
`is_static`	No
`build_pack`	Yes
`git_branch`	Yes
`server_uuid`	Yes
`project_uuid`	Yes
`build_command`	No
`ports_exposes`	No	80
`start_command`	No
`base_directory`	No	/
`git_repository`	Yes
`install_command`	No
`destination_uuid`	No
`environment_uuid`	Yes
`private_key_uuid`	Yes
`publish_directory`	No
`autogenerate_domain`	No
`dockerfile_location`	No
`health_check_enabled`	No
`docker_compose_domains`	No
`docker_compose_location`	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 annotations by disclosing the auth requirement, the return payload (UUID plus authenticated deploy webhook), the fact that no deployment happens, and that auto-deploy is off. The retry caution adds safety context. No contradiction with readOnlyHint=false / destructiveHint=false.

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?

Five short, front-loaded sentences with minimal waste; the constraints (no deploy, retry caution) arrive early. The final sentence is slightly cryptic about what 'inventory' means, but overall it is tight.

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?

Return values and deployment side-effects are covered, which compensates for the missing output schema. The large gap is parameter guidance across 24 required/optional fields in a high-stakes creation tool — an agent could call this correctly in shape but not in substance.

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?

With 24 parameters and 0% schema description coverage, the description carries the full burden and largely fails it — only indirect hints (private repo, deploy key) point at private_key_uuid and git_repository. Nothing explains project_uuid, server_uuid, environment_uuid, build_pack, or the domain/redirect behavior.

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: creating a single private-repo application via a deploy key through Coolify's API. The 'private Git repository' + 'deploy key' phrasing implicitly separates it from create_public_repository_application and create_github_app_application, but it never names those siblings, so disambiguation is inferred rather than stated.

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?

Gives real operational guidance — read/write token permissions required, this does not deploy, automatic Git deployment is disabled, and inspect inventory before retrying an uncertain failure. However, it never says when to prefer this over the plan_deploy_key_application sibling, which is the most likely wrong choice an agent could make.

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

Deploy Server