Skip to main content
Glama

hcloud_server_reset_password_action

Destructive

Reset a Linux server's root password and generate a new one. Requires the server to be running with the qemu guest agent installed.

Instructions

Reset root Password of a Server

Resets the root password. Only works for Linux systems that are running the qemu guest agent. Server must be powered on (status running) in order for this operation to succeed.

This will generate a new password for this Server and return it.

If this does not succeed you can use the rescue system to netboot the Server and manually change your Server password by hand.

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare the operation as destructive and open-world. The description adds meaningful behavior beyond that: the server must be running, it only works on Linux with qemu guest agent, it generates and returns a new password, and rescue mode is a fallback if it fails. It does not cover auth requirements or rate limits, but the core 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?

The description is front-loaded and reasonably tight, but the opening sentence 'Reset root Password of a Server' is immediately restated as 'Resets the root password,' creating slight redundancy. The rest of the content earns its place by covering prerequisites, return value, and fallback.

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

Completeness4/5

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

For a destructive server action with no output schema, the description covers the key operational constraints, the returned new password, and a fallback path. It could be slightly more complete by mentioning that the old password becomes invalid or that authentication/permissions may be required, but it is broadly sufficient.

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?

The input schema has 100% description coverage for both parameters (id and wait), so the schema already explains them. The description does not add parameter-level detail beyond the schema, which is acceptable given the high coverage.

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?

The description states a specific verb and resource: resetting the root password of a server. It clearly differentiates this operation from general server update tools, but it does not explicitly name sibling alternatives such as the rescue-system actions to reinforce the distinction.

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 provides important usage context: Linux only, qemu guest agent required, and server must be running. However, it does not explicitly state when to choose this tool over alternatives like hcloud_server_enable_rescue_action or manual rescue-system password changes; the fallback mention is only after failure.

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