Skip to main content
Glama
0xtlt

coolify-mcp

by 0xtlt
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

coolify_update_application

[WRITE] Update configuration of a Coolify application

Instructions

[WRITE] Update configuration of a Coolify application

Input Schema

NameRequiredDescriptionDefault
fqdnNoFully qualified domain name(s)
nameNoApplication name
uuidYesUUID of the resource
is_staticNoServe as static site
build_packNoBuild pack (dockerfile, nixpacks, static, dockercompose, dockerimage)
git_branchNoGit branch
descriptionNoApplication description
build_commandNoBuild command (e.g. npm run build)
custom_fieldsNoAdditional fields not listed above (advanced)
ports_exposesNoExposed ports (e.g. 3000,8080)
start_commandNoStart command (e.g. npm start)
base_directoryNoBase directory in repo
git_repositoryNoGit repository URL
instant_deployNoDeploy immediately after update
install_commandNoInstall command (e.g. npm install)
publish_directoryNoPublish directory for static builds
is_auto_deploy_enabledNoAuto-deploy on push
custom_container_name_prefixNoReadable prefix for generated container names (Coolify v4.4+; slugified, max 30 chars, unique per server)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.3.0
    • addedInput schema / properties / custom_container_name_prefix
      Added value: +{
+  "description": "Readable prefix for generated container names (Coolify v4.4+; slugified, max 30 chars, unique per server)",
+  "maxLength": 255,
+  "type": "string"
+}
  2. First observedv4.0.0

TDQS

C2.8/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden. The '[WRITE]' prefix usefully signals mutation, but nothing is said about partial-update semantics (whether omitted fields are preserved or reset), required permissions, deployment side effects, or reversibility — all critical for an 18-parameter update call.

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?

A single front-loaded sentence with zero waste, which satisfies brevity. However, for a tool with 18 parameters and nested objects, that brevity tips into under-specification rather than economy.

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?

Complex, high-parameter-count mutation tool with no annotations and no output schema, yet the description is a ten-word fragment. An agent cannot tell whether this is a PATCH-style partial update, whether instant_deploy triggers a rebuild, or what happens on uuid mismatch.

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

Parameters3/5

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

Schema description coverage is 100%, so every one of the 18 parameters including the nested custom_fields object is documented in the schema itself. The description adds no parameter-level meaning beyond the schema, which is acceptable but not additive, so the baseline 3 applies.

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 ('Update configuration of a Coolify application'), so an agent knows the mutation target. It does not distinguish this from near-name siblings such as coolify_update_application_storage, coolify_update_application_preview, or coolify_update_application_secret_manager, which an agent could easily confuse.

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?

There is no guidance on when to use this versus the preview/storage/secret-manager update tools, no prerequisite information (e.g., that the uuid must come from coolify_get_application or coolify_list_applications), and no mention of what to do if the application is currently deployed.

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