Skip to main content
Glama

Coolify: Update application

coolify_update_application
Destructive

Modify Coolify application settings such as domains, build options, health checks, and resource limits to align deployed apps with current requirements.

Instructions

[UNIFIED] Update a Coolify application settings. Supports name, description, domains, build settings, health checks, resource limits, and more.

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": {
      "site": "<site>",
      "uuid": "<uuid>"
    },
    "name": "coolify_update_application"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNo
siteYes
uuidYes
domainsNo
redirectNo
build_packNo
dockerfileNo
git_branchNo
descriptionNo
limits_cpusNo
watch_pathsNo
static_imageNo
build_commandNo
clear_domainsNo
custom_labelsNo
limits_cpusetNo
limits_memoryNo
ports_exposesNo
start_commandNo
base_directoryNo
docker_composeNo
git_commit_shaNo
git_repositoryNo
instant_deployNo
ports_mappingsNo
install_commandNo
is_gzip_enabledNo
health_check_hostNo
health_check_pathNo
health_check_portNo
limits_cpu_sharesNo
publish_directoryNo
docker_compose_rawNo
limits_memory_swapNo
dockerfile_locationNo
health_check_methodNo
health_check_schemeNo
health_check_enabledNo
health_check_retriesNo
health_check_timeoutNo
is_log_drain_enabledNo
health_check_intervalNo
docker_compose_domainsNo
is_auto_deploy_enabledNo
is_force_https_enabledNo
is_stripprefix_enabledNo
pre_deployment_commandNo
docker_compose_locationNo
dockerfile_target_buildNo
post_deployment_commandNo
health_check_return_codeNo
http_basic_auth_passwordNo
http_basic_auth_usernameNo
limits_memory_swappinessNo
custom_docker_run_optionsNo
docker_registry_image_tagNo
health_check_start_periodNo
limits_memory_reservationNo
custom_nginx_configurationNo
docker_registry_image_nameNo
health_check_response_textNo
is_http_basic_auth_enabledNo
is_preview_deployments_enabledNo
pre_deployment_command_containerNo
post_deployment_command_containerNo
docker_compose_custom_build_commandNo
docker_compose_custom_start_commandNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.14.0

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, while the description adds only broad field categories. It does not explain whether this is a partial update, how null/default values are treated, whether changes trigger a deployment, what clear_domains does, or what permissions and side effects apply to a destructive update. The category list adds some value, but the behavior of a destructive 67-parameter mutation remains largely undisclosed.

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

Conciseness3/5

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

The description is front-loaded in two short sentences with no obvious filler. However, for a 67-parameter destructive update tool, the extreme brevity is under-specification rather than effective conciseness, and 'and more' is too vague to guide the agent.

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

Completeness2/5

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

Given a destructive update tool with 67 parameters, no output schema, and no schema parameter descriptions, the description is materially incomplete. It communicates the general purpose and some affected areas, but omits required identifiers, parameter formats, mutation semantics, and side-effect details that an agent would need before invoking it safely.

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

Parameters1/5

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

Schema description coverage is 0% across 67 parameters, so the description must carry the burden of explaining parameter meaning. It only names a few broad categories ('name, description, domains, build settings, health checks, resource limits, and more') and does not explain required site/uuid, clear_domains, docker/compose build fields, health-check subfields, null defaults, or the many string-typed boolean-like flags. This is not enough to compensate for the lack of schema descriptions.

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?

The description states a specific verb ('Update') and resource ('Coolify application settings'), and it lists domains, build settings, health checks, and resource limits as supported areas. It does not explicitly distinguish this tool from close siblings such as coolify_update_application_env, and the phrase 'and more' leaves the exact scope fuzzy.

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

Usage Guidelines2/5

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

The description gives no when-to-use guidance, prerequisites, or alternatives. It does not say when to prefer this tool over coolify_update_application_env, coolify_get_application, or the restart/start/stop application tools.

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

Deploy Server

Other Tools