Skip to main content
Glama
Sign In
lazyants

hetzner-mcp-server

by lazyants
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create Load Balancer

hetzner_create_load_balancer

Create a Hetzner Cloud load balancer with a specified type, location or network zone, plus optional targets and services to distribute traffic.

Instructions

Create a new load balancer with the specified type, location, and optional targets and services.

Input Schema

NameRequiredDescriptionDefault
nameYesName of the load balancer
labelsNoLabels as key-value pairs
networkNoNetwork ID to attach to
targetsNoArray of targets
locationNoLocation name (e.g. "fsn1"), mutually exclusive with network_zone
servicesNoArray of services
algorithmNoLoad balancing algorithm
public_netNoExisting Primary IPs to assign at creation; assignments cannot be changed later
network_zoneNoNetwork zone (e.g. "eu-central"), mutually exclusive with location
public_interfaceNoEnable the public interface
load_balancer_typeYesLoad balancer type name or ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.0.2
    • addedInput schema / properties / public_net
      Added value: +{
+  "description": "Existing Primary IPs to assign at creation; assignments cannot be changed later",
+  "properties": {
+    "ipv4": {
+      "anyOf": [
+        {
+          "description": "Resource ID",
+          "exclusiveMinimum": 0,
+          "maximum": 9007199254740991,
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Existing IPv4 Primary IP ID; omit or set null for a system-managed IPv4 address"
+    },
+    "ipv6": {
+      "anyOf": [
+        {
+          "description": "Resource ID",
+          "exclusiveMinimum": 0,
+          "maximum": 9007199254740991,
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Existing IPv6 Primary IP ID; omit or set null for a system-managed IPv6 address"
+    }
+  },
+  "type": "object"
+}
  2. First observedv2.2.0

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already disclose create semantics: non-read-only, non-destructive, non-idempotent, open-world. The description adds only the scoping of optional targets and services. It does not mention that repeated calls create duplicate balancers (relevant given idempotentHint=false) or what the call returns.

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?

One well-formed sentence, front-loaded with the verb and resource, no filler. It is efficient, if slightly thin for an eleven-parameter creation tool.

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

Completeness2/5

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

For an 11-parameter, deeply nested creation tool with no output schema, the description says nothing about what is returned (e.g. the new load balancer ID/status) or that targets and services can be modified after creation. The schema fills in field-level detail but the behavioral envelope is missing.

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% and the nested target/service structures are fully documented inline, so the schema carries the parameter meaning. The description only echoes type/location/targets/services at the top level, adding no syntax or constraint detail beyond the schema.

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 load balancer) and names the key configurable dimensions (type, location, targets, services). This clearly separates it from the update/delete load balancer siblings, though it does not explicitly name them.

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 alternatives, no prerequisites (e.g. that a load balancer type must already exist, or that targets/services can also be added later via hetzner_add_lb_target / hetzner_add_lb_service). The reader must infer its role purely from the name.

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