coolify_update_server

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

The description begins with '[WRITE]' which hints at a write/mutation operation, but since no annotations are provided, the description must fully disclose behavioral traits. It lacks information about whether the update is incremental or replaces all fields, what the effect on running services is, or any required permissions. The description 'Update configuration' is too vague about the mutation's scope and consequences.

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

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

The description is a single short sentence, which is concise. However, it uses the '[WRITE]' prefix which is not clearly explained and adds minimal value given the description already implies mutation. It is front-loaded with the action verb, but could be slightly more informative without adding length.

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

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

Given the complex context with 8 parameters and no output schema, the description is minimally adequate. It conveys the tool's purpose but does not cover what happens after an update (e.g., does it return the updated server?) or whether all parameters are updatable. The sibling tool list shows many other CRUD operations, but the description doesn't differentiate enough for the agent to know when to use this over coolify_create_server or coolify_get_server.

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

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

The input schema covers 100% of parameters with descriptions, so the schema already does heavy lifting. The description does not add meaning beyond the schema—it simply says 'update configuration' without detailing which parameters are updatable or mandatory. The schema lists 8 optional parameters and 1 required (uuid), but the description doesn't clarify that uuid identifies the server to update, leaving the agent to infer from the schema alone.

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

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

The description states 'Update configuration of a Coolify server' which clearly indicates the action (update) and the resource (server configuration). It distinguishes itself from sibling tools like coolify_create_server and coolify_delete_server by using the specific verb 'update', and from coolify_get_server which is read-only. However, it could be more specific by noting that it is used to modify existing server settings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies that this tool is for modifying an existing server's configuration after creation, which is a reasonable use case. However, it provides no explicit guidance on when to use this tool versus alternatives (e.g., coolify_create_server for new servers, coolify_validate_server for testing). There is no mention of prerequisites or conditions under which the update should be performed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.