hetzner-dns-mcp

A Model Context Protocol (MCP) server for managing DNS zones and records via the Hetzner Cloud API.

Lets MCP clients like Claude Code, Claude Desktop or Codex manage your Hetzner DNS: list, create, update and delete zones and RRSets (record sets), import/export zone files, manage protection and TTLs, and track asynchronous zone actions.

Twenty-two tools is the ceiling, not the floor: HETZNER_ALLOW_TOOLS=essential registers a curated eight instead, and a model picks the right tool far more reliably from eight than from twenty-two — see choosing which tools load.

Note: This server targets the current DNS API that is part of the Hetzner Cloud API (api.hetzner.cloud). The legacy DNS API (dns.hetzner.com) was shut down in May 2026 and is not supported.

What makes it different

Zones, record sets and the actions behind them. Listing, creating, updating and deleting zones and RRSets, importing and exporting BIND zone files, changing TTLs and protection — and following the asynchronous zone actions Hetzner queues behind a change, rather than reporting success and leaving you to guess.

Nothing upstream is trusted. Record values, comments and zone files come back wrapped as untrusted data, secret-looking keys are redacted, oversized values are truncated and HTML error pages are dropped instead of pasted into the context.

Destructive calls ask a person. Deleting a zone or replacing a record set raises a real dialog through MCP elicitation. Where the client cannot show one, the call is refused and carries a random single-use token that only ever appeared in a previous tool result — so nothing hidden inside a DNS record can mint it.

Requirements

• Node.js ≥ 22
• A Hetzner Cloud API token for the project that holds your DNS zones — create one in the Hetzner Cloud Console under your project → Security → API tokens. Use a read & write token for full functionality (a read-only token limits you to the read tools).

Configuration

Configuration is provided via environment variables:

Without a token the server still starts and lists its tools (so registries and inspectors can introspect it), but every tool call fails with setup instructions instead of reaching the API.

HETZNER_API_TOKEN and HETZNER_API_BASE_URL are deleted from the process environment once they have been read, so a later crash report or diagnostic dump cannot expose the token.

Choosing which tools load

HETZNER_ALLOW_TOOLS and HETZNER_DENY_TOOLS take comma-separated tool names; a trailing * matches a whole family. essential is a curated preset — list_zones, get_zone, list_rrsets, get_rrset, create_rrset, set_records, delete_rrset and export_zonefile — which covers reading a zone and changing a record without the rare, catastrophic tools.

HETZNER_ALLOW_TOOLS=essential
HETZNER_ALLOW_TOOLS=list_*,get_zone,set_records
HETZNER_DENY_TOOLS=delete_zone,import_zonefile

An entry that matches no tool aborts startup and names it, so a typo cannot silently hide a tool — an absent tool is not something anyone traces back to an environment variable. A filtered tool is never registered, so it is absent from tools/list and unknown to tools/call alike, exactly like a write tool under HETZNER_READ_ONLY.

If you run several of these servers at once, mcp-hub is the other answer — its /hub endpoint replaces every server's tools with six meta-tools.

Installation

Claude Code

claude mcp add hetzner-dns -s user \
  -e HETZNER_API_TOKEN=your-token \
  -- npx -y hetzner-dns-mcp

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "hetzner-dns": {
      "command": "npx",
      "args": ["-y", "hetzner-dns-mcp"],
      "env": {
        "HETZNER_API_TOKEN": "your-token"
      }
    }
  }
}

Codex

Add to your ~/.codex/config.toml:

[mcp_servers.hetzner-dns]
command = "npx"
args = ["-y", "hetzner-dns-mcp"]
env = { HETZNER_API_TOKEN = "your-token" }

From source

git clone https://github.com/ni-c/hetzner-dns-mcp.git
cd hetzner-dns-mcp
npm install
npm run build
# then use `node /path/to/hetzner-dns-mcp/dist/index.js` as the command

Docker

Multi-arch images (amd64/arm64) are published to GHCR with an SBOM and build provenance:

docker run -i --rm -e HETZNER_API_TOKEN=your-token ghcr.io/ni-c/hetzner-dns-mcp

The image talks MCP over stdio, so clients need docker run -i (no port is exposed):

{
  "mcpServers": {
    "hetzner-dns": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "HETZNER_API_TOKEN",
        "ghcr.io/ni-c/hetzner-dns-mcp"
      ],
      "env": {
        "HETZNER_API_TOKEN": "your-token"
      }
    }
  }
}

Through mcp-hub

A client that cannot spawn a local process — ChatGPT connectors, Claude on the web, Cursor, LibreChat — reaches hetzner-dns-mcp through mcp-hub: one container serves many stdio MCP servers over Streamable HTTP, with an OAuth 2.1 login behind a single password and long-lived tokens for the clients that cannot do OAuth. Its /hub endpoint puts every server behind six meta-tools, so one connector reaches all of them without N×tool schemas in the model's context, and it speaks both protocol revisions — a question this server asks travels through it to the person at the far end.