Skip to main content
Glama
0xtlt

coolify-mcp

by 0xtlt
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

coolify_set_application_storage_backup

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

Instructions

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

Input Schema

NameRequiredDescriptionDefault
uuidYesUUID of the application
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.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. 'Create or replace' usefully implies an idempotent upsert, but for a mutation tool with 16 parameters it does not say whether replacing wipes previously configured retention settings, what permissions/auth are required, or what happens to fields left unspecified.

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 tight sentence with the '[WRITE]' mutability marker front-loaded and the core resource stated immediately. It is efficient, though for a 16-parameter upsert it is arguably under-sized rather than over-sized.

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 16-parameter mutation with no annotations, no output schema, and only 63% schema coverage, the description is far thinner than the tool's complexity warrants. It omits prerequisites, upsert/replace semantics details, retention behavior, and any hint at the response.

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 description coverage is 63%, leaving several retention parameters (retention_days_s3, retention_amount_locally, retention_max_storage_*) undocumented anywhere. The description adds no parameter-level meaning at all — no explanation of frequency format, save_s3/s3_storage_uuid coupling, or stop_during_backup implications — 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+resource: 'Create or replace a backup schedule for an application persistent volume/directory', and the '[WRITE]' prefix signals the mutation class. It is distinguishable from the sibling run/delete backup tools by name and intent, though it never explicitly contrasts itself with coolify_set_database_storage_backup or coolify_set_service_storage_backup.

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 statement of when to use this versus coolify_run_application_storage_backup (trigger an immediate run) or the delete counterpart, nor any prerequisite such as the application and storage UUIDs having to exist first. Usage is only inferable from the name.

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