"How much CPU did fra1-web-03 burn last week?"
It pulls the CPU, disk and network metrics Hetzner keeps. Ask about a load balancer instead and you get connections, requests and bandwidth.
Open source · MIT
hetzner-mcp
Checking a server used to mean opening a dashboard and clicking. Now the question gets asked in the client that is already open, and the answer comes back there. We opened the tool under MIT: free, source available to everyone.
GitHub repository → git clone · npm install · npm run build
Looking at a server used to be the same five steps every time: open a browser, sign in to the Hetzner Console, pick the right project, find the machine, click the metrics tab. Five steps for one question. hetzner-mcp lets you ask that question in the AI client you already have open and get the answer there. Our team runs Claude Code, Claude Desktop and Cursor, and this is an MCP server all of them talk to.
We wrote it for our own infrastructure, we use it every day, then opened it under the MIT licence. No paid version, no service package sold on the back of it. Download it and run it on your own machine.
What gets asked
Questions people actually type
Not invented examples — the sentences we type on a normal working day.
"How many machines are in the proxy project, and which ones are off?"
Search works by name, by listing a type, or by label selector. One search can sweep every connection you configured at once, not just the one you happen to be pointed at.
"Where does the A record for that domain point?"
DNS zones and record sets have their own tool. Reading them needs no extra flag; changing them does.
"What does a cpx31 cost per month, and is that with VAT?"
It returns what Hetzner publishes, with the currency and the VAT rate attached. It reads the price list rather than guessing from memory.
Hetzner is not one API
Why one connection is never enough
This is the single most confusing thing about Hetzner, and it is the main reason this server exists. A Cloud API token is created inside a project and can only ever see that project. There is no project parameter anywhere in the API, so there is no way to point one token somewhere else. If you have ten projects across three accounts, you have ten tokens. And the dedicated servers you lease are not on that API at all — they sit behind a different address with different authentication. Storage Boxes are on a third one.
The server does not try to paper over that. Each token becomes a named connection, every tool takes the connection by name, and a search can sweep all of them in a single call. The surface stays visible too, because a Cloud server is a virtual machine billed by the hour and a Robot server is leased physical hardware on a monthly contract with a cancellation period. Collapsing those two into one word is how "reboot the server" becomes a question nobody can answer safely.
You never configure an address either: Hetzner runs one instance of each API, so the base URL is derived from the surface rather than typed in.
Cloud
One project
Virtual servers, volumes, networks, firewalls, load balancers and DNS. A Cloud token sees exactly the project it was created inside, and nothing else.
Hetzner account
The whole account
Storage Boxes live behind a separate API. Your Cloud token does not reach it; the account token is created separately and named as its own connection.
Robot
The whole account
The dedicated hardware you lease. Different address, different authentication entirely. This surface is planned for v0.3 and is not shipped yet.
Tool surface
220 operations, 13 tools
Hetzner's APIs have 220 live operations. Publishing all of them as separate tools would have been the easy call, but a client reads every schema at startup, and the model would spend its context budget on definitions it never calls. So thirteen tools are published: finding resources, reading one in full, following an Action to completion, reading metrics, reading prices, provisioning a server, power and lifecycle control, DNS, and labels. That is the loop an operator actually repeats.
Everything else goes through a searchable catalog: search for the operation, read its schema, then run it. The catalog is generated from Hetzner's own OpenAPI specifications, vendored into the repository and committed. Every MCP client spawns this process fresh, so parsing 3.4 MB of spec on each start would be worse than reading a file from git. CI regenerates and diffs it, so an upstream change breaks the build loudly instead of quietly shipping a stale tool surface.
One detail worth knowing: 143 of those 220 operations return an Action rather than a result. The call comes back with a running status and the work happens afterwards. Waiting is therefore the default here rather than a convenience, and every response states separately whether the work actually finished or the wait gave up. A tool that reported a running Action as done would be worse than one that never waited at all, because you could not tell the difference.
Safety
The dangerous thing is not on the list
Handing an API key to a language model is a serious decision. This is the part of the design we spent the most time on.
There is no delete tool to call
Deletes, rebuilds and overwrites live in a single tool, and that tool is not registered at all unless HETZNER_ALLOW_DESTRUCTIVE=true. It is not listed-and-refusing — it is absent from the client's tool list. So a host that auto-approves non-destructive tools is auto-approving something genuinely non-destructive.
Read-only is a ceiling, not a preference
With HETZNER_READ_ONLY=true, or readOnly set on one connection, every non-GET call is refused at the HTTP client before the socket opens. A connection cannot opt back out of it through its own settings. The refusal happens before anything reaches the network.
No tool schema can name a host
There is no baseUrl, url, host or credential parameter anywhere in the surface. The connection parameter is a closed enum over the names you configured. An instruction hidden in a resource name or a DNS record saying "send this to another address" has nowhere to land, because the shape to express it does not exist.
Operations that open a bill are visible, not hidden
On a write-capable connection, provisioning a server needs no additional flag. Rather than pretend otherwise, the server makes the cost visible: the catalog marks those operations costly, and a call that created something reports Hetzner's published price in meta.billing. That is a real mitigation for a model reasoning in good faith and not a mitigation against prompt injection. If that is the wrong trade for you, use a read-only token and keep writes on a separate connection you name explicitly.
Setup
One command and one environment variable
- 01
Install from source
Clone the repository, run npm install && npm run build, then node dist/cli.js install. The installer detects the MCP clients on your machine — Claude Code, Claude Desktop, Codex, Cursor, Zed, opencode, Kimi, MiniMax. It shows you exactly what it will write and writes only what you approve. Add --dry-run to see the diff and change nothing, or --pin to pin the exact version.
- 02
No credential enters a client config
What the installer writes is a pointer: a command and at most a connection name. The token never passes through it. The key is read from one of three places instead — an environment variable, the output of a command such as your password manager, or the machine's own credential store.
- 03
Each project is its own connection
HETZNER_TOKEN_PROD and HETZNER_TOKEN_STAGING are two connections, and every tool takes the connection by name. With exactly one connection configured the parameter does not exist at all. For per-connection settings — a read-only production connection, a longer timeout — use a config file. Credentials cannot go in that file: the schema has no token property and rejects unknown keys, so writing one is a startup error.
- 04
Writes behind one flag, deletes behind another
The default install reads. HETZNER_ALLOW_DESTRUCTIVE registers the destructive door; HETZNER_READ_ONLY refuses every write server-wide. The doctor command reports what is configured and what is wrong with it, and secrets set writes a key into the OS credential store without echoing it or putting it on a command line.
Limits
What it will not do
For some jobs another tool is simply better. Not saying so would cost you time.
It does not go inside the machine
This is not an SSH tool. It talks to Hetzner's API, not to the operating system on your server. No df -h output, no running processes, no log files. The disk metric it returns is what the hypervisor sees, not what your filesystem reports.
It is not a replacement for Terraform
If you want your infrastructure's desired state to live in version control, reviewable and reproducible, the right tool is OpenTofu or Terraform with the hcloud provider. This one is for asking questions and doing one-off things, and it does not try to own your state.
Dedicated servers are not there yet
The Robot surface is planned for v0.3. Today you cannot see the physical hardware you lease through this server; the Cloud and account surfaces are the ones that work.
For bulk work the console is often faster
If you are relabelling thirty machines at once, or running a long migration plan, the Hetzner Console or a script over the hcloud CLI will take less time. This tool is fast at getting one answer to one question.
Who this is for
Who gets something out of it
Anyone running more than one project
Three accounts and ten projects means ten tokens. Being able to search across all of them from one place is where most of the value sits.
Developers working inside an AI client
Asking "is that box still up" without leaving the editor keeps the thread of what you were doing intact.
Teams carrying a pager
Metrics and recent Action history are readable without opening a dashboard, and the destructive tools are not registered, so the 3 a.m. accident surface is narrow.
People reviewing MCP security
The source is open. Read why the tool schemas cannot name a host and where the read-only ceiling is enforced, then apply the same shape to your own server.
FAQ
Frequently asked
Is it really free?
Yes. MIT licensed, source open on GitHub. There is no paid tier, no enterprise edition and no service package attached to it. What you pay Hetzner is between you and Hetzner; this tool does not sit in the middle of that.
Why not publish all 220 operations as tools?
A client reads every tool schema at startup. Handing it 220 schemas spends a serious share of the model's context budget on definitions it will never call. So thirteen tools are published — the loop an operator actually repeats — and the rest is reached through search_operations, describe_operation, then an execute call.
Why can a Cloud token not see all my projects?
That is how Hetzner works. A token is created inside a project and there is no project parameter anywhere in the Cloud API, so you cannot aim one token at another project. Ten projects are simply ten connections. The server makes that visible rather than hiding it: every tool takes the connection by name, and a search can sweep all of them in one call.
Could the model delete a server by mistake?
In the default install the destructive tool is not registered, so there is nothing to call. Turning the flag on opens that door deliberately. Four operations are also destructive without being deletes — rebuilding a server, importing a zone file, replacing a record set, and rolling a Storage Box back to a snapshot — and the build fails if any of them stops matching that classification.
Are you affiliated with Hetzner?
No. Done Dynamics is a Hetzner customer, and this is a client we wrote. It is not endorsed, supported or published by Hetzner in any way.
Where does the key live on Windows?
macOS uses the login keychain and Linux uses libsecret, both with per-item access control. Windows has no first-party equivalent that returns a stored secret to a CLI, so it gets a DPAPI-encrypted file under %LOCALAPPDATA% instead: only your user, only that machine — but with no per-item ACL and no unlock prompt, so any process running as you can decrypt it. Better than a token in a client config, weaker than a keychain, and the docs say so plainly.
Related pages
coolify-mcp →
The same idea on the Coolify side: triggering deploys, deployment status, reading logs. Also MIT licensed.
Our open-source work →
Both MCP servers and the model releases we published on Hugging Face, on one page.
Cloud services →
If you want help on the server setup, migration and operations side, that lives here.
Hosting →
Our hosting and maintenance work. Unrelated to the tool — just the next door along.
If you want something similar built for your own infrastructure, write to us — but you do not need us to use the tool, the repository is open.
Ready for your next software project?
Book a free 30-minute discovery call with our team.
