coolify_import_service_database

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

With no annotations, the description does real work: it tags the operation [DESTRUCTIVE], states it runs in the background rather than returning a result, and discloses an authorization prerequisite for one source mode. It does not say what existing database contents are replaced or how failures surface, which keeps it below a 5.

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?

Three tight sentences, with the destructive warning and the action front-loaded and the polling/authorization caveats following. Nothing is redundant with the name or with the schema.

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?

For a 12-parameter destructive async tool with no output schema and no annotations, it covers the essentials an agent must know before calling: destructiveness, async polling target, and the server-source token requirement. The remaining parameter interactions are carried by the fully described schema, so the gap is minor.

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?

Schema coverage is 100%, so every parameter is already documented, including the source enum, confirm, and the source-specific fields. The description only restates the three source options without adding format or interaction rules (e.g., how replace_existing interacts with keep_owners), so the baseline 3 applies.

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?

A specific verb plus resource: restores a backup into a database of a *service*, with the three allowed sources enumerated inline. The sibling-provisioning note (poll coolify_get_service_database_import) also separates it from the plain coolify_import_database / coolify_get_database_import pair.

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?

Gives clear operational context: this is the async entry point, and coolify_get_service_database_import is the follow-up. It also flags the prerequisite that source=server needs the deploy token ability. It stops short of an explicit when-not/alternative rule versus coolify_import_database, so it is clear but not fully routing.

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