Skip to main content
Glama
0xtlt

coolify-mcp

by 0xtlt
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

coolify_set_service_storage_backup

[WRITE] Create or replace a backup schedule for a service persistent volume/directory

Instructions

[WRITE] Create or replace a backup schedule for a service persistent volume/directory

Input Schema

NameRequiredDescriptionDefault
uuidYesUUID of the service
enabledNoWhether the schedule is enabled (default true)
save_s3NoAlso upload backups to S3
timeoutNoBackup timeout in seconds
frequencyYesCron frequency for the backup (e.g. '0 2 * * *')
storage_uuidYesUUID of the persistent volume or directory storage
s3_storage_uuidNoS3 storage UUID when save_s3 is true
retention_days_s3No
stop_during_backupNoStop the resource during backup
retention_amount_s3No
disable_local_backupNoDisable local backup retention
retention_days_locallyNo
retention_amount_locallyNo
retention_max_storage_s3No
retention_max_storage_locallyNo
missing_backup_notification_daysNoAlert after this many days without an execution; 0 disables alerts (Coolify v4.4.1)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv4.3.0
    • addedInput schema / properties / missing_backup_notification_days
      Added value: +{
+  "description": "Alert after this many days without an execution; 0 disables alerts (Coolify v4.4.1)",
+  "maximum": 365,
+  "minimum": 0,
+  "type": "integer"
+}
    • removedInput schema / properties / s3_storage_uuid / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedInput schema / properties / s3_storage_uuid / type
      Added value: +[
+  "string",
+  "null"
+]
  2. Changed2 schema fields changedv4.1.0
    • changedInput schema / properties / timeout / maximum
      Previous value: -9007199254740991New value: +36000
    • changedInput schema / properties / timeout / minimum
      Previous value: --9007199254740991New value: +60
  3. First observedv4.0.0

TDQS

C2.9/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. The '[WRITE]' tag and 'create or replace' do disclose the mutation/upsert nature, which is valuable. But it says nothing about permissions required, whether an existing schedule is fully overwritten (including retention settings not passed), or whether a backup fires immediately.

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 front-loaded sentence with a useful '[WRITE]' marker and zero filler. Its brevity is efficient, though it tips into under-specification given the 16-parameter surface.

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?

For a 16-parameter, no-annotation, no-output-schema mutation tool, the agent needs to know how retention options interact, what S3 configuration is required, and what 'replace' overwrites. None of that is present, leaving the definition insufficient to call correctly without reading the whole schema.

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?

Schema coverage is 63%, leaving roughly six retention parameters (retention_days_s3, retention_amount_s3, retention_days_locally, retention_amount_locally, retention_max_storage_s3, retention_max_storage_locally) undocumented anywhere. The description explains none of the 16 parameters or the dependency between save_s3 and s3_storage_uuid, so it fails to compensate for the gap.

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 ('Create or replace a backup schedule') scoped to a service persistent volume/directory, which implicitly distinguishes it from the application and database siblings. It stops short of naming those siblings explicitly, so differentiation relies on the word 'service'.

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 coolify_run_service_storage_backup, coolify_delete_service_storage_backup, or coolify_update_service_storage, nor any stated prerequisites (e.g. that the storage_uuid must already exist via coolify_create_service_storage). Intent is only implied by the verb.

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