Skip to main content
Glama
Sign In
lazyants

hetzner-mcp-server

by lazyants
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create Network

hetzner_create_network

Creates a Hetzner Cloud network with a specified IP range and optional subnets and routes, enabling isolated cloud networking setup.

Instructions

Create a new network with the specified IP range, and optionally subnets and routes.

Input Schema

NameRequiredDescriptionDefault
nameYesName of the network
labelsNoLabels as key-value pairs
routesNoArray of routes to create
subnetsNoArray of subnets to create
ip_rangeYesIP range of the whole network, e.g. "10.0.0.0/8"
expose_routes_to_vswitchNoWhether to expose routes to the vSwitch

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.0.2
    • changedInput schema / properties / subnets / items / properties / type / description
      Previous value: -"Type of subnet: cloud, server, or vswitch"New value: +"Subnet type: cloud or vswitch; server is a deprecated alias normalized to cloud (upstream removal 2027-04-15)"
  2. Changed1 schema field changedv3.0.0
    • addedInput schema / properties / expose_routes_to_vswitch
      Added value: +{
+  "description": "Whether to expose routes to the vSwitch",
+  "type": "boolean"
+}
  3. First observedv2.2.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already disclose that this is a non-read-only, non-idempotent, non-destructive open-world operation. The description adds that subnets and routes are optional, but does not explain creation side effects, whether an async action is returned, or constraints around network zones.

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?

A single compact sentence with no filler, front-loading the main action and primary required field. Every phrase contributes useful scope information.

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 six-parameter creation tool with nested objects and no output schema, the description is sparse. It covers the core purpose but leaves an agent to rely entirely on the schema for required name, labels, and vSwitch exposure behavior.

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?

Schema description coverage is 100%, so the schema already documents all six parameters including nested route and subnet fields. The description mentions ip_range, subnets, and routes but omits name, labels, and expose_routes_to_vswitch; baseline 3 is appropriate because the schema carries the detail.

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?

States a specific verb and resource ("Create a new network") plus the primary scope (IP range) and optional components (subnets, routes). It is distinguishable from delete/update/list network siblings, though it does not explicitly name alternatives.

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?

No guidance on when to use this versus update_network or add_subnet/add_route. The create semantics are implied by the verb but no prerequisites, exclusions, or alternative routing are provided.

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