hcloud-mcp

create_certificate

Create a TLS certificate for Hetzner Cloud: upload an existing PEM certificate and private key, or request an auto-renewed Let's Encrypt certificate for domains in delegated primary DNS zones.

Instructions

Create a TLS certificate. type "uploaded" (default): provide certificate (PEM, leaf first then chain) and private_key (PEM); supported keys RSA 2048/3072/4096 or ECDSA P-256/P-384; you must renew it yourself before not_valid_after. type "managed": provide domain_names; Hetzner requests and auto-renews a Let's Encrypt cert. Managed (Let's Encrypt) certificates are validated via DNS: every domain must be in a PRIMARY Hetzner DNS zone (create_zone) that is delegated to Hetzner's nameservers at the registrar, and any CAA record must allow Let's Encrypt. Typical failures: dns_zone_not_found, dns_zone_is_secondary_zone, could_not_verify_domain_delegated_to_zone, caa_record_does_not_allow_ca, ca_dns_validation_failed, Let's Encrypt rate limits. Returns {certificate, action}: action tracks managed issuance (poll get_action), null for uploaded. Certificates are referenced by ID in Load Balancer HTTPS services: http.certificates in add_load_balancer_service / update_load_balancer_service

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "create_certificate"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes	Unique name within the project
`type`	No		uploaded
`labels`	No
`certificate`	No	uploaded only: certificate + chain in PEM, each cert certifying the preceding one
`private_key`	No	uploaded only: private key in PEM. Sent to the API only; never returned
`domain_names`	No	managed only: domains to include, e.g. ["example.com", "www.example.com"]

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.1Nov 11, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only mark this as non-read-only and non-destructive; the description adds the operational reality well beyond that: the caller must renew uploaded certs before not_valid_after, managed issuance is asynchronous with an action to poll, and DNS/CAA preconditions must hold. It also enumerates concrete failure codes (dns_zone_not_found, caa_record_does_not_allow_ca, ca_dns_validation_failed, Let's Encrypt rate limits) so the agent can anticipate errors rather than guess.

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?

Front-loaded with purpose and then organized by mode, so an agent can stop reading once it knows its variant. It is dense and durable, with almost every clause carrying a constraint, though the long tail of failure codes and the load-balancer reference sentence could be tightened without losing selection value.

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

Completeness5/5

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

For a 6-parameter creation tool with no output schema, the description still documents the return value ({certificate, action} with action null for uploaded) and the follow-on polling pattern. Combined with prerequisites and referenced-by-ID usage, an agent has everything needed to invoke it correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 67% schema coverage, the description compensates beyond the schema: it specifies PEM ordering (leaf first then chain), the accepted key algorithms and sizes (RSA 2048/3072/4096, ECDSA P-256/P-384), and that private_key is sent to the API but never returned. It also pins domain_names as the managed-only field and restates type's default, adding security-relevant meaning the schema does not carry.

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?

Opens with a specific verb and resource ("Create a TLS certificate") and immediately splits the resource into its two distinct modes, "uploaded" and "managed", each with its own required payload. An agent can tell this apart from update_certificate, retry_certificate, and get_certificate without inspecting another schema.

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

Usage Guidelines4/5

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

The description clearly states which mode to choose and the exact conditions attached to each: uploaded requires certificate + private_key and self-renewal, managed requires domain_names and Hetzner handles renewal. It also routes the agent forward to get_action polling and to add_load_balancer_service / update_load_balancer_service for consumption. It stops short of naming when to use update_certificate or retry_certificate instead, but the mode-level guidance is strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server