Dora NodaOn August 30, 2026, a community maintainer re-validated every tool of an MCP server against the live Hetzner API changelog — three months after the first sweep — and published the delta table. Six provider-side changes in three months, spanning a removed response property, a renamed deprecation field, new required parameters, and two looming deadlines. Tools broken: zero.
That is the whole lesson in one number, and it is the lesson every deploy-from-chat roadmap needs: an infrastructure-facing tool surface is only as current as its last changelog pass. The server is mjmirza/hetzner-mcp, a community project mapping the Hetzner Cloud, Storage Box, and Robot APIs to MCP tools. Its audit discipline — a tested endpoint inventory plus a scheduled re-validation against the provider changelog — is the part worth copying. But a community server also stops exactly where a PaaS has to start: tenant scoping, audit-logged deploys, and credential boundaries. This post walks the audit, the drift it survived, and the honest borrow / contribute / build verdict for each layer.
What the community server actually covers
hetzner-mcp is a TypeScript MCP server covering three Hetzner surfaces behind one tool set: Cloud (servers, networks, volumes, firewalls, load balancers, floating and primary IPs, placement groups, SSH keys, images, certificates, and DNS zones), Storage Box backup storage, and Robot dedicated servers and vSwitches. One Cloud API token authenticates both Cloud and Storage Box; Robot needs its own webservice user and password over HTTP Basic on a different host. That auth split is documented from live probing, not assumed from docs.
The design details that matter for operators:
- Cost classes on every endpoint. Each tool is labeled FREE (reads), FREE-CREATE (creatable at zero cost: SSH keys, networks, firewalls, placement groups), or BILLED (servers, volumes, load balancers, IPs, storage boxes, dedicated servers). Billed calls require explicit confirmation and get a price preview first.
- Destructive guard. DELETE-class operations require
confirm: true, and a read-only mode blocks them outright. Input validation runs through zod on every tool. - A live validation suite, not just unit tests.
test/live-validate.tsruns 52 checks — reads, guard behavior, and free plus billed create/delete lifecycles across all three surfaces — against a real Hetzner account. - A contribution loop that demands evidence. The missing-endpoint issue template and the PR template require pasting the real result of calling the endpoint against a Hetzner account, secrets redacted. New coverage arrives with proof attached.
Setup is a guided wizard (npx hetzner-mcp setup) that verifies the token against the live API before writing any client config. And the project publishes a comparison table against sibling servers — dkruyt/mcp-hetzner, Xodus-CO/hcloud-mcp, valerius21/hetzner-mcp, and others — where it is the only one documenting a cost guard, a live endpoint audit (39 of 39), and a contribution loop. That comparison is self-reported, but the audit document it points to is public and specific, which is more than any sibling offers.
The drift it survived: six changelog deltas in three months
The audit lives in docs/ENDPOINT-AUDIT.md. The June 7, 2026 sweep live-tested every read endpoint and immediately caught rot: the global GET /actions endpoint returned 410 deprecated_api_endpoint, so the server routes action queries per resource instead. Three months later, the August 30 pass re-checked every surface against the current changelog without re-running billed calls, and recorded six deltas:
| Date | Provider change | Effect on the server |
|---|---|---|
| 2026-05-01 | Assigned Primary/Floating IPs must be unassigned before delete | Advisory: teardown ordering in the provision skill |
| 2026-06-02 | /datacenters endpoints deprecated, removal after 2026-10-01 | Safe today; the eval treats 410-on-deprecated as a pass |
| 2026-06-05 | LB Types deprecated field renamed to deprecation | Not affected; the response projection never referenced the old field |
| 2026-07-01 | datacenter property removed from Servers and Primary IPs bodies | Not affected; the curated create body sends location, never datacenter |
| 2026-07-08 | dns_ptr required for reverse-DNS changes, ttl for RRSet updates (deadline 2026-09-30) | Caller responsibility; the generic write tool passes bodies through |
| 2026-08-17 | LB health checks gained detail and http_status_code fields | Additive only, no break |
Two things make this table more than bookkeeping. First, the July 1 datacenter removal broke real automation elsewhere: a GitHub-Hetzner runner autoscaler started crashing dereferencing server.datacenter.location.name, the official hcloud CLI shipped v1.67.0 removing its --datacenter flags, the Ansible collection cut a breaking release, and downstream projects from vmagent service discovery to machine-controller filed migration issues.
The deprecation was announced in December 2025 with a July 2026 removal date, and it still caught pinned tooling off guard. That is exactly the failure mode an unaudited MCP tool surface inherits silently — except an agent holding a stale tool definition does not file a migration issue, it just fails the deploy call at 2 a.m.
Second, two of the six rows are live deadlines, not history. Reverse-DNS and TTL requirements bite September 30, 2026, and the /datacenters endpoints go away after October 1. An audit cadence is not hygiene theater; it is the difference between reading those dates in a changelog and discovering them in an incident.
Why it survived: three design decisions
The audit is the discipline, but three design decisions are what made the deltas survivable. Each maps directly to rows in the table:
- Generic pass-through writes. Most mutations go through a generic request tool that forwards the caller's body to the API. When Hetzner added required parameters (
dns_ptr,ttl), no curated tool broke — the requirement falls to the caller composing the body. Pass-through trades schema strictness for changelog resilience, and for a provider API that changes six times a quarter, that is the right trade. - Curated tools avoid volatile fields. The hand-built create/delete tools construct minimal bodies —
location, neverdatacenter— and the response projection is generic rather than bound to fields providers rename (the LBdeprecated→deprecationrename passed through harmlessly). Verified in code during the audit, not asserted. - The eval expects deprecation. The validation suite treats a 410 on a deprecated endpoint as a pass, so the October
/datacentersremoval will not fail the suite — it will just retire a tool path that was already marked. Deprecation is modeled as a normal lifecycle event, not an exception.
The general principle travels beyond Hetzner: MCP tool drift against a moving backend is a known failure class. One project's drift audit found its agent tools had silently diverged from the router they wrapped — weaker permission checks, missing dual-writes and cache invalidation, stale URL lists. hetzner-mcp's answer is to make the tool surface either too thin to rot (pass-through) or too tested to rot quietly (live suite plus scheduled changelog pass). A PaaS MCP server should steal both halves.
What a community server can't supply
Here is where the honest accounting starts. hetzner-mcp is a single-tenant tool: one operator, one token, one Hetzner account. A self-hosted PaaS offering deploy-from-chat to tenants needs a deploy-authority layer the community server deliberately does not attempt:
- Tenant scoping. A tenant's agent must see and touch only that tenant's services, and the scoping has to be enforced server-side, not suggested in a system prompt. A shared Cloud token with a confirmation flag is not multi-tenancy.
- Audit-logged deploys. Every agent-initiated deploy, rollback, scale, and secret touch needs an actor, a timestamp, a diff, and a replay path. "The agent did it" is not an audit trail.
- Credential boundaries. Tenants must never handle the provider token at all. The PaaS holds provider credentials; tenants hold PaaS-scoped credentials; the MCP surface brokers between them with least privilege per call.
- Per-tenant cost attribution. A price preview protects one operator from surprise bills. A platform needs per-tenant metering of both the infrastructure the agent provisions and the model calls the agent burns doing it.
None of this is a criticism of the community project — it is scope the project correctly refuses. But it sets the build-vs-borrow line precisely: everything below the deploy-authority line is borrowable; the authority line itself has to be built.
Borrow, contribute, or build
With the line drawn, the verdict per layer:
| Layer | Verdict | Why |
|---|---|---|
| Endpoint map (which calls exist, cost class, auth shape) | Borrow the pattern | The inventory format — surface, method, cost class, last test date, live result — ports directly to any provider surface |
| Changelog-audit cadence | Borrow, then contribute | Quarterly re-validation against the provider changelog is the cheapest reliability win; contributing audit findings upstream keeps the map you borrowed accurate |
| Guard patterns (confirm-on-billed, destructive guard, read-only mode) | Borrow | Battle-tested shapes for agent-facing mutations; adapt the confirm semantics to tenant policy |
| Deploy-authority layer (scoping, audit log, credential brokering) | Build | No community server can supply your tenancy model; this is the PaaS's own control-plane work |
The contribution direction matters. If a PaaS borrows the endpoint map and the audit cadence, its own changelog passes will find deltas the community server has not hit yet. Upstreaming those — a missing-endpoint issue with live evidence attached, per the project's own template — costs minutes and keeps the shared map current for everyone downstream of it. Extract-only open source is how tool surfaces rot in the first place.
The deeper takeaway is about what "done" means for agent infrastructure. An MCP server is not done when its tools work; it is done when it has a defined answer to provider drift — a re-validation date, a deprecation lifecycle in the eval, and writes too thin to rot. hetzner-mcp ships that answer in a markdown file and a test suite. Any deploy-from-chat roadmap that cannot point to the same two artifacts is carrying unpriced risk, and the next Hetzner-style removal notice will price it.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
