Skip to main content
Glama

Coolify: Update database

coolify_update_database
Destructive

Update Coolify database settings by site and UUID, including credentials, resource limits, and engine-specific configuration.

Instructions

[UNIFIED] Update a Coolify database settings.

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_database"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNo
siteYes
uuidYes
imageNo
is_publicNo
keydb_confNo
mongo_confNo
mysql_confNo
mysql_userNo
redis_confNo
descriptionNo
limits_cpusNo
postgres_dbNo
public_portNo
mariadb_confNo
limits_cpusetNo
limits_memoryNo
postgres_confNo
postgres_userNo
keydb_passwordNo
mysql_databaseNo
mysql_passwordNo
redis_passwordNo
clickhouse_confNo
limits_cpu_sharesNo
postgres_passwordNo
limits_memory_swapNo
mysql_root_passwordNo
postgres_initdb_argsNo
clickhouse_admin_userNo
mongo_initdb_databaseNo
limits_memory_swappinessNo
clickhouse_admin_passwordNo
limits_memory_reservationNo
postgres_host_auth_methodNo
mongo_initdb_root_passwordNo
mongo_initdb_root_usernameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.14.0

TDQS

C2/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is known. The description adds nothing beyond that — it does not say whether unspecified fields are preserved or reset to defaults, whether changes trigger a redeploy/restart of the database container, or what happens on partial failure; for a 37-parameter destructive mutation this is a significant gap.

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

Conciseness2/5

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

The single sentence is short and front-loaded, but its brevity reflects under-specification rather than efficiency. The '[UNIFIED]' tag consumes part of a one-line budget without conveying anything actionable.

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

Completeness1/5

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

For a destructive update tool with 37 undocumented parameters, no output schema, and only minimal annotations, the description is far too thin. An agent cannot determine engine-specific field semantics, side effects, or return behavior from this definition.

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 37 parameters, and the description mentions none of them. It does not explain the required 'site'/'uuid' identifiers, the per-engine config groups (mysql_conf, postgres_conf, redis_conf, mongo_initdb_*), or which fields are engine-specific and will be ignored otherwise.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a clear verb+resource ('Update a Coolify database settings'), so the agent knows this mutates a database resource. However, it offers no differentiation from siblings such as coolify_update_application or coolify_update_service, and the '[UNIFIED]' prefix is unexplained jargon that adds no discriminating information.

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 when-to-use guidance: nothing says when to update versus recreate, restart, or reconfigure via coolify_update_service, and no prerequisites or preconditions are stated. The agent must infer usage entirely from the name and sibling list.

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