Skip to main content
Glama

hcloud_delete_network

Destructive

Delete a Hetzner Cloud network by ID; attached resources are detached automatically.

Instructions

Delete a Network

Deletes a Network.

Attached resources will be detached automatically.

Input Schema

NameRequiredDescriptionDefault
idYesID of the Network.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3.3/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, so the safety profile is known; the description nonetheless adds real behavioral value by stating that attached resources are detached automatically rather than blocking the delete. It stops short of saying whether the delete is irreversible, which resources are considered 'attached', or whether an async action is returned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

Very short and front-loaded, but the title line 'Delete a Network' and the body sentence 'Deletes a [Network](...)' are redundant restatements. Only the third sentence carries new information, so one of the three does not earn its place.

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 one-parameter destructive tool with no output schema, the description covers the core side effect (auto-detachment) but omits irreversibility and the shape of the response — the sibling presence of hcloud_get_network_action suggests deletion may return an asynchronous action, which is never mentioned.

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 single parameter 'id' is fully documented in the schema (100% coverage, with type, range, and example), so the schema carries the load. The description adds no meaning about how to obtain the ID or what happens if the ID is stale/not found, so baseline 3 applies.

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?

Clear specific verb+resource: deletes a Network, identified by ID. An agent can distinguish it from hcloud_get_network, hcloud_update_network, and hcloud_create_network by name alone, but the description never explicitly contrasts with the network-scoped siblings (subnet/route deletion actions) or warns against using it when only a subnet should go.

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

Usage Guidelines2/5

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

There is no explicit when-to-use / when-not-to-use guidance and no mention of alternatives such as hcloud_network_delete_subnet_action or hcloud_network_delete_route_action for partial cleanup. Usage is only implied by the word 'Delete' and the auto-detach note.

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