Skip to main content
Glama

hcloud_server_rebuild_action

Destructive

Rebuild a server from a system, snapshot, or backup Image, overwriting its disk and destroying all existing data; the server is powered off before the rebuild runs.

Instructions

Rebuild a Server from an Image

Rebuilds a Server overwriting its disk with the content of an Image, thereby destroying all data on the target Server

The Image can either be one you have created earlier (backup or snapshot Image) or it can be a completely fresh system Image provided by us. You can get a list of all available Images with GET /images.

Your Server will automatically be powered off before the rebuild command executes.

Input Schema

NameRequiredDescriptionDefault
idYesID of the Server.
bodyYes
waitNoPoll the resulting action until success/error or timeout.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds real value on top: it bolds that all data on the target disk is destroyed, notes the server is automatically powered off first, and explains that previous user_data is re-used if omitted. It omits async/action semantics, but the safety-relevant behavior is well disclosed.

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?

Short, front-loaded, and the destructive warning appears immediately after the purpose. Minor redundancy between the header line and the first sentence, but no padding.

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

Completeness3/5

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

For a destructive mutation with a nested body and no output schema, the description covers data loss, power-off behavior, and image sourcing but leaves the action/async model and the `wait` polling parameter unexplained. Adequate rather than complete.

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

Parameters3/5

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

At 67% schema coverage the description adds meaning for the `image` parameter by explaining that backup, snapshot, or system images are acceptable. It says nothing about the `wait` polling parameter or the nested `user_data` field, so full coverage is not achieved.

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 ('Rebuild a Server from an Image') and elaborates on the mechanics of overwriting the disk. It does not distinguish itself from the close sibling hcloud_server_rebuild or from related actions like reset/reboot, so sibling differentiation is missing.

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

Usage Guidelines3/5

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

It gives useful context on which image to choose (backup/snapshot vs. fresh system image) and points to GET /images for discovery, but never states when to prefer this over siblings like hcloud_server_rebuild, hcloud_server_reset_action, or a full server recreate.

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