Skip to main content
Glama
Sign In
hcloud-mcp

hcloud-mcp

by Xodus-CO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

enable_rescue

Activates the Hetzner Rescue System on a server for repair or reinstall tasks. Does not reboot; follow with a reset or reboot to apply it.

Instructions

Enable the Hetzner Rescue System (minimal Linux for repair/reinstall) on a server. Does NOT reboot: rescue only takes effect at the next boot, so follow with reset_server (or reboot) once the Action succeeds. Rescue is disabled automatically when the server first boots into it, or if it is not used within 60 minutes. Returns an Action and root_password for the rescue system (valid once the Action succeeds; treat as a secret). Pass ssh_keys to log in by key instead

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": {
      "id": "<id>"
    },
    "name": "enable_rescue"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesServer ID
typeNoRescue system type; only linux64 exists (default)
ssh_keysNoSSH key IDs to inject into the rescue system

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare openWorldHint=true and destructiveHint=false, but the description adds substantial context beyond them: no reboot is performed, rescue mode deactivates at first boot or after 60 minutes without use, and the call returns an Action plus a root_password that should be treated as a secret. That secrecy and lifecycle disclosure is exactly the kind of behavior an agent cannot infer from structured fields.

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?

Behaviorally dense but front-loaded: what it does, then the reboot caveat and required follow-up, then lifecycle, then return values. Nearly every sentence carries new information. The final sentence is a fragment without terminal punctuation, a minor structural blemish.

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

Completeness5/5

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

No output schema exists, and the description compensates by naming the returned Action and root_password along with their validity condition. Combined with the boot/60-minute expiry and the required follow-up call, an agent has everything needed to invoke and sequence this tool correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, and the description earns above that by explaining the ssh_keys parameter's purpose beyond the schema text: supplying keys replaces password login, which is otherwise the default path implied by the returned root_password. The type parameter is left to the enum and schema, which is acceptable.

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

Purpose5/5

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

"Enable the Hetzner Rescue System (minimal Linux for repair/reinstall) on a server" gives a specific verb, resource, and a parenthetical clarifying what the rescue system actually is. It also implicitly separates itself from disable_rescue and explicitly from reset_server, so an agent can place it correctly among siblings.

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

Usage Guidelines4/5

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

Strong sequencing guidance: the tool does not reboot, so the agent is told to call reset_server (or reboot) after the Action succeeds. It also states the 60-minute unused window and auto-disable-on-first-boot. It stops short of explicit when-not-to-use guidance such as preferring attach_iso for other repair workflows, so not a full 5.

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