Skip to main content
Glama

hcloud_get_network

Read-only

Retrieve a specific Hetzner Cloud network by its numeric ID to inspect configuration and details.

Instructions

Get a Network

Get a specific Network.

Input Schema

NameRequiredDescriptionDefault
idYesID of the Network.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

C2.6/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context of its own — nothing about what a Network object contains, whether a missing ID errors, or any auth/rate-limit notes.

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?

It is short and front-loaded, but the second line ('Get a specific Network') merely repeats the first with a doc link, so one of two sentences is redundant rather than earning 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 simple single-resource read with a fully documented ID param and complete annotations, the essentials are present. But with no output schema, the description gives no hint of what a Network response contains or how it relates to subnets/routes, leaving a notable gap.

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?

With a single parameter and 100% schema description coverage ('ID of the Network.'), the schema fully documents the input, so the baseline of 3 applies. The description contributes nothing extra such as ID source (e.g., from hcloud_list_networks) or format constraints.

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

Purpose3/5

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

The description states the verb (get) and resource (Network) and adds 'specific', hinting at single-resource retrieval. However, it essentially restates the tool name, and with siblings like hcloud_list_networks, hcloud_get_network_members, and hcloud_get_network_action present, it does nothing to differentiate scope or return shape.

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 guidance on when to use this versus hcloud_list_networks or the network Members/actions getters, and no prerequisites or conditions stated. The only usable signal is the required integer ID, which is implied by the schema rather than the description.

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