Skip to main content
Glama
mjmirza

hetzner-mcp

by mjmirza
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Delete a cloud server

cloud_delete_server

Delete a Hetzner Cloud server to stop billing. This is irreversible and requires confirmation; auto-created primary IPs are released after.

Instructions

Delete a Hetzner Cloud server. Deleting is free and stops billing, but it destroys the server, so it requires confirm true. Auto-created primary IPs are released by Hetzner shortly after.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesServer id.
confirmNoMust be true. Deletes the server for good.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.7.0
    • changedInput schema / properties / confirm / description
      Previous value: -"Must be true. This permanently deletes the server."New value: +"Must be true. Deletes the server for good."
    • changedInput schema / properties / id / anyOf
      Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  }
-]New value: +[
+  {
+    "exclusiveMinimum": 0,
+    "maximum": 9007199254740991,
+    "type": "integer"
+  },
+  {
+    "pattern": "^[0-9]+$",
+    "type": "string"
+  }
+]
  2. First observedv0.3.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that deletion is irreversible, that it stops billing, that a confirm flag is mandatory, and that auto-created primary IPs are released shortly after. It omits permission requirements and any dependency handling (e.g. attached volumes), keeping it short of 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.

Conciseness5/5

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

Two tight sentences with zero filler; the destructive nature and confirm requirement are front-loaded ahead of the secondary IP-release detail. Every clause carries information an agent needs.

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 two-parameter destructive tool with no annotations and no output schema, the description covers the key risks: irreversibility, billing impact, the confirm gate, and one notable side effect. Minor gaps remain around prerequisites (server state, dependent resources), but nothing critical for correct invocation is missing.

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 already 100%, so the baseline is 3, but the description adds real semantic weight by explaining the purpose of confirm (gate for permanent destruction) and clarifying the downstream billing/IP effects. It does not add syntax beyond what the schema documents for id.

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?

Specific verb + resource ('Delete a Hetzner Cloud server') that immediately separates it from siblings like cloud_delete_volume, cloud_delete_network, or cloud_delete_primary_ip. An agent knows exactly which resource is targeted without opening the schema.

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?

States the precondition (confirm true) and the consequence, which implies when to use it, but names no alternatives and gives no explicit when-not guidance (e.g. powering off first, or deleting attached volumes/IPs separately). Usage is inferred rather than directed.

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