Skip to main content
Glama
0xtlt

coolify-mcp

by 0xtlt
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

coolify_update_server

[WRITE] Update configuration of a Coolify server

Instructions

[WRITE] Update configuration of a Coolify server

Input Schema

NameRequiredDescriptionDefault
ipNoServer IP address
nameNoServer display name
portNoSSH port
userNoSSH username
uuidYesUUID of the resource
descriptionNoServer description
server_roleNoDeployments only, builds only, or both (Coolify v4.4+; replaces is_build_server)
is_build_serverNoUse as build server (Coolify v4.4+: deprecated, use server_role=build)
private_key_uuidNoUUID of the SSH private key
server_disk_usage_notification_interval_hoursNoHours between repeated high disk usage alerts (Coolify v4.4+)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv4.3.0
    • changedInput schema / properties / is_build_server / description
      Previous value: -"Use as build server"New value: +"Use as build server (Coolify v4.4+: deprecated, use server_role=build)"
    • addedInput schema / properties / server_disk_usage_notification_interval_hours
      Added value: +{
+  "description": "Hours between repeated high disk usage alerts (Coolify v4.4+)",
+  "maximum": 720,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / server_role
      Added value: +{
+  "description": "Deployments only, builds only, or both (Coolify v4.4+; replaces is_build_server)",
+  "enum": [
+    "deployment",
+    "build",
+    "both"
+  ],
+  "type": "string"
+}
  2. First observedv4.0.0

TDQS

C2.9/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 burden, yet it only contributes a '[WRITE]' tag. It does not say whether updates are partial or full replacement, whether omitted fields are preserved, whether SSH connectivity is re-tested, whether the change is reversible, or what permissions are required. For a 10-parameter mutation on infrastructure, this is a serious gap.

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?

A single short, front-loaded line with the mutation signal leading. It wastes nothing, but the brevity comes at the cost of the behavioral detail a write tool needs.

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?

With 10 parameters, no annotations, and no output schema, the description should explain partial-update semantics and side effects; it explains neither. An agent can call it correctly from the schema alone but cannot predict what happens to the server.

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% and each field is documented inline, including the server_role enum and the is_build_server deprecation note, so the description has little left to add. It does not mention that only uuid is required, which is the key semantic (partial update) an agent would want stated in prose.

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 (update) and resource (Coolify server configuration), which cleanly separates it from coolify_create_server, coolify_delete_server, and coolify_get_server. It stops short of saying what 'configuration' covers, but the schema title plus the WRITE marker make the intent unambiguous.

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?

No guidance on when to prefer this over siblings such as coolify_validate_server, coolify_update_private_key, or coolify_get_server, and no prerequisites. The agent must infer that this is the tool for changing an existing server's name/IP/port/role.

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